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. -- 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: ${hyperkitty_url}
