Executing grub install dev sda failed this is fatal error

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(EFIbootbootx64.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.

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

As the title says, I’m trying to install Ubuntu 16.10 so that I can dual-boot Ubuntu alongside my existing Windows 7 installation. I’m installing from a USB drive and I keep getting the error:

Unable to install GRUB in /dev/sda. Executing 'grub-install/dev/sda' failed.
This is a fatal error.

My situation is as follows:

I currently have:

• HDD #1 : Windows 7 64-bit (750 GB)
• HDD #2 : NTFS partition for extra files (700 GB) and Ubuntu 16.10 (300 GB)
• SSD #1 : Unformatted (120 GB)

I was able to install Ubuntu 16.10 successfully, prior to GRUB failing to install.

I want to install Ubuntu such that it is on the 300 GB partition of the 1 TB drive. I can’t seem to get Ubuntu to install GRUB successfully.

Though this is a common error, I can’t seem to find anyone in exactly the same situation (apparently Windows 8 and later play differently with Ubuntu and can cause other problems, and other posts from people with this problem seem to be trying to install Ubuntu over Windows 7 as a replacement rather than a dual-boot option).

I’d prefer not to put Ubuntu on the SSD (eventually I’m going to get around to reinstalling Windows 7 there, but that’s another day’s project).

I can provide screenshots (or at least, pictures of the screen) if that would be helpful.

The lsblk -a command yielded this:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop1    7:1    0         0 loop 
sdd      8:48   1  57.7G  0 disk 
└─sdd1   8:49   1  57.7G  0 part /cdrom
sdb      8:16   0 698.7G  0 disk 
├─sdb2   8:18   0 698.6G  0 part 
└─sdb1   8:17   0   100M  0 part 
loop6    7:6    0         0 loop 
loop4    7:4    0         0 loop 
sr0     11:0    1    38M  0 rom  /media/ubuntu/SAMSUNG SSD
loop2    7:2    0         0 loop 
loop0    7:0    0   1.4G  1 loop /rofs
sdc      8:32   0 931.5G  0 disk 
├─sdc2   8:34   0     1K  0 part 
├─sdc5   8:37   0    16G  0 part [SWAP]
├─sdc1   8:33   0 651.5G  0 part 
└─sdc6   8:38   0 264.1G  0 part 
sda      8:0    0 111.8G  0 disk 
loop7    7:7    0         0 loop 
loop5    7:5    0         0 loop 
sr1     11:1    1  1024M  0 rom
loop3    7:3    0         0 loop

Translation(s): English — Français — Italiano — Russian

Recover GRUB

Imagine for any reason you have any other OS installed next to Debian. And for any reason you need to reinstall it because is really broken. Again, imagine that OS has a crappy installation and overwrites the disk MBR or GPT to own the full computer. What’s next? Reinstall Debian? No.

In any case, you can use SuperGRUB, a boot utility that can restore and repair overwritten and misconfigured GRUB installs or directly boot various operating systems.

Standard procedure

The Debian Installer (DVD, netinst CD, floppy, netboot, etc.) can be used to rescue systems, for example if they fail to boot after an upgrade. You should read and follow the instruction «Recovering a Broken System» section of the Installation Guide¹ [link to stable/amd64].

Troubleshooting : ‘grub-install /dev/sda’ failed.

If D-I’s «Reinstall GRUB boot loader» option fails, with error message

Unable to install GRUB in /dev/sda
Executing 'grub-install /dev/sda' failed.
This is a fatal error.

Also, the d-i log console (Alt-F4) displays

grub-installer: /dev/scsi/host0/bus0/target0/lun0/disc does not have any corresponding BIOS Drive

You can still use the following method to reinstall GRUB. Choose «Execute a shell in Your root partition» in the d-i rescue menu.

Locate your root partition :

fdisk -l

Disk /dev/sda: 39.9 GB, 39996820992 bytes
255 heads, 63 sectors/track, 4862 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         111      891576    7  HPFS/NTFS
/dev/sda2             167         230      514080   82  Linux swap
/dev/sda3             231         784     4450005   83  Linux
/dev/sda4             785        4862    32756535    f  W95 Ext'd (LBA)
/dev/sda5             785        4862    32756503+  83  Linux

Reinstall GRUB bootloader (grub manual)

If you have grub-legacy ² and your root partition is /dev/sda3 then you can re-install grub in the MBR of your hard drive by typing the following commands :

sudo grub
grub>root (hd0,2)
grub>setup (hd0)
grub>quit
exit

Note that in grub-legacy (hd0,2) is the third partition.

Then choose «Reboot the system», everything should be fine.

CategoryBootProcess

1. Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   I had an issue with upgrade and then fresh install of 20.10. Got busy and now thought I could fix it with 21.04

   I was able to run the live CD and get to the page Try or install. (I checked the download was correct with the SHA256SUMS etc)

   I have a dual boot Windows and Linux desktop (boots correctly in windows).

   I chose the install now and I then get the error.

   Executing �grub-install/dev/sda� failed
   This is a fatal error

   I did a chkdisk in windows without any errors.

   I’ve seen many post about fixing this, with many different methods.

   Of note, when I boot from the USB, I get an initial grub screen with not the best graphics to choose ubuntu or ubuntu with safe graphics or something like that (never seen that with a live CD before).

   D

   ---

2. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   What version of Windows and is it installed using UEFI?
   If a pre-installed Windows 10 it will certainly be UEFI but if you upgraded from Windows 7 it could easily be installed in legacy/BIOS mode.

   To give us more detailed info see Boot-Repair in my signature below and follow the instructions there to run the Boot-Info-Script. Do not run the any repair just yet but simply copy back here the pastebin link you get which will show us a lot more about your system.

   ---

3. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   https://paste.ubuntu.com/p/tp9BBhzxRG/

   I actually don’t remember, but I’m almost certain I upgraded to windows 10.

   Bios mode is: Legacy

   D

   ---

4. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   I am not a great expert in reading and decoding the boot-info script output but I note that it appears that you have an EFI/ESP partition on the hard disk.

   Code:

   fdisk -l (filtered): ___________________________________________________________
   
   Disk sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
   Disk identifier: 0xd283b5ea
         Boot      Start        End   Sectors   Size Id Type
   sda1             2048     718847    716800   350M  7 HPFS/NTFS/exFAT
   sda2           718848  979328108 978609261 466.6G  7 HPFS/NTFS/exFAT
   sda3       1952518144 1953519615   1001472   489M 27 Hidden NTFS WinRE
   sda4        979329022 1952518143 973189122 464.1G  5 Extended
   sda5  *     979329024  980379647   1050624   513M ef EFI (FAT-12/16/32)
   sda6        980381696 1952518143 972136448 463.6G 83 Linux
   Partition table entries are not in disk order.

   How did you create the USB you used to install and was the USB you used for that the same one as you used to run Boot-info script?

   Some applications used in Windows will only create a UEFI boot disk I believe, which would mean that you booted the USB in UEFI mode when you installed, therefore Ubuntu will have installed in UEFI mode, which will not work if your Windows is using legacy/BIOS.

   Wait for someone who understands the report better than I do before carrying out any further activities.

   ---

5. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   I used my other Ubuntu 20.10 only machine to create the USB.

   Yes, I made it while in the liveCD session on the USB.

   D

   ---

6. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   Please do not take me for an expert either. This is what I see in the Boot-Repair report.

   The drive has an extended partition (sda4). This means the drive has a Master Boot Record (MBR) partitioning scheme. I do not think that there should be an EFI partition (sda5). Indeed there are no boot files in sda5.

   I am guessing that this is a BIOS motherboard and not an UEFI motherboard. I am also guessing the Ubuntu install session was in UEFI mode. Boot Repair says

   Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of the same hard drive for core.img. core.img is at this location and looks for (,msdos6)/boot/grub. It also embeds following components:

   This is correct. msdos6 = sda6. The location of the Grub boot files. If there was a previous install of Ubuntu on this machine (20.10) it could have put
   Grub into the MBR of the drive. This would mean that the installer of 21.04 was accurate when it said that the install of Grub into the MBR failed.

   Boot Repair is offering to do the only thing it can do.

   The default repair of the Boot-Repair utility would purge (in order to unsign) and reinstall the grub2 of sda6 into the MBR of sda.
   Grub-efi would not be selected by default because: legacy-win no-win-efi
   Additional repair would be performed: unhide-bootmenu-10s win-legacy-basic-fix

   Regards

   It is a machine. It is more stupid than we are. It will not stop us from doing stupid things.
   Ubuntu user #33,200. Linux user #530,530

   ---

7. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   Line 72 3 Operating systems detected
   Line 105 Windows 10 on sda1 in Legacy mode
   Line 106 Windows 10 on sda2 in Legacy mode
   Line 116 EFI System Partition (ESP) for Ubuntu
   Line 109 Ubuntu on sda6 in UEFI mode

   How did you end up with 2 installations of Windows 10?

   You have Windows 10 in Legacy mode and Ubuntu in UEFI mode and this is ill-advised, hence the grub installation failure.

   In order to future proof your system, you should consider:-

   Backup your data
   Install both systems in

   UEFI mode with GPT
   https://help.ubuntu.com/community/UEFI

   ---

8. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   I’ve had previous Ubuntu going back many, many years. The last was 20.10 which did not install correctly. The last that worked correctly was 20.04

   I thought the second windows was the recovery area for windows? When I boot, I only show Windows 10 and Ubuntu 21.04. I haven’t installed a second, just upgraded from 8 to 10 at some time.

   I’m not sure what is on sda5

   Gparted shows boot, esp as flags for sda5
   If I click on information:
   Unable to read the contents of this file system!
   Because of this some operation may be unavailable.
   The cause might be missing software package.
   The following list of software packages is required for fat32
   file system support: dosfstools, mtools

   I’ll review that last link «

   Install both systems in UEFI mode with GPT», do I need to resolve the above issue first?

   D

   ---

9. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
   

   With BIOS, Boot-Repair copies bootmgr & BCD from Windows boot partition into the main or c:drive partition as many users have removed the boot partition not knowing it is essential. And then they do not have any boot files.
   But then grub does search for Windows boot files, not Windows boot flag like Windows uses, to find Windows bootable partitions and it then finds both NTFS partitions as bootable. But Windows only uses its boot loader from primary NTFS partition with boot flag.

   But you installed Ubuntu in UEFI mode, and had an old grub in MBR for BIOS boot.
   You can tell Ubuntu is installed in UEFI mode from ESP, UEFI boot entry and mount of ESP in fstab.
   You cannot have both BIOS boot Windows and UEFI boot of another system on same drive without major work arounds to change booting.
   Windows has to have boot flag on its bootable partition, your sda1 (although now it could be sda2 since boot files copied) and UEFI requires boot flag on ESP — efi system partition. Only one boot flag per drive.

   Use gparted and move boot flag from sda5 to sda1.
   Use Boot-Repair to install a Windows type boot loader to MBR ( or Windows repair/recovery flash drive) and make sure Windows boots. Fast start up must be off.
   Then use Boot-Repair to install BIOS version of grub to MBR.

   Since you only have one MBR, and two systems booting in BIOS mode, you need to always have both Ubuntu live installer & Windows repair flash drive.
   Grub only boots working Windows & Windows updates will turn fast start up back on. Then grub will not boot Windows & you have to do the boot loader switches again.

   Its a lot easier to have Windows in UEFI mode as then it can be directly booted from UEFI boot menu, if grub does not boot Windows.
   Microsoft has required vendors to install Windows in UEFI boot mode to gpt partitioned drive for almost 10 years, so BIOS installs are not recommended.

   Note conversion from MBR to gpt partitioning will erase drive so have good backups. But plan on eventually converting both systems to UEFI.

   ---

10. Re: Fresh Install 21.04 Executing �grub-install/dev/sda� failed
    

    Ok, sounds like I have a mess (not sure how I got to this point).

    Can I reinstall windows 10 in UEFI in GPT, then install Ubuntu?

    I’d overwrite/erase the entire drive in the process.

    Will that fix the issues above?

    D

    ---