How to do manual multi-boot configuration with Fedora

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.)

7 Responses

  1. Paul Bolle
    Paul Bolle January 9, 2014 at 2:14 am | | Reply

    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).

  2. kparal.wordpress.com/
    kparal.wordpress.com/ January 9, 2014 at 2:44 am | | Reply

    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 :-)

  3. David De Graaf
    David De Graaf February 1, 2014 at 11:19 am | | Reply

    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.

You can comment without reCAPTCHA by using an OpenID as the URL, or logging in with an OpenID or an old site account.

Leave a Reply