RAID1 & UEFI: support for twin ESPs in GRUB

[D. Jared Dominguez]

On Sun, Jan 24, 2016 at 09:29:27AM -0600, Francesco Poli wrote:
>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

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.

--Jared