| |||||||||||||
LPC: Booting and systemdLPC: Booting and systemdPosted Sep 18, 2011 20:36 UTC (Sun) by raven667 (subscriber, #5198)In reply to: LPC: Booting and systemd by mjg59 Parent article: LPC: Booting and systemd
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.
(Log in to post comments)
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.
|
|||||||||||||