Contents
Summary
Simplify our supported boot configurations to reduce the test matrix, provide support for UEFI (not to be confused with Secure Boot) and GPT disk layouts and handle multiple operating system installs and bootloader entries gracefully and cooperatively.
Owner
- Name: Colin Guthrie
- Email: colin@mageia.org
Resources
Colin Guthrie (and hopefully some help from Thomas Backlund and Thierry Vignaud)
Current status
- Targeted release: Mageia 4
- Last updated: 2013-02-24
- Percentage of completion: 0%
Detailed Description
In Mageia 3 we supported four boot loaders (for various values of support!): lilo, grub-legacy, grub2 and (to a lesser extent) grub2-efi. We also shipped packages for gummiboot, although no direct integration with our tools was shipped. We currently have a series of scripts and tools (bootloader-utils and various code in drakx) to deal with boot loader configuration and installation. This is somewhat complex and error prone.
In various upstream tools (namely systemd and dracut) there has been a concerted effort to support a new structure of boot loader configuration that is detailed in the Boot Loader Specification. This proposal is about adopting as much as possible from this specification and simplifying our tools accordingly and collaborating with upstream when necessary.
In modern systems, the GPT partition format is used and UEFI boots from the ESP partition which is FAT32 format (FAT12 or FAT16 is also possible). In order to cut down on superfluous permutations of filesystem layouts and formats, this feature proposes in a default install we mandate a separate /boot partition and only allow it to be in FAT32 format on all systems (regardless of UEFI or BIOS boots). The 'Expert' installer mode would allow more control over the options (such as picking ext4 and, perhaps, btrfs filesystems for /boot), but there would still be much more restriction over what is possible than we offer currently. One primary example would be that if software RAID was selected, this would require a separate /boot (a setup currently allowed with some RAID configurations and lilo - although reports are mixed as to whether this works well - some report that grub is required for this etc. - currently all very muddy).
Although grub2 is written in a module fashion, it currently supports a large variety of filesystems for the /boot partition (including not having any /boot partition and even reading RAID disks). Having such a complex pre-boot environment just increases the test matrix and leads to complex support with very little practical gain to the user and a much larger overhead on QA. Whether or not we allow the installer to continue to support complex setups but warn the user they are using an "unsupported option" is a possibility here to maintain flexibility. We would of course try our best to keep things working but it means we can officially close such bug reports if the repercussions of such support are to onerous.
In modern systems, including those running Windows 8, an ESP partition of (typically) around 250-500MB is used to boot Windows. The ESP filesystem layout is such that other bootloaders and kernel images/diagnostic tools can co-exist happily to boot alternative operating systems when used in conjunction with the Boot Loader Specification. By using approximately the same layout for both UEFI and BIOS boots, we allow a sensible transition from legacy to modern environments and a more consistent installer experience.
Specifics
Bootloaders
It is proposed that the only supported boot loaders would be:
- grub2: For BIOS boots
- gummiboot: For UEFI boots
All other bootloaders would be no longer supported (it might be that they are still shipped but they will not be offered as an option in the installer).
grub2 should be patched to read it's configuration in the format as defined by the Boot Loader Specification. This is implemented as a module named "blscfg" in grub2 ("boot loader specification config"). This is a patch currently used in Fedora. gummiboot uses this format natively.
Kernel
The kernel would be modified to ship it's vmlinuz image outside of /boot.
At kernel install time the image would be copied to /boot (which in the case of UEFI boots would be the ESP partition. Note this is NOT mounted as /boot/EFI as is sometimes suggested in other schemes). The script /usr/bin/kernel-install (part of systemd) would be used to install the kernel image. This script supports a hooks system that makes it extensible.
Ramdisk
In order to automatically build an initial ramdisk when a kernel is installed, dracut ships hooks that work with the kernel-install script mentioned above.
Install
In non-expert mode, we would default to GPT layout, utilising a good sized ESP partition (for /boot) with GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B in FAT32. If MBR layout is used we should also create an ESP partition by default with type 0xEF also FAT32. This would be compliant with UEFI boots.
If Windows 8 is installed we should reuse the ESP partition that already exists.
If the user chooses expert mode, the disk partitioning will allow them to select alternative file systems for /boot, although this will restrict the user to legacy BIOS booting only; UEFI boot would require the setup chosen by default. The filesystem choice for /boot should still be restricted to FAT32, ext4 and (maybe) btrfs.
It is still open to debate as to whether the user should be allowed to configure a system (for fresh install) that does not have a /boot. Looking to the future with UEFI, it seems counter productive to cater for a non-/boot partition (ESP) world so it is my opinion we should look to phase this out sooner rather than later.
Upgrades
Upgrades are a bigger problem. We may need to include lilo and grub-legacy as options for upgraders. This does not mean we should still offer these options as first class citizens in the installer however. Migrating grub users to grub2 should certainly be investigated here. Ideally we'd migrate users away from both these options before upgrade as this will complicate the goal to exclusively use the Boot Loader Specification configuration file format.
Overall
The above structure means we can greatly simplify our handling of bootloaders. By using a common configuration scheme we do not need to treat grub2 or gummiboot differently and we can use upstream developed/maintained scripts and utilitys for handling kernel installation. The scheme allows for multiple installs (including multiple versions of the same operating system) to share the same ESP partition (kernel images and ramdisks are keyed on the "machine ID" i.e. /etc/machine-id) to avoid conflicts)
Why it would be good for Mageia to include it
Currently, the permutations of bootloader configurations is too high and causes unnecessary support overhead. We have a number of custom scripts and utilities that support a wide range of bootloader configurations which is both confusing to develop, understood by few people and is a bottleneck for supporting newer bootloaders capable of booting modern machines. By placing more restrictions on what is officially supported and adopting a common configuration format allows us to concentrate on more important parts of the distribution.
Test case
Make sure it boots!
Software / Packages Dependencies
As mentioned above, kernel packaging should change to not include anything directly in the /boot partition. When installing a new kernel package appropriate configs will be generated depending (regardless of whether grub or gummitboot is used) and kernels copied to (and ramdisks generated in) the appropriate locations on the /boot partition (typically within a subfolder representing the current machine-id to play nice with other operating systems which may co-exist on the same ESP partition).
What could disrupt development of this new feature
Bikeshedding and users complaining that this is a travesty and generally wanting us to support every single option under the sun.
Planning
We would need to decide on how we wish to package the kernel going forward and adjust the bootloader-utils package to act accordingly.
systemd would need to be configured to mount the ESP partition in /boot (which it does so upstream automatically as of v197). Certain tools would have to be configured to ignore ESP partition and NOT add it to /etc/fstab by default (and just let systemd do it). Due to VFAT format we need to ensure the fmask and dmask options are suitably restrictive to not allow regular users to read and manipulate the data on that partition.
Contingency
Continue to support lilo, grub, grub2 and gummiboot going forward and deal with a test matrix that is unnecessarily large.
