How can I reinstall GRUB to the EFI partition?

Question

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.

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 -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
Clear :) Anyway, I tried to remove the second ubuntu entry (referred to grubx64.efi) with efibootmgr, but when I restart my computer it comes back! Instead, if I try to remove the other entry (that is referred to shimx64.efi), there are no problems. However, when I select ubuntu in the bios, it strangely loads successfully. I say strangely because I've read that, when secure boot is active, I must select the entry referred to shimx64.efi in order to load ubuntu properly! I'm a little bit confused.. — Generoso, Sep 30 '16 at 15:28
What you read is true, when Secure Boot is enabled you boot with shimx64, when Secure Boot is disabled you boot with grubx64. This gives you both options, so my suggestion is to leave it just right the way it is. :) — cl-netbox, Sep 30 '16 at 15:35
Okk :) Then I'll rename the bios entries, so I can distinguish them and choose the proper one, depending on the Secure Boot state :) Is there a command to restore the entry (shimx64) I deleted before? :D — Generoso, Sep 30 '16 at 17:20
Execute : sudo efibootmgr -c -w -d /dev/sd* -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi' (* = disk) :) — cl-netbox, Oct 17 '16 at 13:34
In my opinion, the difference between the BIOS and EFI is difficult to live easily with. best to pick one — , Nov 08 '16 at 13:55
All current answers use chrooting but it did not work on my machine (I could not access my drives inside the chroot), so I added my answer that works without chrooting: https://askubuntu.com/a/1203713/541576 — Gabriel Devillers, Jan 17 '20 at 14:12

cl-netbox · Accepted Answer · 2023-01-08T13:40:39.130

161

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
update-grub
exit

Note: If the grub-install command reports an error, it cannot find efivars. Try the following while still in the chroot environment (Thanks to @michael_dunn - the step was necessary in Ubuntu 22.10) :

mount -t efivarfs none /sys/firmware/efi/efivars

Afterwards execute the grub-install command again : grub-install /dev/sdX

To avoid possible unexpected issues, properly unmount the file systems afterwards.

sudo umount /dev/sdXX
sudo umount /dev/sdXY

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.

edited Jan 08 '23 at 13:40

answered Sep 29 '16 at 15:51

cl-netbox

31,163
7
94
131

3

+1 but why don't you install from Ubuntu itself? – Nov 08 '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 08 '16 at 13:58
After exchanging an Intel NUC the new device didn't start from the old HDD. This fixed it. You made my day - thanks a lot! – Möhre Oct 08 '17 at 19:06
6

In this solution, how does 'grub-install' know it is supposed to install in EFI mode? – user334639 Oct 12 '17 at 00:38
@user334639 This happens right because the EFI partition gets recognized automatically ... :) – cl-netbox Oct 12 '17 at 10:23
Thanks! And that's because the disk is formatted with GPT instead of MBR, is this right? Converting MBR to GPT would be a different question, is this right? – user334639 Oct 12 '17 at 15:45
1

@user334639 Generally we can say that system installations on modern machines with an EFI based BIOS are deployed on disks with GPT partition table and system installations on older machines with MBR based BIOS are deployed on disks with "msdos" partition table. When the GRUB boot loader gets installed this will be detected automatically ... on system installations in legacy BIOS mode, an EFI partition does not exist. :) – cl-netbox Oct 12 '17 at 16:48
18

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 06 '18 at 12:20
@mook765 Thanks for your contribution ! Although this should be an obviously known fact, I think that the information you provided is useful, especially for not so experienced users. Hence I decided to include it in the answer. :) – cl-netbox Mar 06 '18 at 14:22
Hi, thanks for this post. When you say " sdXXX = System partition" do you mean the partition assigned to /, /home or /boot? Thanks – Chris Rogers Mar 14 '18 at 21:49
Hi @ChrisRogers You're welcome ! :) sdXXX is the system partition, which means : / (the root partition). – cl-netbox Mar 15 '18 at 12:04
Fantastic, cheers for that. – Chris Rogers Mar 15 '18 at 23:29
1

Installing Ubuntu 18.04, only grub-pc was available. Had to first run sudo apt-get install grub-efi, then these steps. Still got an error message on grub-install, but ignored it and ran update-grub, which found the Windows EFI. I then had to reboot, enter the boot management, and update the Boot Sequence option. It wasn't listed, but it gave me the option to add a boot option, then search for file, which I found in the right file system + EFI directory. Set the new boot option as first, and it finally worked! – iisisrael Jul 12 '18 at 19:47
4

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
I think if you do this
1. after purging Windows partitions,
2. whilst identifying partitions using UUIDs in /etc/fstab,
you need to update at least the /boot/efi UUID in your /etc/fstab (make sure other are correct as well). You can find partition IDs using blkid
– Egor Tensin Mar 17 '19 at 15:38
What about 32-bit version? – chx101 Jul 30 '19 at 22:12
This really helped me. I’ve been scouring the internet to find a solution. – wesley franks Apr 13 '20 at 22:35
Thanks for this solution it worked. I'd like to add that i had troubles after the procedure with startup time (~3min system boot / startup). I had to update /etc/fstab with the right UUID of the efi partition. Just compare the UUIDs of the efi partition of sudo blkid and the one of /etc/fstab... – user634093 Apr 26 '20 at 18:02
Can someone explain me what the third command does for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done ? – kamer_kane Jun 26 '20 at 10:42
1

@Vivek It binds /dev /dev/pts /proc /sys /run from the live system to the mounted installed system, so that the commands you execute on the live system can effectively make the changes to the mounted installed system. It is a shorter version of these commands : sudo mount -o bind /dev /mnt/dev sudo mount -o bind /dev/pts /mnt/dev/pts sudo mount -o bind /proc /mnt/proc sudo mount -o bind /run /mnt/run sudo mount -o bind /sys /mnt/sys – cl-netbox Jun 26 '20 at 17:39
In my case, the grub-install step failed with "read-only partition". So I went out of the chroot, unmounted the efi partition, then remounted it with --rw. Went back into the chroot and then the reinstall was successful. This was on a Ubuntu 20.04 live CD. – EugeneRomero Jul 06 '20 at 09:51
Works fine with Ubuntu 20.04 after: deleted all Windows partitions, moved Ubuntu partition and formated EFI partition. Thanks ! – NicolasSmith Sep 27 '20 at 18:30
Thanks a lot for this answer. +1 – schizoid_man Sep 29 '20 at 09:36
2

you sir are a god and an upvote is not nearly enough repayment – rchurch4 Apr 11 '21 at 19:04
@cl-netbox Hi follow all the step as you said but when I excute the grub-install /dev/sda it's taking to long... It's now over 5 hours what should I do? Stop it?.. Note: I deleted EFI partition accidentally in past. – Rohit Nishad May 28 '21 at 14:02
Hi @RohitNishad :) An EFI partition is mandatory to let any operating system boot at all. The EFI partition should be the first partition on the disk and must be formatted with FAT (fat32). Recreate the partition with GParted by booting from the installation medium ... in case you are not sure how to perform everything, it probably might be more easy for you to completely reinstall the Ubuntu operating system from scratch. – cl-netbox May 29 '21 at 11:42
I don't known why my PVE (debian based) can't boot (uefi fail, no grub screen) after a power failure. this really save my life. – yurenchen Jan 29 '22 at 18:06
I had "bad" settings that was causing grub to fail and this was just reinstalling grub with those same settings. Before running update-grub I edited /etc/defaults/grub and removed the bad settings. I'm not 100% sure how it was finding the non-default grub file -- when non-chrooted, it had normal defaults, but from within the chrooted terminal window, I saw my "bad" settings. – Tim Coker May 15 '22 at 06:15
this method has helped even in case of "Locked ESP detected" error. as further boot fixes has been done with the BIOS assistance: AMI BIOS proposed to fix EFI database errors. – Oleg Kokorin Jun 15 '22 at 07:04
1

This worked for me with 2 modifications: After chroot: mount -t efivarfs none /sys/firmware/efi/efivars and grub-install /dev/sdXX – michael_dunn Jun 17 '22 at 02:18
It's not right in front of me now, but I remember reading in some rescue CD's manual about this, or a very similar solution, and in there it was emphasized how important it is to correctly unmount the filesystems afterwards. Apparently, rebooting at this state without proper unmounting, carries a not unsignificant risk of damage to these crucial partitions, that may impose a new, harder to solve impediment on booting. Given the popularity of this answer, I would include here the codeblock for the unmounting part too. – Levente Oct 29 '22 at 11:03
Thank you for the suggestion @Levente ! Although it's a commonly known practice, I have added the part of unmounting the file systems nevertheless. Well, you are right ... better be safe than sorry. :) – cl-netbox Oct 30 '22 at 13:00
For how long should I expect it to say "umount: /mnt: target is busy"? If it does this forever does that indicate some other problem? (in my specific case, Ubuntu isn't booting after multiple tries of a fresh install) – KernelDeimos Nov 06 '22 at 02:14
1

@KernelDeimos : As you say "Ubuntu isn't booting after multiple tries of a fresh install" ... yes, you most certainly are facing some other problems. – cl-netbox Nov 06 '22 at 10:41
@cl-netbox turns out I had to rename ubuntu/boot/grubx64.efi to Microsoft/Boot/bootmfgw.efi or something like that... it was uncomfortable and strange – KernelDeimos Nov 08 '22 at 00:16
what's the reason to boot from installation medium when I can boot into final ubuntu already? Thx – ying Jul 17 '23 at 02:45
@ying : You ask "What's the reason to boot from installation medium ?" Firstly, the main reason is that this is the safest way to reinstall the GRUB boot loader. Secondly, most users need to reinstall the boot loader only in case they can NOT boot into the installed system ... And, why else should someone want to reinstall the boot loader when everything works as expected ? :) – cl-netbox Jul 17 '23 at 11:57

score 17 · Answer 2 · answered Aug 28 '18 at 20:07

17

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

answered Aug 28 '18 at 20:07

Chilu Pereira

179
1
3

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
1

Worth noting that for --target=x86_64-efi option to work you need a package grub-efi-amd64-bin – Hi-Angel Jan 20 '22 at 17:28
Would like to see a revision with some for loops – Avery Freeman Nov 20 '22 at 06:33

score 14 · Answer 3 · edited Feb 04 '24 at 00:17

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)

if the directory /sys/firmware/efi/efivars is empty, run:

mount -t efivarfs none /sys/firmware/efi/efivars

after which is should not be empty anymore

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

if you use Secure Boot, add the argument --uefi-secure-boot to grub-install command below

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

source for how to populate /sys/firmware/efi/efivars (else grub-install warns: warning: EFI variables are not supported on this system)

source for how to make it work with Secure 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. — 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: https://serverfault.com/a/1047507/574185 — LuxZg, Dec 24 '20 at 23:56
Helped a lot. The disk in my system was still OK, but reaching it's capacity. So I transferred all the data to the new one (btrfs send/receive), created the new EFI partition, copied contents from the old EFI and followed your instructions. Then after rebooting with the new disk I found that the grub.cfg created by grub-install references the grub.cfg in /boot/grub (that lives on the btrfs partition). This one did still have the previous disk's UUIDs in the menu, so it wouldn't boot. Fixed the ID there (use ls -l /dev/disk/by-uuid to find the new ID), works like a charm now. Thanks! — Patrick Echterbruch, Jul 02 '21 at 09:06
I upvoted this but found that the update-grub step is missing from the instruction, which IMHO is the biggest flaw of this solution as update-grub is most often a critical step that most people cannot miss (and I guess that it has to be done within chroot). — xpt, Sep 05 '21 at 13:50

Nicolás · Answer 4 · 2021-03-30T00:59:07.540

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
update-grub2
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

score 7 · Answer 5 · answered Jun 22 '18 at 22:32

7

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
update-grub

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

answered Jun 22 '18 at 22:32

Rob Pearman

79

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 '21 at 22:05

score 6 · Answer 6 · edited Dec 05 '23 at 13:06

6

Also, if booting from Live CD to recover, it might happen that you are missing the grub-efi-amd64-bin package and then the 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, the /dev/sdb parameter is obsolete and is being ignored.

edited Dec 05 '23 at 13:06

BeastOfCaerbannog

14,585

answered Jan 12 '19 at 01:15

mprot

146

I wonder what sudo apt get grub-efi-amd64-bin will do. – mook765 Dec 20 '20 at 04:22
sudo apt get grub-efi-amd64-bin is not a valid command. Perhaps you mean sudo apt install ... – Organic Marble Feb 10 '23 at 22:25

cengique · Answer 7 · 2020-03-29T01:07:26.530

4

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.

edited Mar 29 '20 at 01:07

answered Jul 17 '18 at 09:04

cengique

150

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

score 4 · Answer 8 · answered Dec 23 '20 at 13:11

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

and

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 '21 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 '21 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 : [https://askubuntu.com/a/1188621/260981] — schiffsratte, Jan 24 '21 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 '21 at 19:20

score 3 · Answer 9 · answered Dec 07 '17 at 23:53

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.

score 2 · Answer 10 · edited Oct 31 '22 at 13:19

Took me a while getting lost doing this. I have the same setup (non-encrypted /boot in ADDITION to a vfat /boot/efi). The following debian guide nails it. Missing pieces from all other guides were mounting the efivars and just comprehensive steps for grub re-installing etc. Hope this helps!

https://wiki.debian.org/GrubEFIReinstall

Details on the specific parts that were missing from other answers here:

include the efivars in the chroot whole installing grub

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

don't forget to mount /boot and then also /boot/efi in the chroot

run all the grub commands

apt-get install --reinstall grub-efi
grub-install /dev/disk
update-grub

Thank you debian!!

score 0 · Answer 11 · answered Jun 19 '21 at 16:09

0

Just used this tool https://help.ubuntu.com/community/Boot-Repair on Ubuntu. That was the easiest way and all was automatic.

answered Jun 19 '21 at 16:09

Zak the Gear

1

score 0 · Answer 12 · answered Jun 29 '21 at 13:33

The simplest for me was to use this small tool (20 Mb) that will let you boot the broken grub system (I used Ventoy to boot the tool):

https://www.supergrubdisk.org/category/download/supergrub2diskdownload/

And once the tool has made its magic and booted your linux systen, do:

sudo grub-install /dev/nvme0n1
sudo update-grub

Joepie Es · Answer 13 · 2021-11-11T11:06:56.093

I used Grub-Customizer. I know some of you don't like this program, but in some cases it comes in very handy ( renaming Ubuntu in Kubuntu ( don't have to do that in 'etc/grub.d/10_Linux_Proxy' ), add a theme, or in this case.

File --> Install in MBR.

And all was done.

I don't use Linux based OS's that long ( 7 or 8 months now ), and if I have to write everything down to use in the command-line, it not only takes a long time ( mostly the writing down ), but I can make errors that way.

I had my Windows Bootloader in partition 1 and grub2 in another EFI partition ( 8 )( didn't want to mess up Windows Bootloader ), so every time I wanted to use my Kubuntu ( daily ) or Mint OS I had to press F11, wait, select USB ( don't ask me why ), select Ubuntu, then wait again for Grub and then select my Linux based OS. Now I get Grub2 almost instantly.

Update 211111/1135 Like Organic Marble commented 'MBR doesn't sound right for a UEFI system', he is right. It worked, but only once. What I did is install Grub2Win in my Win10 installation. From Kubuntu I could export my 'grub.conf´ to the 'My Documents'-partition ( NTFS, so Win10 can read that ) and imported it in Grub2Win. Now it is working like it is suposed to.

PS. I saved this page, so I know how to do it when I get rid of Windows.

@ Organic Marble. No, you are right. Doesn't sound good. It worked though. Only 1 time. So clearly this is not the right way. — Joepie Es, Nov 11 '21 at 09:19

How can I reinstall GRUB to the EFI partition?

13 Answers13

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

Linked

Related