<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/20/2014 01:21 AM, Chris Murphy
wrote:<br>
</div>
<blockquote
cite="mid:8A653CD9-CC4A-419D-A1FD-C18D24798723@colorremedies.com"
type="cite">
<pre wrap="">
On Mar 19, 2014, at 7:51 PM, Adam Williamson <a class="moz-txt-link-rfc2396E" href="mailto:awilliam@redhat.com"><awilliam@redhat.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
More complex than trying to mirror a FAT ESP partition across multiple
boot disks, keeping it properly synchronized, because RAID isn't
supported?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
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.<br>
<br>
I agree with you that nothing else but UEFI should mount those
devices as individual plain volumes, of course.<br>
<blockquote
cite="mid:8A653CD9-CC4A-419D-A1FD-C18D24798723@colorremedies.com"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
It is a darn useful side effect. How else can you implement
redundant boot that is transparently updated? I could (and did) try<br>
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.<br>
<br>
</body>
</html>