How to do manual multi-boot configuration with Fedora

Source

One thing that always seems to be a pain point with Linux distributions and installers is handling multi-boot. There are some fairly notorious cases, and a lot more less commonly-considered ones which people making distributions and installers nevertheless have to consider.

Prior to Fedora 18, you could install Fedora's bootloader to a partition header, which was useful for a multi-booting strategy known as chainloading, where a 'master' bootloader in the MBR could 'chainload' slave bootloaders installed to partition headers. From Fedora 18 onwards this is no longer possible through the Fedora installer UI. However, there are other ways you can configure a manual multi-boot setup, and I thought it might be useful to write some of them down.

Setting up chainloading manually

Yes, you can actually still achieve a chainloading setup when doing an interactive installation of Fedora, it just takes a bit more work. It's crucial to know that, during Fedora installation, you can always access a root console on tty2 with 'ctrl-alt-f2'. You have a fairly complete environment, and if the installation has reached a point where the filesystem for the installed system has been created and mounted, you can access it at /mnt/sysimage. So our strategy here is simply to tell Fedora not to install a bootloader, complete the installation, and then do the bootloader installation ourself.

  1. Begin Fedora installation as usual.
  2. Enter the Installation Destination spoke.
  3. Click on Full disk summary and bootloader... at the bottom left
  4. Select the disk with a check and click Do not install bootloader
  5. Click Close, and proceed with installation as desired
  6. When installation is complete and Fedora tells you to reboot, don't! Instead hit ctrl-alt-f2, and run the following commands:
  7. chroot /mnt/sysimage
  8. echo "GRUB_DISABLE_OS_PROBER=true" >> /etc/default/grub
  9. grub2-install --no-floppy --force /dev/sda1
  10. grub2-mkconfig -o /boot/grub2/grub.cfg

Now we're done with the Fedora side of things. It's safe to reboot from the installer. Boot to the OS that owns the 'master' bootloader, on the MBR. Now we just need to add an entry to the configuration of the 'master' bootloader, assuming it's grub2. You may also want to run echo "GRUB_DISABLE_OS_PROBER=true" >> /etc/default/grub on the 'master' OS: what this command does is prevent grub2-mkconfig using its automatic multi-boot smarts, where it tries to add entries for other installed OSes to the bootloader configuration. If the OS that controls the configuration for your master bootloader uses grub2-mkconfig to update its configuration file, you should add the new entry to /etc/grub.d/40_custom (or similar - its location may differ between distros) then re-generate the config file.

menuentry "Fedora (chainload)" {
    insmod ext2
    insmod chain
    set root=(hd0,msdos1)
    chainloader +1
}

(hd0,msdos1) is the first partition on the first hard disk (unless it's GPT-labelled, in which case it would be (hd0,gpt1)) in grub2 lingo. If you installed Fedora somewhere else and wrote the Fedora bootloader somewhere else, of course, adjust accordingly. You can use something like search --set=root --fs-uuid=[UUID] --hint hd0,msdos1 directive instead of set root to set the partition by UUID, if you like.

That should be all! Now, booting the system should show you a Fedora (chainload) entry which will load Fedora's bootloader, from which you can of course boot Fedora.

Setting up configfile inclusion manually

If your 'master' bootloader is grub2, you can use an alternative approach known as configfile inclusion. It works very similarly to chainloading, only instead of actually loading the 'slave' bootloader, the master copy of grub2 just reads a different configuration file. So instead of actually installing a 'slave' OS's grub2 to a partition header, we just make sure each slave OS has a grub2 config file, and adjust the 'master' grub2's configuration accordingly.

  1. Begin Fedora installation as usual.
  2. Enter the Installation Destination spoke.
  3. Click on Full disk summary and bootloader... at the bottom left
  4. Select the disk with a check and click Do not install bootloader
  5. Click Close, and proceed with installation as desired
  6. When installation is complete and Fedora tells you to reboot, don't! Instead hit ctrl-alt-f2, and run the following commands:
  7. chroot /mnt/sysimage
  8. echo "GRUB_DISABLE_OS_PROBER=true" >> /etc/default/grub
  9. grub2-install --no-floppy /dev/sda1 --grub-setup=/bin/true
  10. grub2-mkconfig -o /boot/grub2/grub.cfg

Now we're done, and we can reboot and edit the 'master' bootloader's configuration file. You will notice these steps are almost identical to the chainloading guide. The change is small, but crucial: passing --grub-setup=/bin/true to grub2-install causes it not to actually write the bootloader to the target location, but do everything else it would usually do, including set up some fonts and modules and things that we need. The grub2-mkconfig step, of course, creates the configuration file we will later chainload.

As per the chainloading guide, you may want to run echo "GRUB_DISABLE_OS_PROBER=true" >> /etc/default/grub on the 'master' OS, and you will probably want to add the new entry to /etc/grub.d/40_custom (or similar - its location may differ between distros) then use grub2-mkconfig to re-generate the config file.

menuentry "Fedora (configfile)" {
    insmod ext2
    set root=(hd0,msdos1)
    configfile /grub2/grub.cfg
}

Again, this is very similar to the chainloading example, except we're using the configfile directive instead of chainload. That should be all! Now, booting the system should show you a Fedora (configfile) entry which will load Fedora's bootloader configuration file from the 'master' copy of grub2, from where you can of course boot Fedora.

The Future

Well, I hope that was useful. I'm hoping for Fedora 21 we can set it up so that choosing not to install a bootloader still generates a configuration file, rather than skipping all bootloader setup entirely. That would make this easier - all you'd have to do is edit the configuration of the 'master' bootloader. But we have to consider whether there are use cases for completely skipping bootloader configuration - not even generating a configuration file - first. Knowing this topic...there probably are. (If you know of any, please shout.)

Comments

Paul Bolle wrote on 2014-01-09 10:14:
Recent versions of LVM support embedding a bootloader area (see man pvcreate). And there is an ioctl for ext4 (added in kernel v3.10) to "store a boot loader in a secure part of the filesystem". The LVM option seems complete. The ext4 seems to be just one step in the right direction. I've tested neither. And I'm not aware of any bootloader actually using their functionality. But perhaps, in some distant future, it will be easier and safer to install a bootloader in a partition (eg, drop the grub2-install --force option for LVM and ext4).
kparal.wordpress.com/ wrote on 2014-01-09 10:44:
Thanks for the writeup. Now I would be interested in a similar guide for dual-booting two Fedora installations using UEFI and the same ESP :-)
adamw wrote on 2014-01-09 18:12:
kamil: I don't think it's actually that difficult, you'd just have to take a note of the first install's efibootmgr entry, do the second install, then re-create the first install's efibootmgr entry with a different name. The only thing from the first install that is nerfed by the second is the efibootmgr entry, AFAIK.
kparal.wordpress.com/ wrote on 2014-01-10 10:00:
I just tested it, it's far from that. You need to a) rename or backup 'fedora' efibootmgr entry b) rename /boot/efi/EFI/fedora directory all in advance. After second fedora installation (in which you need to mount existing ESP as /boot/efi), you need to c) recreate previous efibootmgr entries (giving a different name to either the first or second installation) d) fix /boot/efi/EFI/* (either keeping the renamed entry for the previous installation, or revert the name change and rename the second installation instead) e) change /etc/grub2-efi.cfg symlinks for point to correct location in both installations, depending on your changes in d)
David De Graaf wrote on 2014-02-01 19:19:
Adam, thank you for writing this desperately needed documentation on dual booting. You make it look easy. Unfortunately, it's incomplete. :-) I would greatly appreciate your advice on two additional aspects: 1) How to deal with LUKS encryption. 2) How to migrate from a single shared unencrypted boot partition with encrypted multiple roots, home and swap, to the preferred configuration where boot is part of each root's encrypted filesystem. Please explain how the "unusual" logic used in the F20 boot process to decrypt the several filesystems will apply. See my bugzilla report 1058385, especially comment 2. I assume there would be a single unencrypted partition which, for lack of a better name, may be called "grub", plus other fully encrypted partitons including (at least) two root partitions that contain their respective /boot subdirectories. That implies that all the decryption mechanism resides in the grub partition, which perforce, includes no knowledge of anything about the several root systems, their contents, and especially their /etc/crypttab data. Perhaps I'm just dense, but I cannot see how to get there from here.
adamw wrote on 2014-02-01 20:41:
Um, sorry, but I honestly don't really know what you're talking about. I don't know why you describe "boot is part of each root’s encrypted filesystem" as "the preferred configuration" - it wouldn't be *my* preferred configuration, I wouldn't ever want /boot to be part of an encrypted FS, that just seems like an invitation to disaster. There's no sensitive data in /boot. I also generally don't muck about with 'migrating' installations in this kind of way, because it always seems to go wrong. I have a very fundamentalist approach to system deployment, personally - I figure out how I want it to be and then I do it and then I leave it alone. :P The way I have my infrastructure set up, my client machines are kinda disposable, so I don't get too wedded to any particular OS deployment. so, I'm afraid I'm not sure I can offer you much help. The only intent of this post was to describe how to do the two 'chained boot' style setups with Fedora's installer; I honestly tend to stay away from configs as complex as you describe, and don't have a lot of experience with them.
adamw wrote on 2014-02-01 20:42:
In case it's not clear: I guess if I was trying to do this kind of chained multiboot style with multiple OSes that I wanted to have encrypted root partitions, I'd just give each of them its own separate unencrypted boot partition, and install each one's 'client' bootloader to that partition.