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

[Miloslav Trmač]

2014-03-19 5:31 GMT+01:00 William Brown <william at firstyear.id.au>:

> On Tue, 2014-03-18 at 21:39 -0600, Chris Murphy wrote:> 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.
>
> Why not also extend this to /boot also? It's "rarely" used in day to day
> on a system, really only for yum updates that include a kernel.
>

Well, why not also extend this to any rarely-used directory like perhaps
/usr/share/zoneinfo, or even any top-level directory?

   - It doesn't make anything easier (well, it does in Chris' RFE under the
   assumption that the partition is frequently being corrupted, but that
   shouldn't be happening in the first place; unlike /boot/efi we do have the
   technology to minimize these occurrences for other partitions).
   - It makes the system more complex and more difficult to understand.
   - The auto-mounting also requires system resources, probably quite
   comparable to keeping the partition simply mounted.
   - Problems with the filesystem could go undetected for a long time.
    This is especially problematic for /boot, consider (admittedly the worst
   case)
      - The /boot metadata or journal becomes corrupted (by a disk error,
      or an errant write)
      - If the kernel used to boot isn't directly affected, the system will
      continue to boot
      - After a few weeks, the user initiates a kernel upgrade, triggering
      an auto mount and a journal replay that makes the metadata corruption
      visible and problematic, perhaps making it impossible to boot even the
      *old* kernel

    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140319/4cc52e79/attachment.html>