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

Re: Support for mirroring of EFI System Partition

On Mon, Sep 07, 2015 at 12:17:27AM +0200, Francesco Poli wrote:
>Stefan and Jared for their followups.
>So, if I understand correctly, I am basically left with two options:
>  * enable the CSM backward compatibility mode, so that my box appears
>    to the OS as if it were BIOS-based (assuming my box supports this
>    mode, I haven't yet checked!)

That's *an* option, but not one I'd recommend to be honest. Newer
systems shipping already don't have CSM, and you'd be stuck.

>  * have the box boot in UEFI mode and run the Debian Installer, create
>    the partitions I need while setting up the software RAID1 and create
>    two identical EFI System Partitions on the two drives; then try and
>    help you to modify grub-efi-amd64 so that multiple ESPs are well
>    supported
>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.

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

>  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

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

>  e) is there anything else missing?

It's quite likely that we'll find broken UEFI firmware implementations
that will get this all wrong. I'm not sure how well most are likely to
deal with actual hardware failure. We'll find out, I guess... :-)

Steve McIntyre, Cambridge, UK.                                steve@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll

Reply to: