[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Support for mirroring of EFI System Partition



On Sat, 12 Sep 2015 11:05:28 +0200 Francesco Poli wrote:

> On Thu, 10 Sep 2015 00:19:25 +0100 Steve McIntyre wrote:
> 
> > On Mon, Sep 07, 2015 at 12:17:27AM +0200, Francesco Poli wrote:
[...]
> > >  b) my idea would be that, if the first ESP is to be mounted
> > >on /boot/efi , maybe we could mount additional ESPs
> > >on /boot/efi2 , /boot/efi3 , and so forth; at that point, whenever an
> > >upgrade of grub-efi-amd64 has to change something on the ESP mounted
> > >on /boot/efi, it should repeat the same actions on each additional ESPs
> > >mounted on /boot/efi2 , /boot/efi3 , and so forth; of course, it should
> > >check that an ESP partition is actually mounted on each mount point,
> > >before proceeding to update its content; is this feasible/reasonable?
> > 
> > For simplicity, I'd be more tempted to just use the existing /boot/efi
> > instance and then sync changes across to the other copies at the point
> > when writeback is needed.
> 
> The problem is: if one ESP is considered to be the "master" one, and
> the other ESPs are "slave" ones, kept in sync with the "master", what
> happens when the drive hosting the "master" ESP breaks?
> The system should be able to boot from one "slave" ESP (assuming boot
> priorities are set with efibootmgr), but it won't be able to
> mount /boot/efi (since the fstab will refer to the inaccessible
> "master" ESP); at that point, if an upgrade of grub-efi-amd64 has to be
> performed before the dead drive is replaced, a new "temporarily-master"
> ESP has to be found and selected, mounted on /boot/efi, its content
> updated, and any remaining ESPs (if present) have to be synced to this
> "temporarily-master" ESP...
> 
> This sounds really complicated and fragile, I think.
> 
> Instead, if all ESPs are mounted on distinct mount points
> (/boot/efi , /boot/efi2 , /boot/efi3 , and so forth) and updated
> independently, there should be no need for special tricks whenever one
> of them is inaccessible (and thus not mounted).
> 
> Please tell me if my reasoning makes sense to you or, otherwise,
> explain where I am being naive.

Please clarify whether my reasoning is flawed...

[...]
> > >  e) is there anything else missing?
> > 
> > It's quite likely that we'll find broken UEFI firmware implementations
> > that will get this all wrong.
> 
> Even for boot priorities on multiple ESPs?!?
> If this is the case, it looks like a major regression with respect to
> BIOS times, where one would just install GRUB on multiple MBRs and be
> fine!    :-(

Could someone please elaborate on the fragility of UEFI?

> 
> > I'm not sure how well most are likely to
> > deal with actual hardware failure. We'll find out, I guess... :-)
> 
> That's not comforting!  :-(
> 
> What I can do to test the setup, is (at most) try to boot with one
> drive disconnected and see what happens.
> One thing's sure: I will *not* intentionally break one drive [1], just
> to test how the UEFI firmware implementation deals with actual hardware
> failure!
> 
> 
> [1] how, by the way? with a hammer?!?   ;-)




-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgp1brm7cSOW0.pgp
Description: PGP signature


Reply to: