While we want to make GPT the default partitioning, we want to ensure with all probs with GPT and BiosBoot software Raid that it works on UEFI systems, too.
Testcase 1 (former just testcase)
Test 1-1 Reboot the system. Expected result: The system starts without problems
Test 1-2 Detach each disk one at a time and reboot (simulating a one disk failure). Expected result: The system starts nevertheless without issues.
Testcase 2
Test 2-1 Reboot the system, system boots without warning. Expected result: The system starts without problems
Test 2-2 Disk sdb detached (the one with efi partition w/o mount point) Result: system starts up with sda
Test 2-3 Disk sda detached (the one with efi partition with mount point) Result: system not bootable (No Bootable Device Detected! Please reboot and check)
Testcase 3
Test 3-1 Reboot the system, system boots without warning. Expected result: The system starts without problems * Disk sda includes 3 partitions (boot/efi; boot; LVM), sdb 2 partitions (boot; LVM) as configured.
Test 3-2 Detached sdb (with just 2 partitions) system boots w/o complains, but needs a lot longer to complete booting.
Test 3-3 Detached sda (with 3 partitions incl. efi) Message "No Bootable Device Detected"
Metadata Update from @pboy: - Issue tagged with: in progress
Rawhide 2022-06-21 Both tests passed successfully
Fedora 36 Both tests passed successfully
Step 2 is unnecessary, the installer properly wipes all selected disks from prior signatures.
./blivet/formats/init.py:571: rc = run_program(["wipefs", "-f", "-a", self.device])
Step 7 is not an acceptable way of making an EFI System partition per upstream mdadm developers. First, it makes the type of partitions mdadm raid members, not EFI System. Using the EFI partition type GUID for them is wrongly typing them; whereas making them Linux RAID partition type GUID means some firmware could (properly) ignore them. Second the EFI System partition can legitimately be written to by the firmware and EFI programs, and in such a case it makes the file systems on the two mirrors out of sync, and since those writes happen outside of md RAID, it's completely ambiguous which blocks are correct. Doing an md scrub check will show the two partitions are out of sync (check mismatches).
It's technically untenable as well as unsupported upstream. Allowing users to create it should be removed from the installer because it sets the wrong expectations, as if this is a valid layout. It's actually fragile and won't consistently work as users expect.
I have extended the test cases and gone through all the available variations.
According to the warnings Anaconda issues, Anaconda explicitly expects that in the case of boot on a raid, efi should also be on a raid device.
Didn't the Anaconda developers read the specs? Rather unlikely.
So the question is, how do we want to proceed?
Metadata Update from @pboy: - Issue tagged with: meeting
Metadata Update from @pboy: - Issue untagged with: meeting
Issue tagged with: in progress
Log in to comment on this ticket.