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
