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