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