[CentOS] /boot on a separate partition?

[Chris Murphy]

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