grub-install should handle /boot/efi on RAID1

Bug #1765484 reported by Kees Cook
58
This bug affects 12 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)
Confirmed
Undecided
Unassigned

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

Remote bug watches

Bug watches keep track of this bug in other bug trackers.