On Fri, Jun 26, 2015 at 8:47 PM, Jonathan Billings billings@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.