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: [...] > >Please let me understand, in case I decide to follow the second option: > > > > a) what's the recommended size for an ESP? (I found inconsistent > >suggestions on the web, from 1 Mibyte to 200 Mibyte!) > > The absolute minimum size that d-i will let you use for the ESP is > 35MiB, based on parted filesystem options. The minimum size I'd use > personally is ~200MiB, but the Wikipedia UEFI article suggests 512MiB, > and that's what we offer by default when doing guided partitioning. As > Stefan says, it really depends on what you're likely to need to put in > the ESP. OK, so probably 540 Mbyte = 515 Mibyte will be on the safe side. Thanks for the explanation. > > > 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. > > > c) who is going to add the other fstab entries? should this be done > >manually by the user? or is there a recommended mechanism to add those > >entries automatically? > > > > d) there should be a debconf setting for grub-efi-amd64, where the > >user may choose which ESPs have to be kept updated (this is similar to > >the corresponding setting in grub-pc); maybe this same setting should > >also use efibootmgr to set the boot priorities accordingly (first the > >primary ESP, then the additional ones); is this possible and a good > >idea? > > That sounds like it should work, yes. We'll need to work out a good > clear way of describing what's going on so that users will understand > it. :-) Yep, the debconf template should be clear (although concise), so that the user may make an informed decision. > > > 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! :-( > 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:
pgpqQuJalnhOq.pgp
Description: PGP signature