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@l.d.o or to pkg-grub-devel@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
Attachment:
pgpZL5IYlX4rj.pgp
Description: PGP signature