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.
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.
On Fri, Jun 26, 2015 at 9:58 AM, Jonathan Billings billings@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.
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.
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.
At Fri, 26 Jun 2015 11:58:07 -0400 CentOS mailing list centos@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.
On 6/26/2015 12:38 PM, Robert Heller wrote:
At Fri, 26 Jun 2015 11:58:07 -0400 CentOS mailing list centos@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.
The only issue I have ever had is if / is not listed first. For some reason that I cannot remember I once listed /boot first in /etc/fstab and the system could not remount / as RW as the first thing mount did was mount /boot. Apparently it failed to recognize / needed a remount before mounting anything else.
-
Chris Murphy -
Jason Warr -
Jonathan Billings -
Robert Heller