Why does Ubuntu install continue to fail with 'grub-install /dev/sda failed' error?

Question

Goal: I am trying to install Ubuntu onto a Dell XPS 8900.

Problem: I can't get through an Ubuntu install without the install interrupting with Unable to install Grub in /dev/sda, Executing 'grub-install /dev/sda failed.' This is a fatal error.. Moreover boot-repair doesn't fix the issue.

Installer: I am using a flash drive with Ubuntu 22.04 LTS Installer on it. I have tried with a flash drive that I have installed with before and I have tried with a fresh install on another flash drive that I created with the Startup Disk Creator application. Note: I have added nomodeset and acpi=off in my grub command to start the Ubuntu Installer OS.

Attempts to solve:

• I tried to complete the grub-install myself using some answers on askubuntu. I did the aforementioned fix by exiting the installer prompt (after it failed) and running the commands in the terminal. I was able to successfully complete the grub-install here. However, as the original error happens part way into an install the resulting Ubuntu OS had multiple problems. I had services that would fail or just not start (including but not limited to: networkd-dispatcher.service, NetworkManager.service, fwupd-refresh.service, apparmor.service, caspermd5.services(?) ) and I had left over remnants from the install (for example, an application named Install RELEASE was still in my applications).

  • Note: chrooting into /mnt and running grub-install /dev/sda results in unable to allocate pty: No such device

• [Top answer here] (https://askubuntu.com/questions/143678/i-receive-the-error-grub-install-dev-sda-failed-while-attempting-to-install-u) suggests clicking Try Ubuntu and then using the Install Ubuntu 24.04 LTS application, which didn't work for me.

• [Top answer here] (https://askubuntu.com/questions/459620/unable-to-install-grub-in-dev-sda-when-installing-grub) suggests that grub-install is installing to the wrong device, which isn't true for me.

• I am desperate now, so I updated the BIOS to its most recent update. That didn't do anything.

• I tried running grub-install prior to running the Try Install application.

  • Note: running sudo grub-install --root-directory /mnt /dev/sda results in grub-instal: error: failed to register the EFI boot entry: Operation not permitted.
  • Also, I worry that even if I could successfully run grub-install prior to running the Ubuntu Installer, that the Ubuntu Installer would still fail because the Ubuntu Installer might run grub-install without options.

• boot-repair said that the NVram was locked. I saw a suggestion to clear the NVRAM by resetting the CMOS. After resetting the CMOS, I still get the same error message during installation.

Question: Why does Ubuntu 22.04 LTS install continue to fail with 'grub-install /dev/sda failed' error?

Result of boot-info:

• https://pastebin.com/tLfzEF8w
• https://paste.ubuntu.com/p/BQNbny9528/

Result of boot-repair:

• https://pastebin.com/z4ftZ8mW
• https://paste.ubuntu.com/p/Shc4V4xB9T

Answer 1

NVram Locked sounds like there might be some problems writing into the UEFI NVRAM variables, which are accessible in Linux via /sys/firmware/efivars or using the efibootmgr tool.

If you are accessing the failed installation by mounting it under /mnt/chrootdir and chrooting into it as suggested in answers to the AskUbuntu question you linked, I would suggest using mount --rbind instead of mount --bind for both /dev and /sys, as both include separate sub-filesystems that can be important for grub-install functionality:

• if /dev/pts is not available in the chrooted environment, it would cause the unable to allocate pty: No such device error
• if /sys/firmware/efi/efivars is not available in the chrooted environment, it would cause the attempts to write into UEFI NVRAM variables to fail... which is exactly your primary issue.

But if this does not help, you might want to read this excellent webpage by Roderick W. Smith, which explains certain problems other OSs or buggy UEFI firmware implementations can cause, and gives methods for working around them.

On your sda1 disk, there is apparently a efi/ubuntu/grub.cfg file, with the following contents:

search.fs_uuid 2D07-0F0A root hd0,gpt1 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

This seems incorrect: it is looking for the ESP partition (sda1) by filesystem UUID, and then assuming it should be a Linux root filesystem that contains /boot/grub... which is not true, as sda1 is the UEFI ESP, not the Linux root filesystem.

That file should instead have the following contents:

search.fs_uuid 25f0e88-f20a-4350-9df0-ee8c57ecc455 root hd0,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

You might want to copy this efi/ubuntu/grub.cfg to efi/BOOT/grub.cfg (also on sda1) too, to allow GRUB to find a valid configuration even if started as efi/BOOT/BOOTx64.efi.

This configuration file would cause the grubx64.efi on the ESP to seek the real Ubuntu root partition (sda2) by filesystem UUID, and then load any necessary GRUB modules from there, and also load the true GRUB configuration from /boot/grub/grub.cfg on sda2.

You might also want to copy efi/ubuntu/grubx64.efi into efi/BOOT/grubx64.efi on sda1, to ensure the full set of boot files are also available on the UEFI fallback/removable media boot path.

This part of the boot-repair output is actually produced by efibootmgr -v:

BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0004
Boot0003* UEFI: TOSHIBA TransMemory 1.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/HD(2,GPT,9240a165-d190-4ab6-8a12-46dc207b42ee,0x71e8a0,0x2130)..BO
Boot0004* UEFI: ST2000DM001-1ER164  HD(1,GPT,22c1dbaf-a26e-4408-a6f9-d1fc06b0d615,0x800,0x100000)/File(EFI\boot\bootx64.efi)..BO

It indicates that although you've currently booted from USB, your system firmware is prepared to boot from sda1 (identified by PARTUUID 2c1dbaf-a26e-4408-a6f9-d1fc06b0d615 using the file fallback/removable media boot path EFI/boot/bootx64.efi (the filesystem on ESP is vfat, so it should be case-insensitive... but some UEFI firmware implementations aren't). So if you can perform the above-mentioned changes to the ESP, the system might be able to boot from sda1.

If you can get a regular Ubuntu system running in UEFI mode, you could retry sudo grub-install /dev/sda to rewrite the bootloader and automatically re-write the NVRAM boot variable for Ubuntu. Or alternatively, you could use the efibootmgr command to try and precision-fix just the boot variable issue yourself:

sudo efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\ubuntu\\grubx64.efi -L Ubuntu 

(This command requires that /dev/sda1 is mounted as /boot/efi and the efivarfs filesystem is mounted at /sys/firmware/efi/efivars. Both of these conditions should be handled automatically by a normal Ubuntu boot process.)

If this still fails with "NVram Locked" or similar, you might have a buggy UEFI implementation, but at least it allows you to boot into Ubuntu by using the fallback/removable media path.

Answer 2

I stumbled into the very same issue - failed to install 20.04LTS and 22.04LTS.

I eventually fixed this: After Ubuntu installer failed, reboot into USB live Ubuntu and re-run boot-repair. It worked out marvelously.

To be more specifically:

• I have 2 Nvidia 3090 graphic card.

• After selecting "Install Ubuntu" in GRUB menuu, I got a black screen. So I have to press e on GRUB menu add acpi=off (nomodeset or choosing "Safe Graphic" didn't help in my case) to get into USB live Ubuntu to install.

• Then I meet this "Failed to install GRUB to NVMe", and runing boot-repair result in "NVram locked".

  I assume that during the previous installation, my SSD somehow was added a lock, so boot-repair can't do any changes and instead I get "NVram locked". If you run cd /target, you will go straight into it.

• After a reboot, run cd /target, you will get a not a directory error message. Then run boot-repair. Problem solved.

I also tried to install GRUB manually, following AskUbuntu posts. But I'm not a native English speaker, so I suppose I messed up which is which, what drive I should mount. Can't really figure out if the word 'device/hardware/drive' means USB stick or SSD.