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

Re: Support for mirroring of EFI System Partition



On Tue, 15 Sep 2015 23:54:36 +0200 Francesco Poli wrote:

> 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...

I am trying hard to address this issue, but I need some explanations:
that's why I would like to discuss my ideas...
Please help me to help you!

> 
> [...]
> > > >  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?

Once again, is there anyone willing to explain a little more about this?

> 
> > 
> > > 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: pgpb9f_UgwLUM.pgp
Description: PGP signature


Reply to: