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