[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-raid
Subject:    Re: Redundant EFI Systemp Partitions (Was Re: How does one enable SCTERC on an NVMe drive (and other
From:       Chris Murphy <lists () colorremedies ! com>
Date:       2021-06-28 3:59:20
Message-ID: CAJCQCtSmMPdK5AmJu-i-amhQBKV8Fqcix7HOTM+_Pn-Uj6Ggig () mail ! gmail ! com
[Download RAW message or body]

On Sun, Jun 27, 2021 at 8:21 PM Edward Kuns <eddie.kuns@gmail.com> wrote:
>
> On Sat, Jun 26, 2021 at 10:14 PM Chris Murphy <lists@colorremedies.com> wrote:
> > I think it's unreliable. GRUB can write to the ESP when grubenv is on
> > it. And sd-boot likewise can write to the ESP as part of
> > https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
> >
> > And the firmware itself can write to the ESP for any reason but most
> > commonly when cleaning up after firmware updates. Any of these events
> > would write to just one of the members, and involve file system
> > writes. So now what happens when they're assembled by mdadm as a raid,
> > and the two member devices have the same event count, and yet now
> > completely different file system states? I think it's a train wreck.
>
> It sounds like the least risky option is just manually creating more
> than one ESP and manually syncing them periodically as Andy Smith
> mentioned.  (Or automatically syncing them upon every boot.)
>
>                 Eddie

I'd like to say we are definitely better off with stale ESPs
occasionally being used, than corrupt file systems. That's probably
almost always true.  But since fallback to another ESP can be silent,
without the benefit of any information from the pre-boot environment
ending up in the system journal to know which ESP booted the system,
it might be false comfort.




-- 
Chris Murphy
[prev in list] [next in list] [prev in thread] [next in thread]