After successfully updating my bios, something went wrong and I ended up with a blinking cursor on the top left corner of a black screen. No errors, no nothing. The bios now only listed a SATA: <disc name> boot option in place of the usual UEFI ubuntu one. I'm using a GPT partitioning scheme.

I eventually found that the working solution was to properly reinstall grub-efi-amd64. So, how do I do this ?

PS: Actually, i succeeded to reinstall GRUB2 EFI on my own and will post my answer here as I was unable to find any complete how-to on this.

  • I had trouble with my dual boot: Windows 10/PCLinuxOS laptop. I somehow lost the grub2 loader or the functionality. After trying many of the above contortions unsuccessfully I stumbled on the Grub2 Boot Rescue iso, burned it to a cd and left it in the drive. It was a little tedious to go through the boot process every time but at least it worked. Then I found the Boot Repair Disk iso and burned it to a DVD. At this point my drive was really flaky from my efforts so I reformatted and reinstalled everything, Windows 10 and Mint Sonya this time. Then booted Boot Repair Disk and installed Grub2 ov Dec 11, 2017 at 15:24

7 Answers 7

  • Boot your computer with a live-USB/CD in UEFI mode. I had two boot options <flash_drive> and UEFI: <flash_drive>, the second is needed to expose the efi variables in /sys/firmware/efi/ so that efibootmgr don't fail later on. Booting with the first option gives me the following error:

    Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
    Try 'modprobe efivars' as root.

    modprobe efivars did'nt work for me.

  • chroot into the broken system (similar to the ubuntu grub2 help but with efi specificities):

    sudo mount /dev/sda2 /mnt #sda2 is the root partition
    sudo mount /dev/sda1 /mnt/boot/efi #sda1 is the efi partition
    for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
    sudo cp /etc/resolv.conf /mnt/etc/ #makes the network available after chrooting
    modprobe efivars # make sure this is loaded
    sudo chroot /mnt
  • Depending on your linux distribution, you now do different things.

    • For Ubuntu/Debian:

      apt-get install --reinstall grub-efi-amd64

      or alternatively:

      apt-get install --reinstall grub-efi

      should the above give you a grub, but not a bootable one

    • For Fedora (up to 16, may work for others):

      yum reinstall grub-efi

      In the following command, you have to replace sdX with the device which has the EFI partition you want to boot from. In --part Y you have to replace the Y with the number of the EFI partition (as in /dev/sdXY).

      efibootmgr -c --disk /dev/sdX --part Y
      efibootmgr -v # verify a new record called Linux is there
  • Now type Ctrl+D to exit chroot, unmount everything and reboot:

    for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
    sudo umount /mnt/boot/efi #please do this. Corrupted efi partitions are not nice
    sudo umount /mnt
    sudo reboot

You may need to adapt this to your needs (different partition table, separate /boot partition, etc.) and it may not be the only option but this worked just fine for me.

A suitable live-system for fixing things is grml. There is also an extensive guide on how to setup a bootable USB device, of which the Mac section is the most useful actually (just create a FAT32 partition, copy the files, reboot, done).

  • 5
    Dude! Thanks so very much! This just saved me after my Lenovo X220 didn't want to boot anymore after a reset, which activated the latest package updates and at the same time saw me doing a BIOS reset because that supposedly fixes connection problems with the 3G card. After that booting became impossible, for whatever reason. Until I used your guide. BTW, the part were you copy resolv.conf didn't work for me, because it is a symlink into /run/resolvconf... (in Ubuntu 12.04), instead I just used mount --bind /run /mnt/run to mount the whole /run directory in the chroot environment.
    – nem75
    Oct 9, 2012 at 20:35
  • I extended the answer with my experiences for Fedora 16 and a reference to grml. If you could review and accept the edit, I'd be happy. Dec 9, 2012 at 11:26
  • 2
    On Ubuntu (at least for 12.04) update-grub won't copy the latest grub2 image to your EFI partition, it only update grub.cfg. So better way to do is apt-get install --reinstall grub-efi (or grub-efi-amd64) this will also call update-grub at the end.
    – number5
    Jan 3, 2013 at 22:16
  • 4
    Saved my media player yesterday. 300 internet points to you. Sep 12, 2013 at 17:21
  • 3
    After running update-grub my /boot/efi folder was still empty (I had created this new partition). Only after running grub-install the actual files were written there. This guide helped me (German): wiki.ubuntuusers.de/EFI_Problembehebung Nov 11, 2016 at 0:49

As a potential simplification of the first method, it is possible to directly boot into the system on the hard disk, only using grub of the live CD. Tested on xubuntu 13.10 with the xubuntu 13.10 live CD.

Make sure that Secure Boot is disabled in your BIOS. Insert the live CD and boot it via UEFI. The CD's GRUB menu will show. the Press "c" to get to the command line.

configfile (hd0,gpt1)/EFI/ubuntu/grub.cfg

Adapt the grub command above if you have a different EFI system partition.

After your system has booted from the hard disk, it should be enough to re-install grub on the EFI system partition and to register it with the firmware via grub-install.

sudo grub-install
  • Doesn't work. configfile (hd0,gpt1)/EFI/ubuntu/grub.cfg does nothing. How do I boot after issuing this command?
    – Autodidact
    Apr 9, 2015 at 10:00
  • 3
    Wow. I did not expect it to be that easy! This is one hell of an answer! I ran sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi rather than the above suggested command (but the one above may just work as well -- I don't know). And after that you can access your linux OS again. Then just run sudo update-grub and everything should be bootable.
    – Zorawar
    Jun 21, 2016 at 0:08
  • @SandeepDatta: your efi directory is probably on a different disk/partition. Mine was on /dev/sdb1, so I ran: configfile (hd1,gpt1)/EFI/ubuntu/grub.cfg. Boot a LiveCD and run sudo gparted to locate your efi partition.
    – Zorawar
    Jun 21, 2016 at 0:11

As with Maxine, I found my UEFI settings in BIOS to get damaged and my machine wouldn't boot.

In my case, it's a Lenovo ThinkServer RD430 with Linux Mint Debian and it seemed anything I'd do about update-grub or changing any hard drives in the server would cause it to not boot. OS in my case is linuxmint-201403-mate-dvd-64bit installed via USB. (see below for a complete description of the events that would cause UEFI to not work)

Going through exactly the same steps on a ThinkServer TS140 did not result in UEFI losing its mind even once. Looked at RD430 driver page and my bios is two versions old. I have never had to update bios on a motherboard before, so I'm not one to automatically update when there are new versions available. After updating the bios, Maxine's answer above worked, only with a twist...

# efibootmgr -c --disk /dev/sdX --part Y
# efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0002,0000,0003,0001,0004
Boot0000* linuxmint HD(1,800,1f4000,829f6cc9-5b17-479c-b3ea-61e43faecbf7)File(\EFI\linuxmint\grubx64.efi)
Boot0001* LMDE Linux Mint Debian    HD(1,800,15d505800,934c598c-fe3c-fd43-84a1-fa38e4f72552)File(\EFI\linuxmint\grubx64.efi)
Boot0002* Linux HD(1,800,1f4000,829f6cc9-5b17-479c-b3ea-61e43faecbf7)File(\elilo.efi)
Boot0003* UEFI: Built-in EFI Shell  Vendor(5023b95c-db26-429b-a648-bd47664c8012,)AMBO
Boot0004* UEFI: VerbatimSTORE N GO 1.00 ACPI(a0341d0,0)PCI(1a,0)USB(1,0)USB(4,0)HD(1,80,1d70780,00000000)AMBO
mint / # 

The efibootmgr -c command added two entries 0000 and 0002!
The Boot0002* Linux HD entry first in boot order is not correct.
The 0000 entry is correct.

To test this, I tried booting without any interruption, which is the 0002 entry. As expected, it didn't work. So I restarted the server, hit F12, and chose linuxmint. As hoped for, it did boot to my LMDE installation.

The way to remove unwanted entries via efibootmgr is:

# efibootmgr -b 2 -B

I used this command to remove entries 0001 and 0002. Option 0001 was from the last of my many attempts to recover the OS.

UEFI notes

If you're reading this and as frustrated with UEFI as I am/was, here are some notes and resources:
» Booting to UEFI Shell is akin to using a DOS shell.
» Intel made a PDF reference manual for efi shell commands.
» Lenovo's UEFI_on_TS430 document is the only resource I have seen explaining usage of efi shell.
» Another uefi shell reference from nPartition Administrator's Guide.
» You can try booting to a partition from the efi shell by navigating to the loader and executing it.
» UEFI wants the disk to have a GPT partition table, not msdos part table.
» UEFI wants the first partition on your disk to be formatted fat32 or vfat.
» For a "generic" boot there must be a /EFI/boot directory at the root with bootx64.efi in it.
» Some people copy their grubx64.efi from where it was installed to /EFI/boot/bootx64.efi and this cheat worked for them.
» Anytime you make grub changes, use efibootmgr -v before and after to ensure your reboot is ok.

My RD430 experience

I have resinstalled the OS 10+ times in the past week trying to sort this out and set up the server. My configuration is a SSD on this RAID controller in the PCIe 2.0 slot with LMDE installed on it. AOC-S3008L-L8i RAID controller (reflashed to IT mode) in the 2nd PCIe 3.0 slot with 6x 3TB drives. RAM: 12GB ECC (3x 4GB).

Here are changes I would make that caused my system to not boot:
» Change S3008L-L8i pci slots (leaving the SSD+card alone).
» Disable the LSi software raid bios prompt for onboard controller.
» Add my old HighPoint RocketRaid card to an open PCIe slot.
» Make a change to /etc/default/grub and then run update-grub.
(maybe grub-install needs to be run as well?)

  • I am very frustrated with UEFi.I have installed Linux with BIOS but it is very hard to get it to work with UEFi and refind
    – Suici Doga
    Mar 28, 2016 at 11:43

I would up-vote this, but apparently I don't have enough rep on SuperUser. I'm glad I finally found an answer to this after days of fighting clones that worked but wouldn't boot. I think it all relates to UEFI and some kind of "secure booting" mechanism or something.

I'm working off-line, so apt-get wasn't an option. What I did was put Ubuntu Desktop on a USB stick, add the grub-efi and grub-efi-amd64 packages to the root of the USB stick (grub-efi_1.99~rc1-13ubuntu3_amd64.deb and grub-efi-amd64_1.99~rc1-13ubuntu3_amd64.deb for Ubuntu 11.04 - change as appropriate for distro and architecture), and put the following in a script on the USB stick as well:

#! /bin/bash
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
dir=`dirname $0`
sudo cp $dir/grub-efi*.deb /mnt/tmp
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt /bin/sh -c "dpkg -i /tmp/grub-efi*.deb"
sudo shutdown -r now

Boot up the Live USB stick, open a terminal, run the command, and the job is a good 'un! The only occasional problem is that UEFI sometimes got moved down the boot priority order below the HDD, at which point you need to go into the BIOS and change the boot order to stop it trying (and failing) on SATA: drive.

You can also use dpkg-reconfigure instead of dpkg -i, but that asks a couple of boot loader questions.

[edit] I also don't have enough rep to comment, so what I thought was a comment on a reply turns out to be a reply.

  • Welcome on board! Actually you need 15 points to vote, 50 to comment (see superuser.com/privileges), just look around for easy questions you can answer and you're good to go, that's the stackexchange way to say thanks :) Beware your script doesn't unmount anything before shutting down. Glad it helped.
    – Maxime R.
    Mar 2, 2012 at 8:38
  • Confusion was more because I've got accts on other related sites. Forgot I was new to this side. Linux normally unmounts on shutdown, and chroot with a command returns after it finishes, so I don't think it should cause a problem. I did find that it won't abort if you didn't UEFI boot the live distro, but it wasn't a priority to test whether sudo chroot /mnt /bin/sh -c "dpkg -i /tmp/grub-efi*.deb" && sudo shutdown -r now gave the right behaviour.
    – IBBoard
    Mar 2, 2012 at 19:24

On my 32 bit Ubuntu 14.10 on Lenovo Yoga 2 Pro, I changed to UEFI boot like this:

  • create folder

    sudo su
    mkdir /boot/efi
  • mount "EFI System" partition in /etc/fstab

    fdisk -l|grep EFI

    this showed: /dev/sda2 2050048 2582527 532480 260M EFI System

    echo "/dev/sda2 /boot/efi   vfat    defaults,sync   0   0">>/etc/fstab

    mount that partition

    mount /boot/efi
  • install grub-efi-amd64-bin and uninstall grub-efi-ia32-bin

    aptitude install grub-efi-amd64-bin grub-efi-ia32-bin_
    grub-install --target=x86_64-efi
  • reboot Ubuntu in efi mode

  • test if it boots fine, then I installed grub-efi-amd64 and uninstalled grub-pc grub-gfxpayload-lists with

    aptitude install grub-efi-amd64 grub-pc_ grub-gfxpayload-lists_

I choose not to remove /boot when asked.

Maybe I made it complicated and this would have just worked fine:

apt-get install --reinstall grub-efi

This entry is more along the lines of preparing your computer to reinstall the efi entries. It's also what you might find to be an effective and simple way to create a rescue disk following system installation on internal media (SSD, HDD).

With Linux Mint Tara (a Linux variant closely related to Ubuntu Bionic Beaver), the method both borked my installation, and made it possible later to save it. It arose out of my wanting a live USB having persistence, and since the time to install a utility like Unetbootin for a persistent install is roughly the same as a fresh install, I simply used the same live distribution to do an installation on the USB as was used to install the OS on the internal SSD.

Of course, none of this is RAID or any other specialized setup, but it did require a prepared volume partition on the USB drive, and an installation done on that USB using the distro's available method, circumventing the internal drive for an install on a single partition's root (/) mount.

This is where the new grub installation tangled with the internal drive. When I rebooted to the USB, the internal UEFI grub entries seemed to have disappeared, leaving only the grub menu when trying to select the drive using the entries in the BIOS menu.

Instead, booting from the USB showed that the distro's method had produced a ready-made grub menu, with a listing for the /dev/sda2, the partition containing the /boot/efi mount. In most primary internal drive installs the partition's grub name is hd0, gpt1.

Going into 'advanced', more than one kernel rescue was available. From there, run the grub utility and then boot normally.

From this point, running the OS on the internal drive which was formerly inaccessible, unplug the USB, then run sudo grub-install.

When you reboot without the USB, you should be able to get back in. At this point the USB is configured to launch the internal drive into normal or rescue mode, and the drive has its own menu.


In 2022, reinstalling GRUB to an EFI system is a lot simpler.

Boot from a Live CD and open the terminal.

Next, mount the partition with your original OS and then the EFI system partition into /boot/efi inside the mounted partition.

Assuming you have a SSD disk /dev/nvme0n1 and orignal OS on the fifth partition /dev/nvme0n1p5:

sudo mount /dev/nvme0n1p5 /mnt

EFI_PARTITON=$(sudo fdisk -l /dev/nvme0n1 | grep EFI | cut -f1 -d' ')
sudo mount $EFI_PARTITON /mnt/boot/efi

Then install GRUB using /mnt as root directory:

sudo grub-install --root-directory=/mnt /dev/nvme0n1

Finally, reboot the system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .