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... -- 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
On 15/02/13 09:41 AM, Will Woods wrote:
Hey all -
Some clever folks have come up with a draft spec for handling boot configuration in a shareable, cross-bootloader, cross-distro way.
I strongly endorse this product and/or service - bootloader configuration is a horrible mess and any attempt to make distros handle it better and more interoperably is a good thing. Every time we have a serious discussion of bootloader config the possibilities and use cases multiply until we wind up just throwing our hands up in the air. It's unmanageable.
The section "Why not simply rely on the EFI boot menu logic?" makes me very sad, but I can't argue with it: in the real world, efibootmgr seems to be being implemented so badly we can't just rely on it. Sigh.
One question arises that doesn't appear to be answered in your mail or in the spec: who is behind this so far? The spec deploys the word 'we' freely, without ever entirely defining who is currently included in 'we'. If we could get at least Fedora, Debian and Ubuntu on board with this, I think we'd have critical mass; adding Mint, SUSE and the Ma*a family would help.
I do think it might be worth being more firm about at least how multi-boot with Windows should work, it being such a very common case. Though I can see the argument that it's 'out of scope'.
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec
[I see no designated mechanism for feedback, so I'll try this one.]
After reading that spec (last edited 2013-02-14 21:36:10), I have these comments:
1. Indirection by one level should be supported, such as a file: $BOOT/loader/entries/my-purple-project.indir having the contents: directory //b098c68b69f54d21848176c25b44da36/purple/boot where b098c...da36 is the blkid of a filesystem, which the boot loader locates by exhaustive search. All .conf files in that directory are processed as if they appeared in $BOOT/loader/entries/ , except that any pathname contained in such a .conf file is interpreted in the context of the filesystem that has the named blkid.
Rationale: Updating the boot configuration for the running system never should require searching for the location which contains the .conf files. The answer always is some path which has the prefix "/boot/", whether that is a local directory or a mount point.
Part of the reason for the current mess involving boot loaders is the insistence that everything must be in one place that the boot loader controls. Instead, multiboot by chain loading is a useful option of GRUB1 (especially: chaining to another GRUB1 which is installed in the bootblock of a partition and manages only that partition), and the 'configfile' indirection feature of GRUB2 is very nice.
2. Filesystem type for $BOOT: Explicitly allow FAT12, FAT16, FAT32. Explicitly disallow FAT32X and NTFS because of complexity. ext4 is a headache because it requires more code. On disk, ext3 is the same as ext2 (assuming a clean unmount.) Obviously the boot loader should warn about dirty unmount (which for ext3 means that the journal will not be processed.)
3. It can be handy if .conf files are syntax-compatible with shell, so that they can be parsed and interpreted by ". file1.conf" or "source file1.conf", instead of having to write a loop: while read line; do set -- "$line"; case "$1" in title) ... ;; ... ;; esac done Problem areas often are: escaping, quoting, meta characters, continuation lines.
Regarding shell compatibility, it looks like the Boot Loader Spec might be aiming for having shell procedures title(), version(), etc. However, "machine-id" is not a shell identifier. Also, shell characters such as "\'"([{*?<>&$;" (backslash singlequote doublequote open leftsquare leftbrace star ask less greater amper dollar semi) should be quoted or escaped. Sharp '#' should begin a comment anywhere, not only first on a line.
4. Explicitly suggest a mechanism for inter-operating with the 'loader' of Microsoft Windows for non-EFI systems. There are many such systems, and they will persist for many years. If there is no explicit suggestion, then there will be different incompatible extensions, which will cause pain later.
Where does TCG OPAL support fit into this? I'm getting a strong sense of an almost complete lack of trust by OSS and TCG. But setting aside TPM, isn't it possible to support OPAL compliant SED drives? There are now consumer drives, and in particular SSDs, that implement this. It seems like a waste for the drive to always do encryption, and simply have no access for managing it, including lock/unlock.
Chris Murphy
On Fri, Mar 01, 2013 at 04:38:39PM -0700, Chris Murphy wrote:
Where does TCG OPAL support fit into this? I'm getting a strong sense of an almost complete lack of trust by OSS and TCG. But setting aside TPM, isn't it possible to support OPAL compliant SED drives? There are now consumer drives, and in particular SSDs, that implement this. It seems like a waste for the drive to always do encryption, and simply have no access for managing it, including lock/unlock.
The big henderance to using TCG Silos is suspend+resume - across a power reset the drive shuts down and needs to be re-authenticated with before we can see it again, which means some code has to be run from somewhere to get the PIN from the user to unlock it, but at the same time we have to not touch the disk to e.g. page anything in or load any new code. So you'd need to have a handler for that (that looks reasonable!) pinned in memory before suspending. That's kind of awful.
Until there's a good solution for that* means it's primarily useful for optional data drives, not a system disk.
* I know of one solution for it. It is as far from good as possible.
Honestly, I have to disagree deeply with this idea:
Note: $BOOT should be considered shared among all OS installations of a system. Instead of maintaining one $BOOT per installed OS (as /boot was traditionally handled), all installed OS share the same place to drop in their boot-time configuration.
This is really just begging on your knees for the various distros to stomp on each others bootloaders, or alternatively -- and just as badly -- not update the bootloaders at all.
It is way more robust to let each distribution have its /boot and worry about its own bootloader.
-hpa
--- On Tue, 3/12/13, H. Peter Anvin hpa@zytor.com wrote:
From: H. Peter Anvin hpa@zytor.com Subject: Re: Boot Loader Spec To: "Discussion of Development and Customization of the Red Hat Linux Installer" anaconda-devel-list@redhat.com Cc: "Lennart Poettering" lennart@poettering.net Date: Tuesday, March 12, 2013, 12:00 AM
Honestly, I have to disagree deeply with this idea:
Note: $BOOT should be considered shared among all OS installations of a system. Instead of maintaining one $BOOT per installed OS (as /boot was traditionally handled), all installed OS share the same place to drop in their boot-time configuration.
This is really just begging on your knees for the various distros to stomp on each others bootloaders, or alternatively -- and just as badly -- not update the bootloaders at all.
It is way more robust to let each distribution have its /boot and worry about its own bootloader.
-hpa
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
I happen to run 4 linux distributions on a common computer. I have noted that each kernel has a identification, indicating distribution, version, and some other informations. The fear of name collision can easily be handled by agreements, such as is done today.
A single boot partition will probably be installed on a separate SD, or could be integrated into the motherboard bios. The bios is a good place as the boot process is an infrequent activity. With UEFI, the bios boot partition makes sense to me.
On Mar 11, 2013, at 10:00 PM, H. Peter Anvin hpa@zytor.com wrote:
Note: $BOOT should be considered shared among all OS installations of a system. Instead of maintaining one $BOOT per installed OS (as /boot was traditionally handled), all installed OS share the same place to drop in their boot-time configuration.
This is really just begging on your knees for the various distros to stomp on each others bootloaders, or alternatively -- and just as badly -- not update the bootloaders at all.
They already do this now.
It is way more robust to let each distribution have its /boot and worry about its own bootloader.
This is what we have today. It's not robust.
Chris Murphy
On 03/13/2013 05:38 PM, Chris Murphy wrote:
On Mar 11, 2013, at 10:00 PM, H. Peter Anvin hpa@zytor.com wrote:
Note: $BOOT should be considered shared among all OS installations of a system. Instead of maintaining one $BOOT per installed OS (as /boot was traditionally handled), all installed OS share the same place to drop in their boot-time configuration.
This is really just begging on your knees for the various distros to stomp on each others bootloaders, or alternatively -- and just as badly -- not update the bootloaders at all.
They already do this now.
It is way more robust to let each distribution have its /boot and worry about its own bootloader.
This is what we have today. It's not robust.
It is quite robust if you disregard each and every distro trying to force you to install the bootloader in the MBR, which is yet another horrible practice. -hpa
anaconda-devel@lists.stg.fedoraproject.org