I want to reinstall GRUB 2 and I found these instructions: How to Repair, Restore, or Reinstall Grub 2 with a Ubuntu Live CD or USB. In my case, the boot loader is installed in the EFI partition. If I use the commands provided in this guide, will GRUB be reinstalled to the EFI partition automatically, or will it be installed into the root partition where Ubuntu is installed ? Obviously, I do not want this to happen.

  • 6
    The instructions in the provided link are valid for reinstalling GRUB in legacy BIOS mode only, this will not work in your case. To reinstall GRUB to an Ubuntu installation in EFI BIOS mode, please read my answer. :) – cl-netbox Sep 29 '16 at 16:36
  • Thank you very much! :) I have some questions: when I installed Ubuntu in my UEFI system, I found two entries in the bios. Is there a way to have a unic ubuntu entry? In case of MBR partition table (so no EFI or any other boot partition), can I use the same commands except for: sudo mount /dev/sd** /mnt/boot/efi ? – Generoso Sep 30 '16 at 10:11
  • You can try to remove the second Ubuntu entry with : sudo efibootmgr (lists all entries) | sudo efi bootmgr -b <entry-number> -B .... and to reinstall GRUB in legacy BIOS mode execute these commands : sudo mount /dev/sd** /mnt | sudo grub-install --boot-directory=/mnt/boot /dev/sd* (* = disk | ** = system partition) ! :) – cl-netbox Sep 30 '16 at 10:54
  • Perfect :) Anyway, having a UEFI system and so a EFI partition, is there a way to avoid getting grub overriden when I perform a new Windows installation? – Generoso Sep 30 '16 at 12:18
  • Well, Microsoft doesn't take care for anything else but their own products, so you can install Linux systems without doing any harm to Windows - unfortunately this isn't the case the other way around - so when you install Windows after you have installed Ubuntu, you have to restore the GRUB boot loader afterwards. :) – cl-netbox Sep 30 '16 at 13:23

10 Answers 10


Reinstall the GRUB boot loader to your Ubuntu installation in EFI mode this way ...

Boot from the Ubuntu installation medium and select 'Try Ubuntu without installing'.
(Boot your install medium in EFI mode, select the Ubuntu entry with UEFI in front.)

Once you are on the Live desktop, open a terminal and execute these commands :

sudo mount /dev/sdXY /mnt
sudo mount /dev/sdXX /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sdX

Note : sdX = disk | sdXX = efi partition | sdXY = system partition

To identify the partitions use GParted, the tool is included in the installation medium.
After having run the commands GRUB will be installed in the separate EFI partition.

  • 2
    +1 but why don't you install from Ubuntu itself? – user595510 Nov 8 '16 at 13:55
  • 3
    @MarkYisri : Thank you very much ! :) Because it is the safest way to reinstall the GRUB boot loader without corrupting things and in case the system does not boot properly ... the only way to do it ! :) – cl-netbox Nov 8 '16 at 13:58
  • 3
    In this solution, how does 'grub-install' know it is supposed to install in EFI mode? – user334639 Oct 12 '17 at 0:38
  • 8
    The important point is to boot the installation media in the correct boot-mode, if we want to reinstall grub-efi we have to boot in UEFI-mode, if we wanty to reinstall grub-pc we have to boot in legacy-mode. – mook765 Mar 6 '18 at 12:20
  • 2
    This worked for me except with one alteration: I did grub-install /dev/sdXX, i.e. not the disk but the EFI partition was used for installing grub and it worked. – Duck Dodgers Mar 12 '19 at 21:56

this is the only way that worked for me: (System: sdb8, boot: sdb6, efi: sdb2)

sudo mount /dev/sdb8 /mnt 
sudo mount /dev/sdb6 /mnt/boot 
sudo mount /dev/sdb2 /mnt/boot/efi

sudo mount --bind /dev /mnt/dev &&
sudo mount --bind /dev/pts /mnt/dev/pts &&
sudo mount --bind /proc /mnt/proc &&
sudo mount --bind /sys /mnt/sys

sudo chroot /mnt

grub-install --target=x86_64-efi /dev/sdb

grub-install --recheck /dev/sdb

exit &&
sudo umount /mnt/sys &&
sudo umount /mnt/proc &&
sudo umount /mnt/dev/pts &&
sudo umount /mnt/dev &&
sudo umount /mnt
  • 1
    What does --recheck do? The manual says delete device map if it already exists? – MrCalvin Mar 27 '19 at 22:45
  • If I call the boot-entry anything different the the default, e.g. --bootloader-id=Ubuntu_02 the boot fails. It just boot in the grub console...any solution? – MrCalvin Mar 27 '19 at 22:47
  • yes. it seems grub-install --recheck is needed. It fixed my non-working USB HDD EFI. – solsTiCe Aug 19 '19 at 12:45

Thanks to @cl-netbox for the instructions!

After I upgraded (Linux Mint 18.2 Sonya to 18.3 Sylvia) my system wouldn't boot so I followed the instructions above but still no success. I noticed however that my machine has /boot in a separate partition (possibly because I am using LVM) so my slightly modified process was:

sudo mount /dev/sdXXX /mnt
sudo mount /dev/sdXY /mnt/boot
sudo mount /dev/sdXX /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sdX

Note : sdX = disk | sdXX = efi partition | sdXY = boot partition | sdXXX = system partition

  • 1
    I had a running Ubuntu Bionic system on which I accidentally did rm -Rf /boot/efi ! My system was still running, so I tried using the last two commands (grub-install /dev/mapper/ubuntu--vg-root AND update-grub). Rebooted, and everything work perfectly. Phewy and thanks :) – Roel Van de Paar Jul 29 '18 at 22:04
  • With LVM, the beginning should look like this: sudo vgchange -ay name_of_:the_lvg and then sudo mount /dev/sname_of_:the_lvg/root /mnt – Benjamin Hastings Mar 31 at 22:05

This is how I did it on a standard x86_amd64 EFI desktop, without chrooting, assuming you have a partition containing Ubuntu on your hard drive and possibly an EFI partition where GRUB should be installed.

# boot on a live Ubuntu, I used 18.04 but more recent should work

# if you have currently no EFI partition (maybe it was deleted,
# or you are migrating to a new drive):
# sudo gparted
# - create a FAT 32 partition of around 100 MB on the disk of your choice
# (in general the one that host the Ubuntu partition). If you plan to
# move or resize some paritions, anticipate that (for instance by
# creating the EFI partition at the end of the free space).
# - set the flag esp on this partition (the flag boot will also be selected)

# now assuming that the Ubuntu partition is `/dev/sda2` and the (possibly new) EFI partition is `/dev/sda1`
sudo apt install grub-efi
sudo mkdir /media/root && sudo mount /dev/sda2 /media/root
sudo mkdir /media/efi && sudo mount /dev/sda1 /media/efi
sudo grub-install --target=x86_64-efi /dev/sda --efi-directory=/media/efi --boot-directory=/media/root/boot

This should give:

Installing for x86_64-efi platform.

Installation finished. No error reported.

Then reboot and you should be done. You may have to tell your BIOS which drive to use, or which EFI partition to use, or which EFI binary to use.

If you created a new EFI partition, you may have to add it to /etc/fstab to have update-grub working correctly.

For more information : https://wiki.archlinux.org/index.php/Multiboot_USB_drive#Hybrid_UEFI_GPT_+_BIOS_GPT/MBR_boot

  • Thanks for the tips. I used modification of this. Since I was converting VM from BIOS to EFI I just formatted the existing /boot that was ext to fat using command mkfs -t vfat /dev/sda2 (in MY case!) then mounted it with mount /dev/sda2 /mnt/boot/ and also mounted my root (LVM). I've pointed both directory options to same place grub-install --force --target=x86_64-efi --boot-directory=/mnt/boot --efi-directory=/mnt/boot /dev/sda. Then I've edited fstab that was mounted in /mnt/root/etc/fstab and replaced UUIDs with /dev/sda2 + vfat and /dev/mapper/.. for LVM. <continues> – LuxZg Dec 24 '20 at 23:23
  • (sorry, comment limit) Anyway, after (successful!!!) reboot, I still repeated it inside the OS (VM) itself, by running grub-install /dev/sda --efi-directory=/boot + update-grub + another reboot. I tested this by installing another kernel, and forcing update-grub, and everything was fine, grub files were updated correctly, and new entries for this kernel were created. So thanks a lot once again, cheers! – LuxZg Dec 24 '20 at 23:27
  • My particular case with Ubuntu VM as answer on serverfault: serverfault.com/a/1047507/574185 – LuxZg Dec 24 '20 at 23:56

Also, if booting from live cd to recover it might happen that you are missing grub-efi-amd64-bin package and then line

"grub-install --target=x86_64-efi /dev/sdb" 

fails with error message: "grub-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory."

In this case run this outside of chroot

sudo apt get grub-efi-amd64-bin

and then add /usr/lib/grub/x86_64-efi to chroot mounts.

BTW "/dev/sdb" param is obsolete and is being ignored.

  • I wonder what sudo apt get grub-efi-amd64-bin will do. – mook765 Dec 20 '20 at 4:22

If you happen to lose your EFI partition, it's easy to get it back. You can use a partitioning tool such as fdisk or parted to create a new partition sdXY (e.g. sda1) with type "EFI partition (1)" and format it with:

sudo mkfs.msdos /dev/sdXY

then mount it with:

sudo mount /dev/sdXY /boot/efi

and you can reinstall GRUB by running:

sudo grub-install --efi-directory=/boot/efi

as mentioned in other solutions.

  • 1
    Surely you format a partition on the disk i.e. /dev/sdX1, and not the whole block device? – Josip Rodin Mar 27 '20 at 21:18

in addition to ci-netbox answer.
If your pendrive OS version does not match the one that is installed on the disk, grub-install may have difficulties to identify the right grub installation:

$ sudo chroot /mnt
# grub-install /dev/sdX
grub-install: error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist. 
Please specify --target or --directory.

Try to identify manually the installation to use

# ls /usr/lib/grub/
grub-mkconfig_lib  x86_64-efi  x86_64-efi-signed

Then restart grub-install :

# grub-install --target=x86_64-efi /dev/sdX 
Installing for x86_64-efi platform.
Installation finished. No error reported.

I can't comment (not enough reputation), but @Chilu Pereira's answer is the way to go in an EFi or multiboot situation. It is similar to the approach in the gentoo-guide. They use a slightly different approach : Instead of a mount --bind they use mount --rbind followed by mount --make-rslave for sys and dev and proc gets simply mounted again. In gentoo I used to create mounts from a live-system like this:

mount -t proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev 
chmod 1777 /mnt/dev/shm

(Anybody knows what is exactly the difference between --bind and --rbind / --make-rslave btw ?)

But today I got two errors in chroot from grub2, I never experienced before :

 connect: No such file or directory
   Please make sure that the zfs-fuse daemon is running


grub-install: warning: Cannot read EFI Boot* variables.
grub-install: warning: read_file: could not read from file: Input/output error.

The zfs-fuse error seems not to matter but for Efivars I had to add one more mount :

mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars

I guess /sys/firmware/efi/efivars does not exist in chroot or maybe it's read only - but anyway it worked

  • Agreed, that answer was the one that fixed up my grub install without borking the existing Apple partition (I don't think bind-mounting /dev/pts is needed though) – Z4-tier Jan 23 at 16:23
  • the /dev/pts thing can be found in many tutorials and manuals . As /dev/pts are pseudo-terminals and a bind mount, it may not be needed. – schiffsratte Jan 24 at 18:51
  • I just found the explanation why you should prefer --rbind over --bind as --rbind gives access to other bind-mounts underneath the bind-mount you are creating. A better explanation is here : [askubuntu.com/a/1188621/260981] – schiffsratte Jan 24 at 19:14
  • I'm guessing the r is for recursive. I've not heard of that option. I'm not sure offhand if there are any other mount points under '/sys', but if there are then i hope 'rbind' has loop detection! – Z4-tier Jan 24 at 19:20

During the last months there have been some updates to the libraries involved.

The steps below were useful for me. They took ideas from old answers as well as from other forums.

Make sure that you booted using EFI

efibootmgr -v

Run grub-install

sudo mount /dev/nvme0n1p5 /mnt 
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do sudo mount -B $i /mnt$i; done

sudo chroot /mnt

grub-install --target=x86_64-efi /dev/nvme0n1
grub-install --recheck /dev/nvme0n1

# as a second attempt, you could also try (assuming _debian_ is your distro)
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian
# grub-mkconfig -o /boot/grub/grub.cfg


exit &&
sudo umount /mnt/sys &&
sudo umount /mnt/proc &&
sudo umount /mnt/dev/pts &&
sudo umount /mnt/dev &&
sudo umount /mnt

Make sure that efibootmgr lists your Linux as an entry

efibootmgr -v

What caused the loss of the Grub2 menu in the first place?

Universal answer 112 (cl-netbox Sep 2016, Dec 2020) should always work to reinstall grub. The maze of steps required will not answer this festering question which most everyone asks.

An Example

Assume a working Ubuntu install on a gpt SSD followed one year later by a new install of a newer Ubuntu version on a gpt spinning disk. Boot after the new install has lost the grub2 menu of the SSD and boots instead to the spinning disk.

Curiosity can sometimes lead to learning more about how grub2 works. Learning from the example proceeds as follows. Assume hereafter the spinning disk boots ubuntu.

Sudo mount the EFI partition of the SSD on /mnt 
Open a terminal on /mnt
cd to /mnt/EFI/ubuntu and open grub.cfg in a text editor like xed

The contents of grub.cfg looks like this:

search.fs_uuid 0caa0215-f19c-4cbf-8b27-1ffd0984bef8 root hd1,gpt12 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg**strong text**

Observe that file name grub.cfg is also used by grub2 in folder /boot/grub in a ubuntu ext4 partition. The two files have completely different contents.

The uuid=0caa0215-f19c-4cbf-8b27-1ffd0984bef8 is the key to discovering what happened. In another terminal examine the output of command blkid to see if the spinning disk has the above uuid.

What caused the loss of the Grub2 menu in the first place? If the uuid belongs to the spinning disk instead of the ssd, then the new ubuntu install re-wrote the info in the EFI partition. The EFI ubuntu file grub.cfg then causes EFI firmware to access the spinning disk instead of the ssd (slower than ssd, wrong grub menu).

A Shortcut? The details of answer 112 depend on a few wizard skills not owned yet by novices. Is a shortcut possible, like editing the UUID in the display above to the correct UUID? Grub2 uses the EFI vfat partition to boot ubuntu, the target partition for the boot given by the 3 boldface items below. Editing the 3 items can restore the ssd boot in the example. But direct editing can produce a non-booting system, which explains why answer 112 is a tool to be learned, independent of shortcuts that sometimes work. If you wear a Wizard's Hat, then the shortcut idea is another tool.

search.fs_uuid 0caa0215-f19c-4cbf-8b27-1ffd0984bef8 root hd1,gpt12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.