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
On Fri, Jun 26, 2015 at 10:54:07AM -0600, Chris Murphy wrote:> 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.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. -- Jonathan Billings <billings at negate.org>
On Fri, Jun 26, 2015 at 8:47 PM, Jonathan Billings <billings at negate.org> wrote:> On Fri, Jun 26, 2015 at 10:54:07AM -0600, Chris Murphy wrote: >> 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. > > 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.it doesn't seem like there's any advantage, especially with rEFInd which unlike the RH/CentOS/Fedora GRUB2 method right now, doesn't need to update anything on the ESP ever. The two disadvantages: https://bugzilla.redhat.com/show_bug.cgi?id=1077917 https://bugzilla.kernel.org/show_bug.cgi?id=92721 It's a bad practice, and I wish the distros would stop being neurotic about mounting everything just because it can be mounted.> 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.The Windows installer is expected to modify the ESP and NVRAM in its favor. The RH/CentOS/Fedora installer does the same thing, with the only supported configuration in Fedora being Fedora installed after Windows, not the reverse. I didn't think dual-boot was supported at all by RHEL or CentOS. So what's likely happening is: a. the ESP//EFI/BOOT/BOOTX64.EFI file is being stepped on by the Windows installer and replaced with the Windows bootloader since this path is the fallback bootloader position. Normally for dual boot systems this is a copy of shim.efi, I'm not sure what does this with rEFInd installations, if it's also shim.efi (likely) or a copy of rEFInd.efi. b. the NVRAM boot order is changed to favor Windows. So chances are all you have to do is change the boot order using efibootmgr. If you use # efibootmgr -v So long as the boot order points to shim.efi and things are set so that shim.efi points to rEFInd, rEFInd itself doesn't care about or depend on NVRAM contents. But NVRAM has to provide an initial path that results in rEFInd getting loaded. -- Chris Murphy