rfc: EFI System partition, FAT32, repair and non-persistent mount

Przemek Klosowski przemek.klosowski at nist.gov
Thu Mar 20 16:32:33 UTC 2014


On 03/20/2014 01:21 AM, Chris Murphy wrote:
> On Mar 19, 2014, at 7:51 PM, Adam Williamson <awilliam at redhat.com> 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.
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.

I agree with you that nothing else but UEFI should mount those devices 
as  individual plain volumes, of course.
>
> Because 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.
It is a darn useful side effect. How else can you implement redundant 
boot that is transparently updated? I could (and did) try
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140320/1afc1e05/attachment.html>


More information about the devel mailing list