grub-install should handle /boot/efi on RAID1

Bug #1765484 reported by Kees Cook
This bug affects 11 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)

Bug Description

I am using grub-efi. I have /boot/efi as a RAID1 with metadata=1.0 at the _end_ of the partition so it can still be seen by UEFI boot firmware as a FAT32 filesystem. grub-install calls efibootmgr with and empty -d argument:

efibootmgr -c -d "" ...

since it can't figure out what drive /boot/efi is on. With grub-pc, when /boot was on a RAID1, grub-install would get run via the grub-pc postinst for each component of the raid (and/or as a list presented to the user via debconf).

For example, with this:

# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[2] sdb1[0]
      524224 blocks super 1.0 [2/2] [UU]

if /dev/md0 was mounted on /boot, grub-pc's postinst would run grub-install on /dev/sda and /dev/sdb.

In the UEFI case, if /dev/md0 is mounted on /boot/efi, I would expect efibootmgr to be run multiple times for each component:

efibootmgr -c -d /dev/sda1 -L ubuntu-sda1 ...
efibootmgr -c -d /dev/sdb1 -L ubuntu-sdb1 ...

Dunno about boot ordering, etc. I'm not actually using efibootmgr currently. As a work-around, I ran "dpkg-reconfigure -p low grub-efi" and disabled the NVRAM setting in debconf (to avoid efibootmgr failing grub-install and causing package installs/upgrades to fail).

Revision history for this message
Kees Cook (kees) wrote :

The error, specifically, is:

Installing for x86_64-efi platform.
efibootmgr: option requires an argument -- 'd'
grub-install: error: efibootmgr failed to register the boot entry: Operation not permitted.
Failed: grub-install --target=x86_64-efi
WARNING: Bootloader is not properly installed, system may not be bootable

Phillip Susi (psusi)
affects: grub2 (Ubuntu) → grub-installer (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in grub-installer (Ubuntu):
status: New → Confirmed
Revision history for this message
Alejandro Mery (amery) wrote :

so what are the instructions needed to mimic grub-install? :)

Revision history for this message
Alejandro Mery (amery) wrote :

also, what exactly did you do on `dpkg-reconfigure -p low grub-efi-amd64` to disable the broken call to `efibootmgr`?

Revision history for this message
Alejandro Mery (amery) wrote :

grub-install --force --target=x86_64-efi /dev/md127
grub-install --force --recheck /dev/md127
efibootmgr -c -D -L "Ubuntu (sdb)" -d /dev/sdb -p1 -l /EFI/ubuntu/grubx64.efi
efibootmgr -c -D -L "Ubuntu (sda)" -d /dev/sda -p1 -l /EFI/ubuntu/grubx64.efi

did the trick for me, but grub-efi-amd64-signed and shim-signed are persistently pending to finish the installation, and every time dpkg attempts to do it the efibootmgr changes mentioned above get wiped and they need to be re-run to be able to continue booting... not a very reliable way of getting a system booting reliably

Revision history for this message
Osmin Lazo (osminlazo) wrote :

Adding --no-nvram to grub-install

grub-install --efi-directory=$mntpoint --target=x86_64-efi --no-nvram

fixes this, the --no-nvram bypasses updating efi vars with efibootmgr but this entries don't need to be modified after install and on every grub pkg update.

Modifying this line in /usr/lib/grub/grub-multi-install will allow the grub pkg update to complete succesfully...

The error seems to be caused by the efibootmgr command using mduuid of raid.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers