RAID1 & UEFI: support for twin ESPs in GRUB

[Francesco Poli]

Hello again Debian EFI support developers, hello GRUB Debian package
maintainers,
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
with efibootmgr.
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:
https://lists.debian.org/debian-efi/2015/09/msg00000.html
https://lists.debian.org/debian-efi/2015/09/msg00005.html
https://lists.debian.org/debian-efi/2015/10/msg00003.html
https://lists.debian.org/debian-efi/2015/10/msg00017.html

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


Way forward
-----------

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
--efi-directory=DIR options

 • 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
this?


Questions
---------

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:
http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
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
system?


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
hint?


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 debian-efi at l.d.o or to
pkg-grub-devel at l.a.d.o, so please CC me on replies.
Thanks for your understanding!


-- 
 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20160124/fcb2f2d8/attachment.sig>