On Wed, 2 Oct 2024 at 20:25, Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx> wrote: > > Hi Jeremy, > > [...] > > > >>> > > >>> Back when we added this we intentionally left loading an initramfs > > >>> loaded via the command line out. > > >>> We wanted people to start using the LoadFile2 protocol instead of the > > >>> command line option, which suffered from various issues -- e.g could > > >>> only be loaded if it resided in the same filesystem as the kernel and > > >>> the bootloader had to reason about the kernel memory layout. > > >>> I don't think measuring the command line option as well is going to > > >>> cause any problems, but isn't it a step backward? > > >> > > >> Thanks for looking at this. Since no one else seems to have commented, I > > >> will just express IMHO, that both methods are useful in differing > > >> circumstances. > > >> > > >> For a heavyweight Linux aware bootloader like grub/sd-boot the > > >> INITRD_MEDIA_GUID is obviously preferred. But, for booting strictly out > > >> out of a pure UEFI environment or Linux unaware bootloader (ex: UEFI > > >> shell), > > > > > > I am not sure I am following on the EfiShell. It has to run from an > > > EFI firmware somehow. The two open-source options I am aware of are > > > U-Boot and EDK2. > > > U-Boot has full support for the LoadFile2 protocol (and the > > > INITRD_MEDIA_GUID). In fact, you can add the initramfs/dtb/kernel > > > triplets as your boot options, supported by the EfiBoot manager and > > > you don't need grub/systemd boot etc. > > > > > > I don't think you can do that from EDK2 -- encode the initrd in a boot > > > option, but you can configure the initramfs to be loaded via LoadFile2 > > > in OMVF via the 'initrd' shell command. > > > > Oh, I guess the shell is a bad example because I was unaware that there > > was a initrd option in it now. I'm buying into the boot loader/boot > > manager distinction, where the manager is largely unaware of the target > > OS's specific needs (in this case, having the initrd GUID set). > > Yes, FWIW what was added in U-Boot needs to be aware of the > Linux-specific GUID, but as far as the EFI BootOptions defined in the > Boot manager, we aren't violating anything in the EFI spec. On the > contrary, we use the _EFI_LOAD_OPTION exactly as the spec describes. > > > > > > > > > > >> the commandline based initrd loader is a useful function. > > >> Because, the kernel stub should continue to serve as a complete, if > > >> minimal implementation for booting Linux out of a pure UEFI environment > > >> without additional support infrastructure (shim/grub/etc). So, it seems > > >> that unless there is a reason for divergent behavior it shouldn't exist. > > >> And at the moment, the two primary linux bootloaders grub2 and sdboot > > >> are both using the INITRD_MEDIA_GUID. Given the battering ram has been > > >> successful, it isn't a step backward. > > > > > > I am not saying we shouldn't. As I said I don't think this patch > > > breaks anything. I am just wondering if enhancing EDK2 to load the > > > initramfs via LoadFile2 for more than OVMF is a better option. > > > > There is a separation of concerns argument here. People regularly > > complain about firmware implementations tuned for windows, but making > > the FW aware of this GUID is doing the same thing for Linux. > > So, IMHO > > that should be avoided, rather assuring the firmware is made as OS > > agnostic as possible, and the OS specifics are moved into the OS boot > > loader, one of which is this stub. It would make more logical sense to > > have the stub set the GUID from built in command line defaults. To be > > clear, i'm not suggesting that. > > I get the separation point but .... > If you do it the other way around you *force* people to use specific > OS loaders that implement OS-specific protocols. And the EFI stub is > not the problem here nor are distros that use such loaders. However, > vertical distros for embedded boards which don't need all the added > complexity have a reasonable way out. > > Anyway, since Ard doesn't plan to deprecate initrd=, the patch is > reasonable, I have no objections > I've queued this up now - thanks all.
