From blibbet at gmail.com  Sat Jan 30 19:12:56 2016
From: blibbet at gmail.com (Blibbet)
Date: Sat, 30 Jan 2016 16:12:56 -0800
Subject: [Fw_Os_Forum] Fwd: RAID1 & UEFI: support for twin ESPs in GRUB
Message-ID: <56AD5188.70209@gmail.com>

Hi,

Francesco has a question about using more than one ESP with UEFI,
[related to RAID usage,] with a boot loader (such as GRUB).

The original question was posted to the Debian-EFI mailing list, but
this impacts more than just Debian, other OSes may need to address it,
hopefully in similar ways.

Apologies if I missed it, but I didn't see this addressed in the UEFI
spec. It should be, so this would not have come up, because Francesco
would have read it in the spec.

I think Francesco may be intimidated to use the FW_OS_Forum w/o some
help, so I'm forwarding it to the list, please forgive me. :-)

Could someone from the UEFI Forum please help out with Francesco's
question?

He is not subscribed to FW_OS_Forum list, so please CC him.

Besides original message below, there is a little bit more techincal
background on the Debian-EFI thread:
https://lists.debian.org/debian-efi/2016/01/msg00016.html

Thanks,
Lee
RSS: http://firmwaresecurity.com/feed

-------- Forwarded Message --------
Subject: RAID1 & UEFI: support for twin ESPs in GRUB
Resent-Date: Sun, 24 Jan 2016 15:29:49 +0000 (UTC)
Resent-From: debian-efi at lists.debian.org
Date: Sun, 24 Jan 2016 16:29:27 +0100
From: Francesco Poli <invernomuto at paranoici.org>
To: Debian EFI <debian-efi at lists.debian.org>, GRUB Debian package
maintainers <pkg-grub-devel at lists.alioth.debian.org>

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!