Use grub-mkstandalone instead of grub-mkimage for UEFI #2293
Conversation
|
Hello @pcahyna, I just run a simple test and created ReaR rescue system with your code. Thanks V. |
|
Hi @gozora , |
|
Hello @pcahyna, I've used SLES12SP4 for SAP ... V. |
|
Excerpt from debug log: |
|
@pcahyna do not spent your time on this for now! I'll run couple of deeper tests in upcoming days and let you know if I find something ... V. |
|
@gozora , thanks. I suggest that you also try GRUB_RESCUE, which uses the same code. |
|
@pcahyna I've tested GRUB_RESCUE as you've suggested and got following:
I'm pretty sure that kernel and initrd are available but Grub2 somehow can't locate them: Same ReaR configuration works fine with "old" code ... Thanks V. |
|
@pcahyna I just realized that I'm running my server from BTRFS snapshot ... V. |
|
@pcahyna just FYI: V. |
|
@gozora has the build code loaded a btrfs and LVM module in Grub2? If not, can you manuallly load them (insmod btrfs, insmod lvm) and try the menu again? |
|
P.S. you will see what modules get loaded from the grub2-mkstandalone command from the debug log. (I also added a separate log statement which will show them) |
|
I assume that all modules were loaded, because I was able to read content /boot directory from Grub2 command line without any problems. V. |
|
@gozora you are able to read the content, but is the content correct? If yes, I don't see how you are able to read the content but not able to boot a kernel which is part of the very same content. |
|
I just simply read content of directory in Grub2 cmdline . I dont know what content / directory is the "correct" one for Grub2. V. |
|
I mean if you read the content of the directory, do you see the kernel and initrd that you want to load? |
|
From my experience with the SUSE's special btrfs default structure From my personal point of view it is just too complicated. When all and everything is fully correctly set up for it, But from my experience things fall apart as soon As far as I know (but I am not at all a real expert in this area) With SUSE's special btrfs default structure what is mounted as '/' in the And then other sub-directories of the btrfs tree (actually btrfs subvolumes) To see what of the btrfs tree is acually mounted one must mount For example on my current SLES12-SP4 system with LVM and btrfs so what looks like I guess with UEFI the same kind of confusion could happen. I think what file and directory paths a GRUB2 command "sees" Again: But what is true is that file and directory paths look different Cf. my fun with it in |
|
Thanks @jsmeix i coldnt explain it better! V. |
|
When I'm using "old" code ReaR executes code as follows: However with "new" code, I have only following modules: Any idea why only 3 modules are auto-detected? (a site note; on this server I don't have BTRFS located on LVM, so missing modules should not be a showstopper for booting) Excerpt from debug log: If I add modules manually by: It still doesn't work though ... (when I type V. |
|
I can see that bootx64.efi and rear.efi are created differently: What is the purpose of $3 and $4 when creating rear.efi ? V. |
The purpose is to pass directories/files that must be accessible from Grub. My code makes sure that Grub modules needed to access those are loaded. Without this feature, you would risk not having part_gpt and / or btrfs modules loaded and you would not even see your /boot. (The log snipped you have shown proves that this part is working correctly.) |
Not strictly required, but useful and good for consistency with the GRUB2_RESCUE Grub image.
Since $UEFI_BOOTLOADER contains the path to the bootloader and grub-probe can work with file paths as well as with directories, take advantage of it and use $UEFI_BOOTLOADER to determine the modules needed to access the ESP (EFI system partition).
|
Unfortunately I've found another problem while running some tests on SLE15. V. |
@gozora thanks for the test. The The problem is, we have unified Grub2 image creation between the ISO and GRUB2_RESCUE, but we have not unified the config file creation. |
Copy graphics-related commands from create_grub2_cfg (in bootloader-functions.sh) to the GRUB2_RESCUE Grub2 config file. XXX the Grub2 config file generation for GRUB2_RESCUE should be unified with config file generation for ISO (create_grub2_cfg).
(if there is anything to print)
|
@gozora hope your issue is fixed now. I just copied the graphics-related code from create_grub2_cfg, because sharing the code would mean a bigger refactoring. |
|
Hello @pcahyna, Thanks for your update, I'll test it again soon ... V. |
|
After running several other tests this PR looks good to me. V. |
|
@gozora thanks for testing! Does it fix your btrfs-on-lvm case without the need of setting GRUB2_MODULES(_LOAD) manually? |
|
Hello @pcahyna, yes btrfs-on-lvm problem is now solved without any explicit Grub module configuration inside ReaR. V. |
|
@rmetrich |
|
@pcahyna thanks for your work on this PR, it is appreciated! V. |
|
…EFI-specific Make GRUB2_MODULES variables having UEFI specific names: Renamed GRUB2_MODULES and GRUB2_MODULES_LOAD for installing GRUB2 as recovery system UEFI bootloader into GRUB2_MODULES_UEFI and GRUB2_MODULES_UEFI_LOAD see #2392 Those config variables have not been in a released ReaR version, cf. #2293 (comment)
Sometimes the search command in GRUB2 used in UEFI ISO does not find the root device. This was seen at least in Debian Buster running in Qemu (VirtualBox works fine, RHEL/CentOS in Qemu works fine as well). To make ReaR work in this case, set $root to a sensible value before trying `search`. The GRUB2 image created by grub-mkstandalone has $root set to memdisk, which can't work. This essentially matches how it used to work before PR rear#2293. Fixes rear#2434.
Sometimes the search command in GRUB2 used in UEFI ISO does not find the root device. This was seen at least in Debian Buster running in Qemu (VirtualBox works fine, RHEL/CentOS in Qemu works fine as well). To make ReaR work in this case, set $root to a sensible value before trying `search`. The GRUB2 image created by grub-mkstandalone has $root set to memdisk, which can't work. This essentially matches how it used to work before PR rear#2293. Fixes rear#2434.
Pull Request Details:
Type: Bug Fix / Cleanup
Impact: Normal
Reference to related issue (URL):
uefi: Search for Grub2 modules in /usr/lib/grub*/x86_64-efi and not in /boot #2199 Currently, ReaR is using hard-coded set of Grub2 modules for UEFI #2283 fedora29 grub2-efi-x64-modules does not contain linuxefi module #2001 ReaR fails on Fedora 29 with UEFI when grub2-efi-modules are missing #1996 (comment)
How was this pull request tested?
the two cases that use the code touched by this PR:
Brief description of the changes in this pull request:
There have been several cases recently where ReaR on UEFI was broken due to either a wrong assumption about what Grub2 modules to load (fedora29 grub2-efi-x64-modules does not contain linuxefi module #2001) or, in an attempt to fix it, a wrong assumption about where to search for them (see uefi: Search for Grub2 modules in /usr/lib/grub*/x86_64-efi and not in /boot #2199). I believe that such Grub internal details are better handled by Grub itself and we should not hardcode them (making them configurable is only a workaround - the default should work in most scenarios). Therefore this change switches to using grub-mkstandalone for te Grub2 UEFI image generation, which, unlike grub-mkimage, relies less on supplied information about modules. It embeds a ramdisk in the Grub2 image and by defaults includes all modules in it.
I found that the current method is broken at least on RHEL and GRUB_RESCUE, because the current default set of modules does not include xfs and /boot is XFS by default on RHEL, making it inaccessible from Grub2. This change also fixes this, therefore it is a bugfix in addition to a cleanup.
I found that the image creation using grub-mkstandalone still needs to be told to load partition modules, otherwise partitions will not be detected out of the box. I therefore added a dynamic detection of all modules needed to access /boot (partitions, filesystems, and others like lvm, should it be needed) using grub-probe, as it is more robust and relies on less assumptions than trying to guess a reasonable set of default modules.
The change still honors GRUB2_MODULES, but changes it into an array. (Other lists in configuration are specified as arrays already, like MODULES, so having GRUB2_MODULES an a string with blank-separated words is not consistent with the rest of the configuration.) If GRUB2_MODULES is set and nonempty, only the specified modules will be embedded in the standalone image ramdisk and also only those will be loaded. The detection using grub-probe will be switched off.