On Fri, Jul 29, 2022, at 5:25 AM, Lennart Poettering wrote:
> On Fr, 29.07.22 00:21, Peter Boy (p...@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. 

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to