Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mar 18, 2014, at 6:19 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:

> On Tue, 18.03.14 15:07, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:
> 
>>> Fedora takes a different approach though, and will mount an explicit
>>> boot partition to /boot and the ESP to /boot/efi, and do so
>>> unconditionally without involving autofs.  Fedora could add
>>> "x-systemd-automount" to the mount options of /boot/efi, and thus
>>> turning /boot/efi into an autofs too.
>> 
>> When I add x-systemd.automount to fstab for /boot/efi, it still gets
>> mounted on every boot. 
> 
> Ah, yeah sorry, forgot to mention, you need to also add "noauto" to the
> line. If it is "auto" we'll still wait for the mount unit to complete.
> 
> Basically, combining x-systemd.automount + auto is just a away to speed
> up boot by fscking in the bg while the mount point is already
> established. After boot the file system will be mounted as if
> x-systemd.automount hadn't been used.
> 
> Combining x-systemd.automount + noauto however is a way to establish a
> mount point and only lazily triggering it on access. And that's what you
> want to use here.

That does work. It's automounted on any command I threw at it, including kernel install, update, or remove. It's a bit half-hearted of a solution for the problem, since it doesn't umount the volume. But since the usual case is that it wouldn't be accessed except for a kernel update (due to the overwriting of grub.cfg), after which a reboot follows, it's seems like a decent short term work around.

RFE: Do not persistently mount EFI System partition at /boot/efi 
https://bugzilla.redhat.com/show_bug.cgi?id=1077984

It's still better to remove the on-going writing of configuration files to the ESP, however. A simple one-time forwarding-configuration file pointing to the /boot volume UUID, permits configuration files to be written somewhere on /boot, which can then be md raid1 or btrfs raid1 based. Boot is made more resilient whether single or multiple disk. This works today on BIOS, but not on UEFI.

Chris Murphy

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux