Timothy Murphy gayleard at eircom.net Tue Jun 23 12:49:08 UTC 2015> > Do most people today have /boot on a separate partition, > or do they (you) have it on the / partition ?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>Not only do I have a /boot partition, but I have a /boot/efi partition.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 probably could get away without using the /boot partition, but I've > been experimenting with btrfs and snapshots and it makes sense to keep > /boot as an ext4 filesystem.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.>I suspect with the move to XFS it might be a good idea to keep an ext4 /boot too.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. -- Chris Murphy
On Thu, Jun 25, 2015 at 01:27:47PM -0600, Chris Murphy wrote:> 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.I've never once had a problem with nested mounts. Is this a problem people have? First I've heard of it.> 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.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. -- Jonathan Billings <billings at negate.org>
On Fri, Jun 26, 2015 at 9:58 AM, Jonathan Billings <billings at negate.org> wrote:> On Thu, Jun 25, 2015 at 01:27:47PM -0600, Chris Murphy wrote: >> 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. > > I've never once had a problem with nested mounts. Is this a problem > people have? First I've heard of it.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.> >> 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. > > 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.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. -- Chris Murphy
At Fri, 26 Jun 2015 11:58:07 -0400 CentOS mailing list <centos at centos.org> wrote:> > On Thu, Jun 25, 2015 at 01:27:47PM -0600, Chris Murphy wrote: > > 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. > > I've never once had a problem with nested mounts. Is this a problem > people have? First I've heard of it.'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.> > > 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. > > 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. >-- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller at deepsoft.com -- Webhosting Services