Boot Loader Spec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey all -

Some clever folks have come up with a draft spec for handling boot
configuration in a shareable, cross-bootloader, cross-distro way.

The details are here:
  http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec
but the basic idea is this:

1) Everyone uses an agreed-upon method for locating /boot
2) Each boot entry is a .conf file in $BOOT/loader/entries/
3) The .conf files use a common, agreed-upon format

And.. that's about it. Simple and elegant.

It greatly simplifies adding, modifying, and removing boot entries, and
also identifying (and dual-booting) other distros. 

I'm also reproducing Lennart's original mail below for further
edification, but there's a couple things I want to discuss here:

===  Our role ===
In this scheme, OS installers are responsible for:
 * finding (or creating) the /boot partition
 * finding (or creating) $BOOT/loader/entries
 * adding an entry for /boot to fstab

Mostly this would mean tweaking our /boot-finding Algorithm to match the
one in the spec (if it doesn't already!) and automatically using an
existing /boot partition if one is found.

We should still let users violate the spec if they want, but we should
probably warn them pretty hard.


=== Platform support ===
The spec gives an algorithm for finding /boot on systems with either
msdos or GPT partition maps, which obviously covers i686/x86_64.

As for other arches:

* arm - All the ARM platforms I know of use msdos. No problem.
* ppc - Everything but Apple uses msdos, and we don't support Apple.
        (The PReP partition is roughly equivalent to the MBR, which 
         isn't relevant to the location of the config files..)
* s390 - Has its own special partition map for DASD. Of course.

So. Can we come up with an addendum to the /boot-finding algorithm that
specifies how to locate/create /boot when using DASD partition maps?


=== Open questions ===
A few things I wondered about:

* Default entry
How does the system choose which entry to boot by default? Or how can we
tell the system to boot a given entry just once? 
This is outside the scope for this spec, but it'll be addressed later.

* Handling MBR/PReP 
What should we do with the MBR/PReP if we're sharing /boot?
If we find $BOOT/loader/entries, there will already be a compliant
bootloader installed, so we don't need to install a new one. But that
also means that we *can* install a new bootloader without harming the
other system.

Should the spec define which behavior is appropriate here, or
deliberately leave that up to us?

If $BOOT/loader/entries doesn't exist, well, we just end up with the
current behavior (create our own /boot and write our own config into it)
so there's no loss of functionality or interoperability there.

* Icons and theming
If we're sharing a bootloader, whose theme does it use? Or if we had
something like the Apple boot picker, wouldn't we want to be able to
specify an icon to use for our boot entries?
That's probably another future spec, but I'd like to see it addressed..

Anyway. Let me know if you have any thoughts here. The original mail
from Lennart is reproduced below.

-w

----------------------------------------

Heya,

(This mail is intended to the boot loader maintainers in the various
distributions. I am not sure I figured them all out correctly, if not,
would you be so kind to forward this to the folks who are the actual
maintainers? Also, feel free to forward this to anybody you think should
be in the loop...)

Newer EFI systems generally do not initialize USB anymore at boot, to
shove off a couple of seconds of POST. This means no kbd support to
enter the BIOS setup or to actually control the boot menu. Currently,
the Linux dual-boot story relies on boot menus: if you have installed
three linux versions, you choose at boot time where you want to boot
into, but that's not going to work anymore for all cases, already now.

Currently, dual-booting (or triple-, ... multi-booting) is pretty ugly
on Linux anyway. The installers try to probe for other OSes, and then
generate a configuration from that, that can't really be updated, and
the installers generally fight for which one may possess the MBR. Then,
there's no way for userspace to actually figure out which boot options
are available, short of parsing grub2.conf. One way to support dual-boot
scenarios might be to show a list of other installed OSes in the normal
OS UI (i.e. somewhere in the GNOME system settings or maybe the GNOME
shutdown button) and allowing the user to click on it to boot into it,
but if we can't even figure out which OSes are installed, that's
never going to work.

So, thinking about this, we came up with this specification:

http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec

This basically defines a scheme how multiple distributions can share a
single /boot and hence boot loader, without stepping on each other's
toes. It defines a generic syntax for drop-in menu items, which can be
read directly by the various boot loaders, and by userspace as well. And
it defines a scheme how installers can find where these files are to be
dropped, so that they can mount it to /boot.

Of course, just discussing the theory of this isn't enough, and hence we
sat down and implemented this in Gummiboot (where it is the native
configuration format now) as well as Grub2 (the patch is here:
http://0pointer.de/public/0001-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch
-- currently only applies to Fedora's slightly older version of Grub2).

Now, we are really interested in getting the various distributions to
subscribe to this idea. We are looking into support this scheme in
Fedora soon, our development packages of grub2 and gummiboot have been
updated already for this.

Right now, the spec is mostly a draft. We have thought a lot about it,
and it should be quite nice already. It covers both EFI/GPT systems and
MBR systems. But it's probably time to get more people involved, hence
this mail... To make this palatable to many folks we based the spec on
grub1's old syntax. 

Soooo, what do you guys say? Any chance we can get the key distributions
on board with this? Any comments? Anything you are missing? Good idea or
worst idea ever?

(Consider this spec semi-public: feel free to pass it on to whoever you
think should now about it, including in mailing lists, but please keep
it off blogs, slashdot, LWN for now, thank you).

Lennart


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux