On Fri, Jun 15, 2018 at 5:48 PM, Kyle Marek <psppsn96@xxxxxxxxx> wrote: > But you are certainly right that any non-read-only access on the ESP > outside of the context of Linux md is going to lead to corruption. I > would think that read only access (reading the .efi file) should be > safe, right? Writing outside of md won't itself cause corruption. It just causes the ESPs to mismatch. The corruption will happen upon md having no way of resolving the mismatches, and feeding conflicting file system metadata to the vfat driver. These reads, without any write, can be corrupt, let alone subsequent writes back to the array, which for sure will corrupt both member devices in such a case. Ostensibly the firmware should only be doing reads, but the UEFI spec does permit writes by the firmware. > On the topic of diverging from EFI specification: Is there any > "appropriate" way to provide a redundant ESP (without firmware RAID) > under the current specification? Sure. I mentioned several. The gist is that any program modifying an ESP is burdened with modifying all related ESPs in a multiple device redundant boot setup, making sure they each have the prescribe updates. I would say they are burdened with knowing they need to mount the ESPs in sequence, modify them in sequence, and unmount them in sequence. Neither the ESP, nor separate boot volumes, should be persistently mounted. That is certainly true on Windows and macOS. Those things are for booting. The only reason why we persistently mount those things read/write left dangling in the wind all day long is because the programs/packages that update those volumes aren't made smart enough to exclusively own those volumes: mount them when needed, modify them correctly, and then unmount them when no longer needed. Now, systemd does handle this mounting and unmounting of a single device's single ESP on demand as part of discoverable partitions spec. But it only supports this on the path /efi or /boot. So the ESP needs to be mounted at either /efi or /boot it can't be at /boot/efi because systemd doesn't support, and they don't want to support, and it's completely rational to not support, nested mounts like this. But anyway, it would need to be extended to support the multiple device (RAID) boot case, and probably makes more sense to have either a systemd service or a daemon that can do this so programs don't have to invent this particular wheel themselves every time. Just point the updates to a directory, maybe even use the existing /boot/efi as that directory instead of as an ESP mountpoint, and the service does the mount, sync, umount of each ESP in the background. i.e. mount to a location in /run/mount and make sure /boot/efi and /run/mount/<uuid> are the same for each ESP and then umount them when done. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/NRNDITVWFDRX2YRVARWDI2P3KUQBU7GS/
