Recent Features
| |||||||||||||
LPC: Booting and systemdLPC: Booting and systemdPosted Sep 17, 2011 0:20 UTC (Sat) by giraffedata (subscriber, #1954)In reply to: LPC: Booting and systemd by alankila Parent article: LPC: Booting and systemd
Maybe we should just go back to LILO. Why boot an intermediate kernel with some added complexity if you can just boot the real one, instead. Because you'd like to have a choice at boot time of kernels and kernel parameters. Hence the intermediate program, be it LILO, GRUB, or Linux. If you really don't want that boot-time choice, then you should step back beyond LILO to the system that simply loads the first N blocks from the disk and branches to it. That can be your Linux boot image, with built-in parameters. Even LILO is dependent on Linux filesystem design more than is desirable. It assumes a file is simply the content of a sequence of blocks, and that that sequence is static. A modern filesystem should not be bound to that.
(Log in to post comments)
LPC: Booting and systemd Posted Sep 18, 2011 17:14 UTC (Sun) by raven667 (subscriber, #5198) [Link]
I suppose EFI systems don't have a way to pass parameters to the kernel, otherwise on newer systems there would seem to be less need for a separate bootloader at all. Presuming that EFI can't pass parameters (or an initrd) that seems like a missed opportunity for the Linux community to get native booting into the standard. Sometimes it seems like linux kernel developers don't participate in the right vendor clubs to influence the design of hardware and standards and end up needing to conform after the fact.
I'm just kind of talking out of my rear end here so maybe it's not like that at all but that's the sense that I get sometimes.
I wonder if grub EFI is an EFI loadable module or a more traditional x86 bootloader, something like that could have just been specified in the standard such that EFI could natively boot Win*, Linux, *BSD, etc. on common filesystems without any further installs or intermediaries. That would probably require compromise on the design which is always hard to get.
LPC: Booting and systemd Posted Sep 18, 2011 18:26 UTC (Sun) by giraffedata (subscriber, #1954) [Link] But there's a reason for all the layers involved in bringing up a system. Each one has a different tradeoff of simplicity and stability versus flexibility, each one has a separate dependence on other components of the system, and so on.One could squeeze the GRUB and EFI layers into one, but look what you'd lose: Today, if I want to start determining kernel parameters in a new way, I can just update GRUB on my boot disk. If I mess it up so the system won't boot, that's OK - I can just tell EFI to boot from my backup boot disk (maybe a rescue CD) and fix it. But if all that parameter stuff was in EFI, I would have to flash a new EFI onto the motherboard, which isn't as easy. And if I screw it up, I might have a brick. We can argue forever on how many layers are optimal, and what should go in each one (I'm hearing more and more opinions that GRUB2 has features that would better reside at the Linux kernel layer), but it's clear that having lots of bootstrap layers can be useful.
LPC: Booting and systemd Posted Sep 18, 2011 20:06 UTC (Sun) by raven667 (subscriber, #5198) [Link]
That seems like a perfectly reasonable trade-off. As a practical matter, how often does the kernel interface have incompatible changes such that forces the need for a new bootloader. EFI and GRUB can already just load an arbitrary boot sector if you want a layered approach but from what little experience I have with EFI (just started working with it last week) it seems nearly capable enough.
Interestingly enough, elsewhere in LWN was a report of progress in making a linux kernel image that is directly bootable from EFI.
LPC: Booting and systemd Posted Sep 18, 2011 18:40 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
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.
LPC: Booting and systemd 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.
|
|||||||||||||