grub-install: Operation not permitted

Bug #1872212 reported by JN
162
This bug affects 34 people
Affects Status Importance Assigned to Milestone
grub2-signed (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I'm using Ubuntu 20.04 beta, upgraded from 19.10.
When doing the last upgrade I got an error message from grub.

When I run ›dpkg-reconfigure shim-signed‹ I get this error:

Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.

Since then I didn't reboot, for I'm afraid it won't work.

Revision history for this message
Michael.G. (michael.g.) wrote :

Upgraded 19.10=>20.04lts beta with do-release-upgrade -d, today. Got two times an ASCII window warning message like "grub failed to install. If you continue, your system might not boot". Continued anyway and the system still boots.

However, I can reproduce the error in console now via sudo grub-install -v --target=x86_64-efi --recheck /dev/sda resulting in:
      grub-install: (...)
      grub-install: info: Registering with EFI: distributor = `ubuntu', path = `\EFI\ubuntu\shimx64.efi', ESP at hostdisk//dev/sda,gpt1.
      grub-install: warning: Internal error.
      grub-install: error: failed to register the EFI boot entry: Operation not permitted.

This post seems related and points to efivarfs: https://unix.stackexchange.com/questions/379774/grub-installation-failed
The EFI firmware in my case is Hyper-V (WS2016 host).

Hope, this helps.

Revision history for this message
kadamcd (kadamcd) wrote :

I also had faced same issue in xubuntu 20.04 installation.

Revision history for this message
Alexei Lozovsky (ilammy) wrote :

I have experienced the same issue with Ubuntu 19.04, 19.10, and 20.04 installers. The system does not boot after the error message. Setting "efi_no_storage_paranoia" from [1] does not seem to help and the syslog does not seems to contain useful info other than the "Operation not permitted" error.

[1]: https://unix.stackexchange.com/questions/379774/grub-installation-failed

Revision history for this message
Oliver Goepfert (ophioparma) wrote :

I've git the same issue wit a fresh install of Lubuntu 20.04

Revision history for this message
Alexei Lozovsky (ilammy) wrote :

After some experiments and meditation on the process I have found the reason for the installation error in my case.

Somehow -- most likely due to my mistake -- the EFI system partition (ESP) switched to being a logical partition. However, UEFI needs it to be a primary partition. Since I've already broken other OS installations on the machine, I have recreated ESP as a primary partition and Ubuntu 20.04 installed fine after that.

I guess it may be a good idea to add a warning to the partition dialog if such situation is detected.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in grub2-signed (Ubuntu):
status: New → Confirmed
Revision history for this message
RB (roger-boezio-2) wrote :

Had the same error message installing Ubuntu 20.04.1. Following Alexei Lozovsky's advice above, I made my EFI partition the first partition on the disk, and also made it a primary partition as opposed to a Logical partition within an extended partition, and the installation completed successfully. (My disk is still MBR partitioned, but I am using UEFI).

Revision history for this message
Svisstack (svisstack) wrote :

This bug also affecting me, after upgrade the server is in reboot loop because first kernel is crashing or does not exist, I must select manually other kernel. After each upgrade there is same error that grub cant be upgraded.

Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.

Revision history for this message
Dariusz Kolasinski (offcer) wrote :

Same result here, hypervisor: Hyper-V.
Partition table: GPT

Here is command dpkg uses to upgrade grub:
root@host ~ # grub-install --efi-directory=/boot/efi --target=x86_64-efi /dev/sda
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.

Here is the same command with: --no-nvram

root@host ~ # grub-install --efi-directory=/boot/efi --target=x86_64-efi --no-nvram /dev/sda
Installing for x86_64-efi platform.
Installation finished. No error reported.

It looks like it is related to Hyper-V.

I`ve tried to use dpkg-reconfigure grub-efi-amd64 to set update_nvram false, but dpkg is still not using the --no-nvram flag:

root@host /var/lib/dpkg # debconf-show grub-efi-amd64 | fgrep nvram
* grub2/update_nvram: false

Revision history for this message
Alex (a-t-page) wrote :

This just happened to me during a "routine" upgrade of a 20.04 system.

Setting up grub-efi-amd64-signed (1.142.9+2.04-1ubuntu26.7) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.

A window pops up:

    GRUB failed to install to the following devices:
    /dev/nvme0n1p1
    Do you want to continue anyway? If you do, your computer may not start up properly.
    Writing GRUB to boot device failed - continue?

(saying "no" just loops back to the same screen)

grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.

This is the last info line before the error when manually running grub-install:

grub-install: info: Registering with EFI: distributor = `ubuntu', path = `\EFI\ubuntu\shimx64.efi', ESP at hostdisk//dev/nvme0n1,gpt1.

No idea what to expect when I reboot.

Revision history for this message
Artur (pieniadz532) wrote :

Just happened for me too, on a 20.04 kubuntu system.

apt upgrade output:
Setting up grub-efi-amd64-signed (1.142.9+2.04-1ubuntu26.7) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.

Window popped up too. Manual grub-install fails in the same way that apt installation does:
# grub-install
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.

According to /var/log/apt/history.log those grub packages were upgraded:
grub-common:amd64 (2.04-1ubuntu26.6, 2.04-1ubuntu26.7)
grub2-common:amd64 (2.04-1ubuntu26.6, 2.04-1ubuntu26.7)
grub-pc:amd64 (2.04-1ubuntu26.6, 2.04-1ubuntu26.7)
grub-pc-bin:amd64 (2.04-1ubuntu26.6, 2.04-1ubuntu26.7)
grub-efi-amd64-bin:amd64 (2.04-1ubuntu26.6, 2.04-1ubuntu26.7)
grub-efi-amd64-signed:amd64 (1.142.8+2.04-1ubuntu26.6, 1.142.9+2.04-1ubuntu26.7)

Did not yet try to restart the PC either.

Revision history for this message
Artur (pieniadz532) wrote :

Possible duplicate of bug #1901650 - as suggested, adding --no-nvram switch worked:

# grub-install --no-nvram
Installing for x86_64-efi platform.
Installation finished. No error reported

Machine boots fine, however i do not know if it would have booted before running the command above.

Revision history for this message
Night Train (nighttrain) wrote :

The same thing as Alex (a-t-page) after a normal grub packages update:

grub-pc_2.04-1ubuntu26.7_amd64.deb...
grub2-common_2.04-1ubuntu26.7_amd64.deb...
grub-pc-bin_2.04-1ubuntu26.7_amd64.deb...
grub-efi-amd64-signed_1.142.9+2.04-1ubuntu26.7_amd64.deb...
grub-efi-amd64-bin_2.04-1ubuntu26.7_amd64.deb...
grub-common_2.04-1ubuntu26.7_amd64.deb...

Configuration of grub-efi-amd64-signed (1.142.9+2.04-1ubuntu26.7)...
Trying to migrate /boot/efi into esp config
Installing grub to /boot/efi.
Installation for platform x86_64-efi.
grub-install: notice: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permited.

Did not yet try to restart the PC either.

Ubuntu 20.04.1 new installation
grub on nvme

The previous grub update gave no error.

What can I do?

Revision history for this message
Alexander Weber (lllalexanderlll) wrote :

Same here as Alex (a-t-page) and Night Train (nighttrain).
But with another Ubuntu on a different drive and partition:

Setting up grub-pc (2.04-1ubuntu26.7) ...
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-53-generic
Found initrd image: /boot/initrd.img-5.4.0-53-generic
Found linux image: /boot/vmlinuz-5.4.0-52-generic
Found initrd image: /boot/initrd.img-5.4.0-52-generic
Found Windows Boot Manager on /dev/sdb2@/EFI/Microsoft/Boot/bootmgfw.efi
Found Ubuntu 18.04.5 LTS (18.04) on /dev/sdb5
Adding boot menu entry for UEFI Firmware Settings
done
Setting up software-properties-qt (0.98.9.3) ...
Setting up grub-efi-amd64-signed (1.142.9+2.04-1ubuntu26.7) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.
Installing grub to /var/lib/grub/esp.
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.

System:

lsb_release -d
Ubuntu 20.04.1 LTS

Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-53-generic
OS Type: 64-bit

Revision history for this message
Ben McCann (ben-mccann) wrote :

Me to. I upgraded all out-of-date packages and the grub-efi-amd64-signed upgrade failed as shown above. This was an *upgrade* on bare metal (A Ryzen 3600 on a B550 motherboard) that had been booting just fine prior to this error. The '--no-nvram' work-around prevents the error but I have no idea if UEFI has been configured correctly.

FWIW, the efibootmgr program displays rational looking EFI entries:

sudo efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002
Boot0000* ubuntu
Boot0002* Windows Boot Manager

and the grub update does install new (or at least touch) the files in /boot/efi/EFI/ubuntu.

I'm about to reboot this machine to see whether my home file server is borked or not :-(

Revision history for this message
Ben McCann (ben-mccann) wrote :

I have the same issue on bare metal (Ryzen 3600 on B550 MB) and --no-nvram also disables the error message by, presumably, *not* updating the EFI boot entries in NVRAM.

This was a working install and efibootmgr looked reasonable after attempting to upgrade grub-efi-amd64-signed:

[deneb:~]$ sudo efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002
Boot0000* ubuntu
Boot0002* Windows Boot Manager

However, and I can't explain this, the boot entries are duplicated after rebooting (which, BTW, worked OK):

[deneb:~]$ sudo efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0003,0004
Boot0000* ubuntu
Boot0002* Windows Boot Manager
Boot0003* Windows Boot Manager
Boot0004* ubuntu

I would swear those duplicates weren't present even after running efibootmgr *after* doing the grub-efi-amd64-signed upgrade. I can't identify *when* they were installed unless somehow they were masked until after I rebooted. In any case it seems *wrong* to have duplicate entries for the *same* operating system.

Perhaps this is a clue? Maybe the grub update is trying to install *new* entries when there are already entries present?

Revision history for this message
Night Train (nighttrain) wrote :

I upgraded with synaptic.
A window warned me that the EFI partition was not writable and GRUB could not be updated.
If I clicked "next" without checking the box, then I returned to the same message.
I checked the box and clicked on "next", then the installation ended without any errors.
I rebooted and everything seems to be working.
Maybe the message window is to ask permission to write to the EFI partition.
But this creates confusion and unnecessary apprehension.

Revision history for this message
Jack Christensen (jchristensen) wrote :
Download full text (3.9 KiB)

I also experienced this issue, although the system rebooted fine afterwards. The grub-install command continued to fail afterwards. As noted above, adding --no-nvram allows grub-install to run. I don't understand what might be lost by not updating NVRAM variables. System continues to reboot OK though.

$ sudo grub-install /dev/nvme0n1
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.

$ sudo grub-install --no-nvram /dev/nvme0n1
Installing for x86_64-efi platform.
Installation finished. No error reported.
$

System information:
System: Kernel: 5.4.0-54-generic x86_64 bits: 64 compiler: gcc v: 9.3.0
           Desktop: Cinnamon 4.6.7 Distro: Linux Mint 20 Ulyana base: Ubuntu 20.04 focal
Machine: Type: Desktop System: Gigabyte product: X570 AORUS ELITE WIFI v: -CF
           serial: <filter>
           Mobo: Gigabyte model: X570 AORUS ELITE WIFI v: x.x serial: <filter>
           UEFI: American Megatrends v: F30 date: 09/15/2020
Battery: Device-1: hidpp_battery_0 model: Logitech Wireless Solar Keyboard K750
           charge: 100% status: Full
           Device-2: hidpp_battery_1 model: Logitech Marathon Mouse/Performance Plus M705
           charge: 55% (should be ignored) status: Discharging
CPU: Topology: 8-Core model: AMD Ryzen 7 3700X bits: 64 type: MT MCP arch: Zen
           L2 cache: 4096 KiB
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
           bogomips: 114988
           Speed: 2195 MHz min/max: 2200/3600 MHz Core speeds (MHz): 1: 2672 2: 2180 3: 2114
           4: 2171 5: 2195 6: 2328 7: 2002 8: 2193 9: 2194 10: 1879 11: 2192 12: 2202
           13: 2184 14: 2172 15: 2510 16: 2018
Graphics: Device-1: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590]
           vendor: PC Partner Limited driver: amdgpu v: kernel bus ID: 09:00.0
           Display: x11 server: X.Org 1.20.8 driver: amdgpu,ati
           unloaded: fbdev,modesetting,vesa resolution: 2560x1440~60Hz
           OpenGL:
           renderer: Radeon RX 580 Series (POLARIS10 DRM 3.35.0 5.4.0-54-generic LLVM 10.0.0)
           v: 4.6 Mesa 20.0.8 direct render: Yes
Audio: Device-1: AMD Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]
           vendor: PC Partner Limited driver: snd_hda_intel v: kernel bus ID: 09:00.1
           Device-2: AMD Starship/Matisse HD Audio vendor: Gigabyte driver: snd_hda_intel
           v: kernel bus ID: 0b:00.4
           Sound Server: ALSA v: k5.4.0-54-generic
Network: Device-1: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi
           v: kernel bus ID: 04:00.0
           IF: wlp4s0 state: down mac: <filter>
           Device-2: Intel I211 Gigabit Network vendor: Gigabyte driver: igb v: 5.6.0-k
           port: f000 bus ID: 05:00.0
           IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives: Local Storage: total: 4.55 TiB used: 512.77 GiB (11.0%)
           ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO Plus 1TB size: 931.51 GiB
           ID-2: /dev/sda vendor: Western Digital model: ...

Read more...

Revision history for this message
Night Train (nighttrain) wrote :

Yes, @Jack Christensen (jchristensen), it’s the same for me too.
I found it interesting to read the explanation given at this link:
https://askubuntu.com/questions/1170347/what-does-no-nvram-do-while-installing-grub

I hope it’s useful to everyone.

Revision history for this message
Alexander Weber (lllalexanderlll) wrote :

After successfully executing 'sudo grub-install /dev/sdb --no-nvram' I also restarted and it booted up fine. I don't know if the command was necessary, but it seem not to have done any harm.

Revision history for this message
Robert Varga (robrtvarga) wrote :

Happened to me on Budgie 20.04.1, too.
I killed the processes and restarted, later just restarted.
Boot seemed fine all the times.
Never tried to let it further with the checkbox, though.

Revision history for this message
Robert Varga (robrtvarga) wrote :
Download full text (6.3 KiB)

By the way, this is in my /var/log/term/apt.log:

... omitted as no errors nor mentions of grub in this update ...
Log ended: 2020-11-24 06:06:29

Log started: 2020-11-25 09:53:25
(Reading database ... 265760 files and directories currently installed.)
Preparing to unpack .../0-grub-pc_2.04-1ubuntu26.7_amd64.deb ...
Unpacking grub-pc (2.04-1ubuntu26.7) over (2.04-1ubuntu26.6) ...
Preparing to unpack .../1-grub2-common_2.04-1ubuntu26.7_amd64.deb ...
Unpacking grub2-common (2.04-1ubuntu26.7) over (2.04-1ubuntu26.6) ...
Preparing to unpack .../2-grub-pc-bin_2.04-1ubuntu26.7_amd64.deb ...
Unpacking grub-pc-bin (2.04-1ubuntu26.7) over (2.04-1ubuntu26.6) ...
Preparing to unpack .../3-grub-efi-amd64-signed_1.142.9+2.04-1ubuntu26.7_amd64.deb ...
Unpacking grub-efi-amd64-signed (1.142.9+2.04-1ubuntu26.7) over (1.142.8+2.04-1ubuntu26.6) ...
Preparing to unpack .../4-grub-efi-amd64-bin_2.04-1ubuntu26.7_amd64.deb ...
Unpacking grub-efi-amd64-bin (2.04-1ubuntu26.7) over (2.04-1ubuntu26.6) ...
Preparing to unpack .../5-grub-common_2.04-1ubuntu26.7_amd64.deb ...
Unpacking grub-common (2.04-1ubuntu26.7) over (2.04-1ubuntu26.6) ...
Preparing to unpack .../6-libatopology2_1.2.2-2.1ubuntu2.2_amd64.deb ...
Unpacking libatopology2:amd64 (1.2.2-2.1ubuntu2.2) over (1.2.2-2.1ubuntu2.1) ...
Setting up grub-common (2.04-1ubuntu26.7) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Setting up grub-efi-amd64-bin (2.04-1ubuntu26.7) ...
Setting up libatopology2:amd64 (1.2.2-2.1ubuntu2.2) ...
Setting up grub2-common (2.04-1ubuntu26.7) ...
Setting up grub-pc-bin (2.04-1ubuntu26.7) ...
Setting up grub-pc (2.04-1ubuntu26.7) ...
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-54-generic
Found initrd image: /boot/initrd.img-5.4.0-54-generic
Found linux image: /boot/vmlinuz-5.4.0-53-generic
Found initrd image: /boot/initrd.img-5.4.0-53-generic
Adding boot menu entry for UEFI Firmware Settings
done
Setting up grub-efi-amd64-signed (1.142.9+2.04-1ubuntu26.7) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
File descriptor 3 (pipe:[795230]) leaked on vgs invocation. Parent PID 6949: grub-install
File descriptor 5 (/dev/nvme0n1p1) leaked on vgs invocation. Parent PID 6949: grub-install
File descriptor 3 (pipe:[795230]) leaked on vgs invocation. Parent PID 6949: grub-install
File descriptor 5 (/dev/nvme0n1p1) leaked on vgs invocation. Parent PID 6949: grub-install
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
File descriptor 3 (pipe:[795230]) leaked on vgs invocation. Parent PID 7138: grub-install
File descriptor 5 (/dev/nvme0n1p1) leaked on vgs invocation. Parent PID 7138: grub-install
File descriptor 3 (pipe:[795230]) leaked on vgs invocation. Parent PID 7138: grub-install
File descriptor 5 (/dev/nvme0n1p1) leaked on vgs invocation. Parent PID 7138: grub-install
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot e...

Read more...

Revision history for this message
Ali Atiia (aliatiia) wrote :

This worked for me: sudo grub-install --no-nvram

The issue happened during a software update, it may be due to permissions on boot/efi which is on a different device (sdaX)

Revision history for this message
Robert Varga (robrtvarga) wrote :

I let it continue without writing, and it does not seem to have broken anything, it rebooted fine.

Revision history for this message
Jack Christensen (jchristensen) wrote :

I just installed the following updates. Seems to have fixed the issue for me; grub-install now runs without error. Thanks very much!

Upgraded the following packages:
libefiboot1 (37-2ubuntu2.1) to 37-2ubuntu2.2
libefivar1 (37-2ubuntu2.1) to 37-2ubuntu2.2

Revision history for this message
jeremyszu (os369510) wrote :

According to comment#25, the SRU of https://bugs.launchpad.net/ubuntu/+source/efivar/+bug/1892792 could fixed this issue and it already in focal-updates.

Revision history for this message
Robert Varga (robrtvarga) wrote :

On the other hand, this issue prevented me from getting any further updates via APT because it never progressed past trying to reconfigure one of the grub packages (grub-efi-amd64-signed, I believe), hence even if such update were available, it will not help existing cases when someone is stuck with a broken grub package.

Therefore some further documentation indicating what to do when experiencing this issue would be very useful, with detailed explanation on each part of each command to issue to fix the existing problem, so it can be adapted to for example different device ids (e.g. explaining what the device id to use should be if device id is necessary).

Revision history for this message
Alex (a-t-page) wrote :

Same here, seems to be fixed as of version 37-2ubuntu2.2 of libefiboot1 and libefivar1.

Revision history for this message
inodez (matt-causey) wrote :

Any updates here? I am running Ubuntu 20.04 installer and getting this failure.

Revision history for this message
Alexander Grytsenko (grytsenkoalexander) wrote :

Ubuntu 20.04.3. The same issue.

Command executed:
  grub-install /dev/sdc --target=x86_64-efi --efi-directory=/boot/efi/ -vv

The result:
  grub-install: info: Registering with EFI: distributor = `ubuntu', path = `\EFI\ubuntu\shimx64.efi', ESP at mduuid/44c7e894b6d510634f9493d9e9cb20a9.
  grub-install: warning: Internal error.
  grub-install: error: failed to register the EFI boot entry: Operation not permitted.

When using option "--no-nvram" - no error.

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.