Gentoo installcd copied in ISO mode no longer boots in UEFI mode #2127
Comments
|
Hi Ben, First of all, let me start by saying that I always appreciate when distro maintainers report breakage, because we really all want the same thing here: Ensure that users can always create bootable media from a distro with a utility they are comfortable with, and therefore resolve any issue that is found during the media creation process. I certainly want people to continue to be able to use Rufus to install Gentoo too!
Then you want to apply this patch series that I sent to the GRUB mailing list (Add support for EFI file system transposition), because I believe that this is your issue. For what is worth, this is something that I have been trying to pre-empt with the GRUB folks ever since I became aware of the problem early last year (and as a matter of fact, the series I am linking to is a re-sent of the same series I submitted quite a few month earlier), and that took quite a lot of convincing to get the GRUB folks to consider integrating. Hopefully, you can apply this patchset to your source tree and that will solve your issue. I also have some notes on how to test this without having to generate a full blow distribution ISO, that I jolted down for the GRUB maintainers. If that does help solve your issue, please don't hesitate to spread the word that EFI File System Transposition is a crucial means of creating UEFI bootable media for users (since it can make Rufus or external utilities including |
|
Thanks for the quick followup! I'm going to apply the grub patches and do a test build, I'll let you know the result and if it's success then I'll talk to our grub maintainer about taking up the patches until upstream does. As I started reading your patch description, it all started to sound very familiar... then I remembered that a few years ago, I added similar logic to our ISO build system for rufus/unetbootin compatibility (forgive me if I got any technical details or terminology wrong): When we moved to using grub-mkrescue, it greatly simplified our ISO generation, BUT we lost that logic to duplicate /boot/efi contents! So it makes sense that now grub-mkrescue needs to handle that, I'm really surprised it doesn't already. |
|
Well, the GRUB patchset should take care of ensuring that Basically, and this is what I mention in the patchset, you want your boot process to honour the 3 following requirements:
If you can honour the 3 requirements above, then, no matter the OS, users who are trying to create a disk-based boot media from your ISO should be able to do so on UEFI systems without using anything but the native tools that are guaranteed to be present on their OS (where, when you do consider Windows users, |
|
With your grub patches, I do now see /efi/boot/ populated on the resulting ISO and on the USB drive created by rufus, but it still fails to boot, with the same grub errors. I do see one difference though, I am now able to "ls (hd0,msdos1)/" from the grub rescue shell and read the files on the usb stick-- so the minimal grub image has fat support now. And now with a few grub commands, I can get it booting: This gets me to the expected grub menu where I can select a Gentoo kernel and boot successfully. Any idea where the missing piece is now? I have a copy of the new ISO (built with your grub patches) here: https://drive.google.com/file/d/15xIiuqVgIz9puKA-qeV4j_JHsgBDNVBV/view?usp=share_link |
|
I'm a bit confused about something else as well. Before grub-mkrescue was populating /efi/boot, it was still starting grub in EFI mode, but from where, if the ISO embedded boot images are gone? I do see what appears to be a grub image at /System/Library/CoreServices/boot.efi, is that where it was loading from? Since your patches, I notice that partciular grub image has increased in size. Before it was 257KB, now it is 297KB. |
|
The I'm not sure why that is the case because, the way I patched Can you please first validate that the patchset has been properly applied, and that you do have the following lines in your /* Create a '.disk/<TIMEBASED_UUID>.uuid' file that can be used to locate the boot media. */
diskdir = grub_util_path_concat (2, iso9660_dir, ".disk");
grub_install_mkdir_p (diskdir);
iso_uuid_file = xasprintf ("%s.uuid", iso_uuid);
diskdir_uuid = grub_util_path_concat (2, diskdir, iso_uuid_file);
f = grub_util_fopen (diskdir_uuid, "wb");
fclose (f);Also be very mindful that, unless you ran grub install, you may still invoke your system's default unpatched binaries, which, even if you do invoke the newly built I suggest that you follow the steps I described from https://gist.github.com/pbatard/0deddbd71eefc35a3ed0b08e12a9e7e3 to validate that you can generate a minimal super grub disk image that includes the
The embedded boot image is not gone. The patchset duplicates the
I do mention that in my notes. We're adding extra file system and partition modules, so, yeah, this will come as an extra few KB (and since we are using the same bootloaders on the ISO fs as the one from the image, this will increase the image size). There really was no point trying to devise a solution where the (ISOHybrid-as-dd-disk-boot) image and (File-system-transposed-disk-boot) ISO9660 bootloaders would be tailored for one specific role, with removal of the parts that only applied for the other role. Better to create GRUB bootloaders that fit both roles, and avoid having to indentify weird issues down the line of "It boots when I use dd, but not when I file transpose" that boil down to a different |
|
Aha, thanks for catching that. I had to mangle the patches a bit after copy/pasting from the ML archive and somehow that one chunk of patch 3 was not being applied (not erroring either). I manually re-rolled that patch, verified that the "/* Create a '.disk/<TIMEBASED_UUID>.uuid' file.." code block exists now, and have rebuilt grub. Sure enough, the next ISO created with grub-mkrescue and passed on to rufus, boots perfectly. I believe we can close this issue out unless you want to use it as reference until the patches (hopefully) land upstream at grub. |
|
Happy to hear that you sorted it out. I'm going to close the issue, since people who do a search should be able to locate it, and, considering how far and in between GRUB releases are (which, sadly, forces distro maintainers to perform a lot of unwarranted extra work), I wouldn't actually bet my life on the next GRUB release being sure to happen within the next 12 months... |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.Issue description
I'm part of the Gentoo Linux release team, and we began getting reports that our Minimal InstallCD image is no longer booting in UEFI mode when copied via rufus in ISO image mode. When booting BIOS/legacy it still works, but in UEFI mode it shows:
I believe the breaking change is on our end, when our ISO build tool changed how it prepares the ISO.
Previously we had an isolinux boot image for BIOS and a grub boot image (via grub-mkstandalone) for UEFI, and we called mkisofs to generate an ISO with those boot images embedded. Now we are calling grub-mkrescue to build the ISO, which will use grub for both BIOS & UEFI boot.
You can see our old call here: https://github.com/gentoo/catalyst/blob/catalyst-3.0-stable/targets/support/create-iso.sh#L258
It was roughly:
The new ISO creation command is defined here: https://github.com/gentoo/catalyst/blob/master/targets/support/create-iso.sh#L203 and just did a test build and here is the exact grub-mkrescue call and its output:
This new ISO built the grub-mkrescue way successfully boots in BIOS or UEFI mode, when copied to the USB stick via dd or Rufus with dd mode. When Rufus copies in ISO image mode, BIOS boot still works but UEFI doesn't.
If you'd like to see an example ISO built this way: http://distfiles.gentoo.org/releases/amd64/autobuilds/20230101T164658Z/install-amd64-minimal-20230101T164658Z.iso
Thanks for any help you can provide in figuring this out.
Log
The text was updated successfully, but these errors were encountered: