Re: RAID1 & UEFI: support for twin ESPs in GRUB
On Sun, Jan 24, 2016 at 09:29:27AM -0600, Francesco Poli wrote:
Hello again Debian EFI support developers, hello GRUB Debian package
I would like to go on with my effort to enhance the support for UEFI
machines with software RAID setups.
Summary of previous episodes
In order to let a UEFI machine with two (or more) drives in software
RAID1 (or higher RAID levels) boot correctly even when only one (or the
minimum number of) drive(s) is working, there must be one ESP partition
per drive, each with the same content and one boot option per drive set
This can be done manually (and works correctly), but, at each
grub-efi-amd64 upgrade, only the first ESP is updated and only the
corresponding efibootmgr boot option is kept. The other ESPs must be
taken care of by hand, which is boring and error-prone.
My goal is to prepare a patch for source package grub2 that will
automate these tasks. As usual, any help is welcome.
More details in my previous messages:
N.B.: bug #784070 has been fixed in the meanwhile, so mdadm is again
able to cope with missing drives without manual intervention on the
I began looking at source package grub2 in order to pinpoint the parts
that need to be changed. From a first glance, it seems to me that:
• the debian/postinst.in script should be modified (in its grub-efi*
specific segment) so that a suitable debconf configuration option is
available for the user to list the ESP mount points to be taken care of
(such as /boot/efi , /boot/efi2 , /boot/efi3 , ...); for each ESP,
grub-install should be invoked with appropriate --bootloader-id=ID and
• since grub-install internally invokes efibootmgr wiping any
pre-existing boot option (corresponding to the same bootloader-id) and
then adding an appropriate boot option, it might be necessary to also
modify util/grub-install.c and add a command-line option to disable the
wiping (or maybe --no-nvram may be used and then efibootmgr should be
invoked directly by debian/postinst.in ?): this is needed for any
grub-install invocation not meant to take care of the "first" ESP
( /boot/efi )
Please note that this is just a first design attempt: any comments on
Once I begin to prepare the patch, I will of course want to build the
resulting binary packages.
I usually build Debian packages with pbuilder and then perform some
routine tests with my hook scripts.
By the way, if anyone is interested, they are available here:
One of my scripts (TestInst_pdeb) tries to
install/upgrade/downgrade/remove/purge the built packages.
My question is: is there any problem in installing grub2 binary
packages inside a pbuilder-managed chroot environment? Will they
attempt to mess up with the MBR (grub-pc) or the EFI boot options
(grub-efi*) and break the chroot environment and/or the actual host
Another issue is, of course, testing the resulting binary packages.
I think I should use a virtual machine to test grub packages, in order
to avoid the risk to damage my real system.
I would like to use KVM, but I am a KVM newbie.
Any suggestions on which packages I should install and on how to create
a virtual UEFI machine with two drives where I can run the
debian-installer and install the grub-efi-amd64 packages I will build?
I will read https://wiki.debian.org/KVM (and possibly other recommended
documentation), but, besides that, is anyone willing to give me any
Thanks to anyone reading so far (wow! this message became longer than
expected!). Any help will be welcome and highly appreciated.
P.S.: I am not subscribed to firstname.lastname@example.org or to
email@example.com, so please CC me on replies.
Thanks for your understanding!
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
I believe that, even if you were to implement this, there needs to be
clarity from the UEFI forum on what the expected, spec-compliant
behavior is when there are multiple ESP's, especially since I doubt it
is well tested. Without this information, anything Debian might
implement ends up as just a hack, and bugs mostly would end up actually
being differences in implementation that no BIOS vendor would actually
consider a bug.