/boot On A Separate Partition?

Home » CentOS » /boot On A Separate Partition?
CentOS 7 Comments

Timothy Murphy gayleard at eircom.net Tue Jun 23 12:49:08 UTC 2015

Different distros have different defaults. There’s no actual right or wrong here. Pretty much anything you can think of can be made to work.

Jonathan Billings billings at negate.org Tue Jun 23 13:28:18 UTC 2015

It’s bad design. First, it’s a nested mount: file system A on /, and file system B on /boot, and file system C on /boot/efi. Therefore the mount process must make sure they’re mounted in that order, or there’s failure. Second, there is no good reason for the EFI System partition to ever be mounted; and multiple reasons to not ever mount it (Windows and OS X never mount the EFI System partition but somehow all the Linux distros are obsessed with mounting things that don’t need mounting). Eventually systemd will become smarter and handle on-demand dynamic mount and umount, including the ESP so this will get better but even better would be not ever mounting it in the first place.

I disagree, yet I’m curious what example you have that this makes sense.

This ext4 /boot is unique to F/C/RH’s dependency on grubby which doesn’t grok Btrfs subvolumes, and therefore kernel updates don’t get written to grub.cfg properly if /boot is on a Btrfs subvolume. GRUB, including grub2-mkconfig figures out subvolumes just fine. It’s specifically a limitation of RH distros. Ubuntu and openSUSE don’t have this problem.

There’s no advantage to it being ext4. The default installation for Fedora 22 Server, CentOS/RHEL 7 is /boot on XFS, and / on a separate XFS, and /home on a separate XFS. Just like with ext4, except with XFS.

7 thoughts on - /boot On A Separate Partition?

  • This might work until the different OS installations start arguing about the version of grub/grub2 and the contents of the grub configuration file (including whose grub configuration files to use). They tend to do this during kernel updates and at other times.

    Having grub take over your main boot choice is as silly as Windows assuming it is the only OS installed.

    I have long preferred to use a single / partition for each OS
    installation and put the system specific grub image in the individual partition. I use the 1 sector (MBR) FreeBSD bootloader to boot the partition I want at boot time. Note that grub2 doesn’t like this and spews an error message, but it does work (mostly) (grub2 needs to be fixed to support this functionality and not assume it can become the master boot process).

    This does tend to limit you to 3 OS choices in the primary partitions
    (assuming a 4th extended partition for data partitions). That usually is enough for my purposes.

    With EFI systems, this is changing and my experiences are not complete enough to have strong opinions. It does look like the EFI boot process conceptually handles this by letting the user choose which EFI
    application to load first (using efimanager). EFI disk based booting does still need the DOS formatted partition often mounted at

    For booting encrypted systems, I do put /boot in separate partitions
    (with the corresponding / being an extended partition). I still use a separate MBR boot loader to select which /boot I use.


  • I’ve never once had a problem with nested mounts. Is this a problem people have? First I’ve heard of it.

    It would be nice if that were the case, however, in an automated dual-boot system with EFI, we have to manage rEFInd *somewhere*, and it is easier for us to manage it under configuration management in Linux than in Windows. Our managed dual-boot workstations need to be able to reboot into the other OS during the evening for updates.

  • You can’t have an automount point nested on an automount point. Namely
    /boot in this case, which for the same reasons should also not be persistently mounted.

    This makes no sense to me. rEFInd dynamically discovers linux kernel updates, it doesn’t need any regular configuration file changes. Once you configure it, it’s a static configuration file unlike grub.cfg or extlinux.conf.

    So why do you need /boot/efi persistently mounted? You don’t even need what GRUB users ought to have which is fstab using mount options noauto,x-systemd.automount for /boot/efi.

  • At Fri, 26 Jun 2015 11:58:07 -0400 CentOS mailing list wrote:

    ‘mount -av’ has *long* supported nested mounts. Nested mounts are a ‘trick’
    from the days of UNIX from way back when. Mount knows all about going through
    /etc/fatab and coming up with a sane and correct order for mounting file systems.

  • The only issue I have ever had is if / is not listed first. For some reason that I cannot remember I once listed /boot first in /etc/fstab and the system could not remount / as RW as the first thing mount did was mount /boot. Apparently it failed to recognize / needed a remount before mounting anything else.

  • Surprisingly enough, we actually like to ensure the rEFInd configuration is correct, and it isn’t like it is hurting anyone to have it mounted. Its a managed system, users don’t get root access.

    Also, we have been seeing Win7 mucking around with the EFI partition post-install, so it helps to make sure things are correct, although typically what happens is Windows makes it so it is the only boot option, and preempts rEFInd, and Linux never even gets a chance to run.