On Fri, Jul 29, 2022, at 5:25 AM, Lennart Poettering wrote: > On Fr, 29.07.22 00:21, Peter Boy (pboy@xxxxxxxxxxxxx) 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. The built-in FAT driver is rw. The efifs drivers (via GRUB) are ro. Yes it's a terrible idea. I've mentioned this many times elsewhere it's come up. I'm not sure whether the loophole to use mdadm RAID1 for ESP is still in Anaconda. Originally it was added, as I understand it, because a RHEL customer requested it. > 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. Intel IMSM format is supported by Linux software RAID. You can use Intel firmware RAID a.k.a. fake-RAID for this. Or any firmware RAID using a format supported by mdadm including DDF. Otherwise, right now, the sync use case is in bootupd's court. > 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. Yep. Software RAID to increase uptime following failure is OK. But degraded boot is fraught with problems and unreliability. I don't think it should be a requirement for any Fedora product. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure