On Fr, 29.07.22 00:21, Peter Boy (pboy@uni-bremen.de) wrote:
One is not really supposed to have multiple ESPs
I have another question regarding multiple ESPs, maybe a bit off-topic. For software raid we currently have a kind of „off-label use“. Anaconda puts the ESP on a raid partition (and the /boot partition as well) and so the partition is marked as RAID and not as ESP. I know, there are several alternatives in development to synchronise ESP partitions, but none is included in Anaconda. And maybe none of the alternatives is ready for production. How does this fit into the plans being discussed here? It is an important issue for Fedora Server.
That's a terrible idea. UEFI file system drivers are read/write. sd-boot makes use of that even, to implement boot counting/automatic fallback (which I am sure is stuff you *really* want in attended systems that shall be able to safely come back when rebooted).
Given that firmware and uefi programs can and do write through the official sanctioned UEFI APIs to the ESP using RAID on ESP is a really bad idea — unless the firmware also implements your flavour of RAID. But it would be news to me that firmwares exist that support Linux software RAID natively.
ESP is defined the way it is, you cannot reinvent its storage underpinnings without breaking the other players that might access the ESP, i.e. firmware, boot loaders, other dual boot OSes. If you want to replicate the ESP, do so by synchronizing contents from userspace maybe. But even that is unreliable, since you can't necessarily trust mtimes there, to figure out what is newer...
I mean, my understanding is that you want to increase reliability by having a working ESP around on multiple disks. But by doing such off-label use stuff you just create problems for yourself that decrease realiability.
Lennart
-- Lennart Poettering, Berlin