On Fri, Jun 15, 2018 at 4:42 PM, Kyle Marek <psppsn96@xxxxxxxxx> wrote: > On 06/15/2018 06:35 PM, Chris Murphy wrote: >> On Fri, Jun 15, 2018 at 3:58 PM, Tom Hughes <tom@xxxxxxxxxx> wrote: >>> On 15/06/18 22:50, Jason L Tibbitts III wrote: >>>>>>>>> "KM" == Kyle Marek <psppsn96@xxxxxxxxx> writes: >>>> >>>> KM> I can't remember what else I discovered in reading the manual >>>> KM> last. Do you know if there are any other discovery/identification >>>> KM> limitations to the old superblocks? >>>> >>>> I don't think there are any in the context of having a small RAID1 ESP >>>> across not too many devices. The 0.9 format which anaconda uses is >>>> limited to 28 devices (and 4TB, but that's obviously not a problem). I >>>> don't really see why it couldn't use the 1.0 format, really. There is >>>> no difference between the 1.0, 1.1 and 1.2 formats besides the location >>>> on the disk. >>> >>> I have a machine that has a raid1 md for the ESP using 1.0 metadata >>> and it's never caused any problems. >>> >>> I didn't realise the installer did it automatically now though - that >>> machine was setup when the installer wouldn't even let you do it >>> manually so I had to set it up as raid post install. >> >> It doesn't do it automatically. In custom partitioning, it will allow >> you to create a contradictory thing: >> 1. Partitions on multiple devices with a partition type GUID claiming >> those partitions are an ESP >> 2. Superceding superblock metadata that claims those partitions are >> not ESPs, but are mdadm member devices. >> 3. Mounting an assembled software RAID as an ESP. >> >> It's clever. But it's a departure from the UEFI spec, and mdadm >> upstream. It's also not an agreed upon layout among the distros, so >> it's not compatible among them for multiboot, and in the case of >> Windows dual boot, it'll almost immediately result in one of the ESPs >> becoming out of sync with the others. >> >> Anytime one of the member devices is written to outside of the array, >> md raid1 more or less randomly chooses which block is correct. So you >> can actually end up with a totally unbootable system with both (fake) >> ESPs totally corrupted by the sync process, where left alone unsynced, >> both are valid working ESPs even if one might be stale. >> >> So it's a bad hack. I've only been around this donkey show 19 times, >> and putting something this (at best ambiguously) dangerous in a GUI >> installer is a misfeature. You want to put it behind an "oh my fuck >> these are badass but very dangerous options" reveal? Super. That's >> better. At least there's a disclosure. But I'm still opposed to this. >> Why? >> >> Because as a bad hack, it's "good enough" and it pushes back the need >> to develop the right thing by alleviating the urgency. > > Interesting points. > > Is Windows existing on the same drives as a Linux software RAID a > non-hypothetical occurrence? I don't know. It might be a bad example. Windows installed before Fedora means a pre-existing ESP, which Fedora's installer will not non-destructively turn into an mdadm raid1 member device. You'd have to be willing to have that ESP wiped in favor a raid1 ESP, and then do a repair for Windows which would then fix up the bootloader on that ESP outside the raid, causing an ambiguous state that mdadm can't fix up. Windows installed after Fedora would not see the mdadm superblock, it'd see it as an VFAT ESP, and would result in the same outcome as a Windows bootloader repair. Installing Windows after Fedora isn't something we test or support or recommend. It's always a Windows is installed first expectation. I guess the take away would be, the various ways an ESP could get written to outside of the assembled md-RAID is not thoroughly explored, but could happen, and if it happens, it's bad news. md can't help you get out from that situation and very likely makes things much worse. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/Y3ERYFQTFP3IFCFXAEGYTPG7A7KOKQJY/
