|
On 03/20/2014 01:21 AM, Chris Murphy
wrote:
Right, but UEFI doesn't write to it----it just uses them to read the boot content. It would be better if UEFI could read software raid1 even if it was degraded due to disk failures, but apparently it can't, so Adam's scheme is the only possibility.On Mar 19, 2014, at 7:51 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote:On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote:More complex than trying to mirror a FAT ESP partition across multiple boot disks, keeping it properly synchronized, because RAID isn't supported?You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because of how RAID-1 works; each individual member can also be mounted as if it was just a plain old partition, which is how the firmware will mount it.This shouldn't be done. It's a source of corruption to treat an md raid1 device as a plain volume, rather than as a degraded md device. If the plain partition volume is modified, its mdadm metadata won't be updated, so when the array is finally assembled, mdadm has no idea member devices are not sync'd, and also has no way to resolve the ambiguity. I agree with you that nothing else but UEFI should mount those devices as individual plain volumes, of course. It is a darn useful side effect. How else can you implement redundant boot that is transparently updated? I could (and did) tryBecause of this, at least one raid stack kernel maintainer wants to do away with the use of mdadm metadata v 1.0 by anaconda. It's v1.0 metadata that permits this plain old partition treatment as a side effect. multiple /boot partitions on separate drives by copying the partition content after updates, but it was fragile and I was never confident that it would work when I needed it. Adam's raid1 /boot just seems more reliable, especially if it became a designed feature. |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
