Right now the kernel isn't an EFI executable, so an additional bootloader is required in order to relocate it, set up the boot parameters structure, load an initrd if necessary and then jump to the kernel's entry point. There's ongoing work to make it possible to execute the kernel directly from EFI, with the command line arguments being provided directly. That's fine for the trivial case, but we'll still require a bootloader of some description if only to provide the user with their boot choices. While the EFI spec does support providing multiple boot choices that the user can select between, there's no specification for what the UI should look like. That's less than ideal.
Posted Sep 18, 2011 20:11 UTC (Sun) by raven667 (subscriber, #5198)
[Link]
That's something that goes back to my original point of encouraging more participation in vendor committees and whatnot by not just concerned vendors who use and fund linux but also independent groups like the Linux Foundation. EFI already seems pretty capable so getting the rest of the small number of additional features in the spec that would be needed to fully replace something like GRUB might be do-able if you can talk to the right people.
LPC: Booting and systemd
Posted Sep 18, 2011 20:15 UTC (Sun) by mjg59 (subscriber, #23239)
[Link]
The spec isn't intended to provide UI, since that's something that's intended to integrate with the platform vendor's design. You could imagine some vendors being happy with a text-based menu with various boot options, but it doesn't seem plausible that, say, Sony would go for that over some sort of graphical UI.
In any case, EFI doesn't require that the firmware be able to read arbitrary filesystems. If you want to boot a kernel off LVM or btrfs or even ext2, you need a bootloader sitting in the EFI system partition.
LPC: Booting and systemd
Posted Sep 18, 2011 20:36 UTC (Sun) by raven667 (subscriber, #5198)
[Link]
At the risk of backseat designing, it seems that all that is really necessary is the ability to provide a list of labels and not specify how they are displayed. One would think that by default it would just load whatever is set to be the default with minimal prompting unless a key is hit. This is similar to how GRUB is usually set up and how I think Mac's work right now.
While it may be do-able to load modules for common filesystem types, as GRUB already does, so you can load kernels off them it seems more productive to be able to EFI boot the kernel directly and have the current and previous kernel images live on the EFI system partition. Basically make the EFI system partition replace the /boot directory.
LPC: Booting and systemd
Posted Sep 18, 2011 21:39 UTC (Sun) by mjg59 (subscriber, #23239)
[Link]
There's no problem in configuring EFI to boot a kernel. The problem is in the UI that the firmware will expose to let you choose which kernel to boot or which boot arguments to pass. That's entirely non-standard, requires different keypresses on different hardware, looks different depending on a variety of circumstances and may not actually exist in any UI.
LPC: Booting and systemd
Posted Sep 19, 2011 3:44 UTC (Mon) by raven667 (subscriber, #5198)
[Link]
As long as it has the information and _can_ load a kernel with options and _can_ present a UI I don't think the actual UI needs to be standard. I would expect it to be branded by the hardware vendor for example. As long as there is a standard place to put kernel images and a standard way to add/remove labeled boot entries and if you can manually boot custom options using the EFI shell then I think that would solve the problem. I don't think the actual UI needs to be standardized beyond that.