As discussed on our meeting I created an issue (https://pagure.io/fedora-server/issue/89) for this matter. According to my tests, software raid is working with uefi booting.
On Fri, Jul 1, 2022 at 2:12 AM Peter Boy pboy@uni-bremen.de wrote:
As discussed on our meeting I created an issue (https://pagure.io/fedora-server/issue/89) for this matter. According to my tests, software raid is working with uefi booting.
I added a comment to the article, https://pagure.io/fedora-server/issue/89#comment-804315 that employing Linux RAID 1 on the EFI System partition is not an acceptable way of syncing EFI system partitions. The only way it could be reliable is if you can guarantee no writes to the file system outside of the kernel's md driver, which is not certain. The firmware has write access, as do EFI programs and those exist outside the Linux RAID driver leading to out of sync EFI System partitions.
I have added all available variants to the test cases.
Judging from the warning messages Anaconda issues, Anaconda explicitly expects that both boot loaders (stage 1 and stage 2) should be on a raid each (or none).
The Anaconda developers will have read the technical specs as well, I think.
How should we proceed here? What solutions are available and which one do we want to aim for?
Am 01.07.2022 um 17:35 schrieb Chris Murphy lists@colorremedies.com:
On Fri, Jul 1, 2022 at 2:12 AM Peter Boy pboy@uni-bremen.de wrote:
As discussed on our meeting I created an issue (https://pagure.io/fedora-server/issue/89) for this matter. According to my tests, software raid is working with uefi booting.
I added a comment to the article, https://pagure.io/fedora-server/issue/89#comment-804315 that employing Linux RAID 1 on the EFI System partition is not an acceptable way of syncing EFI system partitions. The only way it could be reliable is if you can guarantee no writes to the file system outside of the kernel's md driver, which is not certain. The firmware has write access, as do EFI programs and those exist outside the Linux RAID driver leading to out of sync EFI System partitions.
-- Chris Murphy _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@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/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sun, Jul 3, 2022 at 5:25 PM Peter Boy pboy@uni-bremen.de wrote:
I have added all available variants to the test cases.
Judging from the warning messages Anaconda issues, Anaconda explicitly expects that both boot loaders (stage 1 and stage 2) should be on a raid each (or none).
The Anaconda developers will have read the technical specs as well, I think.
My understanding is it was done for a RHEL customer, but it's still not at all supported by upstream mdadm developers and not recommended.
How should we proceed here? What solutions are available and which one do we want to aim for?
Unfortunately there is no recommended work around. About the best we have is bootupd.
https://github.com/coreos/bootupd
About the best that can be done is documentation that recommends the sysadmin manually create an ESP on each RAID member. Then copy the "canonical" ESP's contents, the one mounted at /boot/efi, to each of the ESPs. While those additional ESPs will not ever have their shim and GRUB bootloaders updated when the canonical one is updated, it should still work as a fallback booth method should the drive containing the canonical ESP fail.
More for reference than really arguing that anyone should use it, here is an attempt I made at scripting essentially what Chris recommended.
https://github.com/gregory-lee-bartholomew/bootsync
I actually do use it on a few of my Fedora Linux systems. Unfortunately, it relies on systemd-boot instead of grub. So it is probably a no-go for being included in Fedora Linux, at least for now. Also, there is a race condition in the current version where it sometimes fails because the A/B partitions aren't mounted yet when it tries to "rsync" the contents between them. I think fixing that is just a matter of adding something to one of the Before= or After= settings on the systemd unit. But I haven't traced down that problem just yet.
Am 06.07.2022 um 22:24 schrieb Gregory Bartholomew gregory.lee.bartholomew@gmail.com:
More for reference than really arguing that anyone should use it, here is an attempt I made at scripting essentially what Chris recommended.
Sorry for my late reply. My current Fedora activities are filling my time frame more than anticipated and unfortunately I can no longer reliably respond in a timely manner.
I studied your script and I think it is very well crafted - eventhough you don't think it is ready for use yet.
I have never dealt with that problem before and am still trying to figure out exactly where the problems are and what to do.
As far as I can see, the synchronization is done with standard file operations, nothing outside the file system. Accordingly, the required contents are also distributed to the disks by Raid. So the contents are in place.
An obvious issue is the type of the partition containing efi content, which is raid with the Fedora (server) solution. Fedora (server) takes care of that, obviously, and performs additional checks if it detects raid. As soon as you try to dual- or even multi-boot with other systems, it will almost certainly end up faulty. From a mere sysadmin perspective, I could hardly care less as long as Fedora (server) compensates. I don't want any other inhabitants on my hardware.
From a systematic perspective this is quite dissatisfying. And from a pragmatic perspective I would use it as long as it works and there is no better solution.
server@lists.fedoraproject.org
-
Chris Murphy -
Gregory Bartholomew -
Peter Boy