grub2 boot record unfunctional
Brought to you by:
henca
Menu
▾
▴
#11 grub2 boot record unfunctional
Hi. I tried as sudo with version 2.5.3 and 2.6.0
ms-sys -b /dev/sdb
with operation OK status and as root copied all necessary files. But after reboot and choice USB device as bootdevice i have only
GRUB_with blinking cursor and keyboard entering commands is impossible - no reaction.
This is strange, because standard behaviour for problem with loading grubmodules is like that:
grubrescue>
and is possible entering commands.
I think this is bad grub2 code - i think this is bug
In Win via Rufus is this procedure fully functional.
Last edit: Amigo Ventero 2020-05-20
Ms-sys only has functionality to write the grub stage 1 part to the MBR. I am not very familiar with GRUB myself, all the GRUB functionality in ms-sys was added by Pete Batard. However, some googling tells me that the stage 1 part of GRUB relies on the stage 2 part of GRUB and it seems as if the GRUB MBR written by ms-sys assumes that stage 2 (or stage 1.5) of grub resides on disc 80 (usually called C: or /dev/sda) and immediately after the MBR. So my guess is that you will not be able to boot from USB unless that 0x80 is changed to something else and that you will need to write the sectors of your stage 2 or stage 1.5 part of GRUB directly after the MBR.
Thank you for vector and your time. By info from GNU GRUB you almost hit. The image files that make up grub2 have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more - now is image system - and grub2 mbr code search for "core.img", which is written in next at least 31KiB.
From GNU wiki:
This is the core image of GRUB. It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads everything else (including menu handling, the ability to load target operating systems, and so on) from the file system at run-time.
All that remains is to have the on linux packages installed grub-pc, grub-pc-bin, grub-common, grub2-common and use command:
grub-installLast edit: Amigo Ventero 2020-05-21
If it really is so simple that the GRUB MBR only searches for the contents of core.img which is supposed to be written to the disk directly after the MBR this bug report should be converted to a support request. If so, it is not enough to only "copy necessary files" to a file system but the content of core.img will need to be written to a specific location on the raw disk. Writing data to that loccation of course also assumes that there is no partition containing a file system at that location.
If however my initial googling result is still valid that the GRUB MBR contains a drive ID and also where on the drive to search for the next step this bug report should instead be converted to a feature request asking for a possibility to also write the correct drive ID like the -p switch is able to do on FAT32 partition boot records and maybe also which position on that drive is supposed to contain the next step.
Older GRUB versions are explained at https://thestarman.pcministry.com/asm/mbr/GRUB.htm on that page it points out that the drive id 0x80 position 7c40 and at 7c44 there are 4 bytes containing the stage 2 beginning sector and those 4 bytes will be 01000000 if the next stage is placed directly after the MBR.
Looking at the MBR created with "ms-sys -b" I see that at position 0x5b we have 0x80 and directly after that we have 01000000, maybe this is only a coincidence, but it could mean that the GRUB MBR written by ms-sys assumes that the next stage should be on the drive with id 0x80. However, maybe that 0x80 only is the one containing the memory location of stage 2 as explained on the same page.
I guess that you are using ms-sys on a linux system in your attempts to install GRUB, just out of curiosity, why don't you use grub-install instead of ms-sys?
On wiki GNU is written, if i think this good, that core is possible put at defined filesystem - then is necessary modified main mbr code. But with modern formating, with starting at 1MiB for alignment, this is redundant.
Yes - you have right - this is probably for support request.
Minimalist systems are often without grub tools and ms-sys is smaller, more univerzal and more simple for remmember with good manpage.
Unfortunately I do not think that it would be possible to modify the GRUB MBR code to open files in a file system to find the next step in a core file there. The code to understand a file system and open files on a file system is too complex to fit into the 512 bytes that the MBR is limited to. To make things even worse those 512 bytes does not only contain the executable binary of the MBR but also the partition table. That is why all boot loaders in the MBR are really simple and rely on some kind of next step to perform the boot.
I don't think that ms-sys will be able to replace the grub programs for you, the ms-sys support is limited to the MBR part of grub and most ot the grub work is done at a later stage.
It looks like it's going to load directly from the filesystem - grubfolder i386-pc include file core.img .
In the end, I still think that the USB flash is evaluated the same as the HDD and that it may be an error. It is also possible that the code 0x80 may no longer be valid - I have experience that this parameter does not work with syslinux/isolinux chainloading to HDD, although it is set by default in the configurations of various Linux installers.
Via Rufus is choice grub2-bootloader install fully functional - so i should rater contact Pete Batard or consult You with him?
It would be interesting to compare that piece of code on a usb flash via rufus vs via ms-sys and what it looks like next - it would reveal.
I almost feel if Pete didn't mistake grub legacy there ;-)
512 bytes is half a kilobyte, I really find it hard to believe that the MBR would be able to fit code to understand and read from a file system. The linux kernel module for FAT is about 92 kB in size, but FAT is a rather simple file system, the ext4 module is about 908 kB in size, that is almost an entire Megabyte!
If you want to compare your successful installation with your failed installation and we assume that the GRUB2 MBR expects the next stage to be placed within the 32 kB directly after the MBR you could probably study the first 32 kB of your disk, something like:
dd if=/dev/sdb bs=32k count=1 | xxd - > success_disk.txt
Pete Batard is probably better at answering questions about GRUB2, but I still doubt that he would be able to make the MBR read different file systems.
As far as I know, other boot loaders do so - for example, the Winloader or G4D does not distinguish whether FS is ntfs or fat and loads the appropriate module for further management.
It is true, that in rufus grub2 installing is fixed choice for fat32 - then if you really needed something more beyond MBR for recognize FS, so this could be solved by an additional parameter to ms-sys.
But then is need to find out how it really is , whether it is loaded from the location immediately after the MBR or from the "core.img" file - in this case it would be error.
The Windows MBR bootloader simply checks which partition is marked as "active" in the partition table and then chains to the bootloader of that partition. A FAT32 boot record is about 1.5 kB in size, 3 times as big as the MBR. Newer Windows versions which relies on UEFI to boot needs a computer with an UEFI BIOS where the functionality to read a FAT file system is built into the BIOS.
Yes, it would be possible to add yet another functionality to ms-sys, making it capable of writing a grub second stage bootloader of about 32 kB. However adding such a big functionality would make the ms-sys binary about 50% bigger and that functionality is already available in another opensource tool better fitted for the problem. As with your other tool, the added 32 kB functionality in ms-sys would also be limited for fat32. With that functionality added it would only be a question of time before someone else asks for support for more file systems and more GRUB functionality and ms-sys would end up implementing all of GRUB in addition to the bootloaders beyond GRUB. As such ms-sys would end up becoming a bigger tool than grub.
Last edit: Henrik Carlqvist 2020-05-22
I understand your arguments.
Depending on what we've gathered together for the information, it's half and half, whether it's a missing next code or an error in the base code - why else would the core.img file be in the grub folder?
So I'll try to ask PB how it is - he will probably be acquainted in more detail.
Unless it takes it from that folder during installation - that would also explain core.img file in folder
Some more googling explains how core.img can be in the grub folder, from https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation
"there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the "boot track", "MBR gap", or "embedding area", and which is usually at least 31 KiB), or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition. "
That page continues: "Each of these has different problems."
...
"installing to a filesystem means that GRUB is vulnerable to its blocks being moved around by filesystem features such as tail packing, or even by aggressive fsck implementations, so this approach is quite fragile; and this approach can only be used if the /boot filesystem is on the same disk that the BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive numbers. "
...
"The GRUB development team generally recommends embedding GRUB before the first partition"
It seems to me as if the MBR written by ms-sys assumes that the core image is embedded before the first partition. Otherwise you would have to give the block address of core.img as an argument to ms-sys. Adding such an argument functionality to ms-sys would be trivial, but knowing what to pass to that argument when installing grub in a file system would be far from trivial for a normal user. For that some help program like grub-install would make life a lot easier as explained on https://www.gnu.org/software/grub/manual/grub/html_node/Images.html
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible.
It also looks like the core.img code is variable and it probably defines the partition FS and other from which it loads modules, because after adding it to the USB-flash fat32 ignored the configuration on the USB-flash and loaded it from the ext4 HDD. This is probably handled by a script from grub-install.
Thank for your time and best wishes.
Last edit: Amigo Ventero 2020-05-22
Yes, https://www.gnu.org/software/grub/manual/grub/html_node/Images.html says about core.img:
"It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads everything else (including menu handling, the ability to load target operating systems, and so on) from the file system at run-time. The modular design allows the core image to be kept small, since the areas of disk where it must be installed are often as small as 32KB."
Thanks for your test to verify that the content of core.img should be placed directly after MBR, I will close this bug report.