Bug#913576: Update to grub-efi-amd64 2.02~beta3-5 results in "error: efibootmgr failed to register the boot entry: Operation not permitted."

bkw+1542031175 at 70mpg.org bkw+1542031175 at 70mpg.org
Mon Nov 12 14:23:54 GMT 2018


Package: grub-efi-amd64
Version: 2.02~beta3-5+deb9u1
Severity: critical

Today, I ran "apt-get -f dist-upgrade" to upgrade a server from Debian 
GNU/Linux 9.5 to the latest 9.6 release.   One of the packages that got 
upgraded was grub-efi-amd64.  During the upgrade, I got the following 
output/error:

Setting up grub2-common (2.02~beta3-5+deb9u1) ...
Setting up grub-efi-amd64 (2.02~beta3-5+deb9u1) ...
Installing for x86_64-efi platform.
efibootmgr: option requires an argument -- 'd'
efibootmgr version 14
usage: efibootmgr [options]
	-a | --active         sets bootnum active
	-A | --inactive       sets bootnum inactive
	-b | --bootnum XXXX   modify BootXXXX (hex)
	-B | --delete-bootnum delete bootnum
	-c | --create         create new variable bootnum and add to bootorder
	-C | --create-only	create new variable bootnum and do not add to 
bootorder
	-D | --remove-dups	remove duplicate values from BootOrder
	-d | --disk disk       (defaults to /dev/sda) containing loader
	-r | --driver         Operate on Driver variables, not Boot Variables.
	-e | --edd [1|3|-1]   force EDD 1.0 or 3.0 creation variables, or guess
	-E | --device num      EDD 1.0 device number (defaults to 0x80)
	-g | --gpt            force disk with invalid PMBR to be treated as GPT
	-i | --iface name     create a netboot entry for the named interface
	-l | --loader name     (defaults to \EFI\redhat\grub.efi)
	-L | --label label     Boot manager display label (defaults to "Linux")
	-m | --mirror-below-4G t|f mirror memory below 4GB
	-M | --mirror-above-4G X percentage memory to mirror above 4GB
	-n | --bootnext XXXX   set BootNext to XXXX (hex)
	-N | --delete-bootnext delete BootNext
	-o | --bootorder XXXX,YYYY,ZZZZ,...     explicitly set BootOrder (hex)
	-O | --delete-bootorder delete BootOrder
	-p | --part part        (defaults to 1) containing loader
	-q | --quiet            be quiet
	-t | --timeout seconds  set boot manager timeout waiting for user 
input.
	-T | --delete-timeout   delete Timeout.
	-u | --unicode | --UCS-2  pass extra args as UCS-2 (default is ASCII)
	-v | --verbose          print additional information
	-V | --version          return version and exit
	-w | --write-signature  write unique sig to MBR if needed
	-y | --sysprep          Operate on SysPrep variables, not Boot 
Variables.
	-@ | --append-binary-args file  append extra args from file (use "-" 
for stdin)
	-h | --help             show help/usage
grub-install: error: efibootmgr failed to register the boot entry: 
Operation not permitted.
Failed: grub-install --target=x86_64-efi --force-extra-removable
WARNING: Bootloader is not properly installed, system may not be 
bootable
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
Found linux image: /boot/vmlinuz-4.9.0-7-amd64
Found initrd image: /boot/initrd.img-4.9.0-7-amd64
Adding boot menu entry for EFI firmware configuration
done
Setting up grub-efi (2.02~beta3-5+deb9u1) ...

It should be noted, that when this server was built, it was built with 
two hard drives in a RAID 1 mirror.  To install the EFI successfully 
into the RAID mirror, the following command was run to create the EFI 
partitions:

"mdadm --create /dev/md0 --metadata 1.0 --raid-devices=2 --level=1 
/dev/sd[ab]1"

The above command was run because mdadm defaults to metadata version 1.2 
and in version 1.2 the metadata is located at the beginning of the 
device, with an offset of 4kb. With that, UEFI can't see a valid fat32 
partition. But, with metadata version 1.0 the superblock is located at 
the end of the RAID partition, so the UEFI bios see a plain FAT32 
partition with esp and boot flags.

I'm not sure if this related to the grub-efi error, or not, but I wanted 
to point it out.

Additionally, looking at /boot/efi/EFI, I see that new EFI images were 
created, so, I'm not clear as to what really failed.

root at 5018a:~# ls -la /boot/efi/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 139264 Nov 12 07:35 
/boot/efi/EFI/BOOT/BOOTX64.EFI
root at 5018a:~# ls -la /boot/efi/EFI/debian/grubx64.efi
-rwx------ 1 root root 139264 Nov 12 07:35 
/boot/efi/EFI/debian/grubx64.efi

This server is a Supermicro 5018A-LTN4.
I am using Debian GNU/Linux 9.5 (for this upgrade to 9.6), kernel 
4.9.0-8-amd64 and libc6 2.24-11.

Any help will be much appreciated.  At this point, I'm afraid to reboot 
this server, for fear that it won't boot up.

Thanks!



More information about the Pkg-grub-devel mailing list