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? _______________________________________________ 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/H3JPNYSITIQS2X4KOSEGIEX7Y75BPFTG/
