Hi, > > > Can GRUB parse image and get kernel and initrd out of it and load > > > like Linux? What prevents add doing so. This is not a problem for > > > this patch per se but I want to understand
> > If we aren't utilizing the EFI stub in the UKI, we could parse the > > kernel and initrd from the section data and load it from there. In > > that case, I suppose it would be possible to load it for a coreboot > > or BIOS machine. Well, yes and no. A UKI is more than just a packaging format ... The systemd-stub can for example load extensions, which uses EFI protocols for filesystem access. That comes with challenges even in EFI mode because grub does not register EFI_SIMPLE_FILESYSTEM_PROTOCOL instances for the non-ESP filesystems it is able to read, so that can work only for UKIs loaded from the ESP. Also the initrd (systemd-gpt-auto-generator to be exact) will look for the LoaderDevicePartUUID EFI variable to figure which disk it has been booted from when searching for the root filesystem, which obviously is not going to work on BIOS/coreboot. There are ways to hack around that limitation, for example by implementing the root filesystem search in grub + patch the kernel command line. We even had a prototype for the latter, to allow hybrid BIOS/UEFI cloud images using UKIs, but at the end of the day dropped the ball on this and went for separate UKI images for a number of reasons. > I propose then to have some kind of "uki" command which would map to > EFI chainloader for now and later we can add implementation for > non-EFI. Aliasing 'uki' to 'chainloader' is probably a good idea, even of only for better usability. It's not obvious that 'chainloader' should be used to load UKIs. When it comes to implement 'uki' for non-EFI systems I have my doubts that this adds much value due to UKIs being designed for EFI systems as outlined above. my two cents, Gerd _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
