Thread (10 messages) flat view 10 messages, 5 authors, 2021-06-28

Re: Redundant EFI Systemp Partitions (Was Re: How does one enable SCTERC on an NVMe drive (and other install questions))

From: Chris Murphy <hidden>
Date: 2021-06-27 03:13:37

On Sat, Jun 26, 2021 at 8:36 AM Phil Turmel [off-list ref] wrote:
quoted
You could lie to the firmware and tell it that each MD member device
is an ESP, but it isn't. This will probably work as long as you use
the correct metadata format (so the MD metadata is at the end and
the firmware is fooled that the member device is just a normal
partition). BUT it is in theory possible for the firmware to write
to the ESP and that would cause a broken array when you boot, which
you'd then recover by randomly choosing one of the member devices as
the "correct" one.
Pretty low risk, I think, but yes.  If you construct the raid with what
the EFI system thinks as the "first" bootable ESP as member role 0,
mdadm will sync correctly.  Fragile, but generally works.
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.



-- 
Chris Murphy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help