update grub safely

doblerone · 2022-08-31 06:34:25

After seeing the announcements in the front page regarding updating grub, I wanted to make sure I'm doing it the right way.

I installed grub in my relatively old system (it has a DOS partition table) with the following command:

grub-install --target=i386-pc /dev/sda

and generate the configuration via:

grub-mkconfig -o /boot/grub/grub.cfg

If I understood correctly, when updating grub, I should run both of the above commands, the installation and the regeneration of the config file, am I right?

I don't want to mess things

V1del · 2022-08-31 06:59:04

That's right. Though the "problematic" config line will primarily affect UEFI setups, to update GRUB properly that would be the correct approach

Maniaxx · 2022-08-31 07:14:04

'/dev/sda' is not safe:

If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like /dev/sda and /dev/sdb switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.
https://wiki.archlinux.org/title/persis … ice_naming

V1del · 2022-08-31 07:59:10

In the context of the GRUB update it is safe as long as you are sure you are hitting the correct device. That's the device you are installing the effective boot loader to. For identification of the kernels/root partitions afterwards GRUB defaults to UUIDs since years.

Last edited by V1del (2022-08-31 07:59:31)

Enrico1989 · 2022-08-31 23:06:37

Hi everybody.

The announcement scared me too, here, so I refrained from rebooting the computer, and intend to keep it on until I understand exactly what to do.

Therefeore I'd like some help understand how to customize the suggested action:

grub-install ...
grub-mkconfig -o /boot/grub/grub.cfg

I've opened the suggested wiki page, but to be honest that just scares me more.

Anyway, based on the first link, and on the text formatting of the following line from the point 3 at the second link

# grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB

I understand I should really just change "esp" (which is in italic) to something else. Since point 1 reads

[...] in the remainder of this section, substitute esp with its mount point.

I suspect that the answer is in here

$ sudo fdisk -l
[sudo] password for enrico: 
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: KBG40ZNS512G NVMe KIOXIA 512GB          
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9DF34935-F28A-4FF0-ACC1-9174FA0C6B10

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     309247    307200   150M EFI System
/dev/nvme0n1p2    309248     571391    262144   128M Microsoft reserved
/dev/nvme0n1p3    571392  482201599 481630208 229.7G Microsoft basic data
/dev/nvme0n1p4 482201600  929927167 447725568 213.5G Microsoft basic data
/dev/nvme0n1p5 963481600  965509119   2027520   990M Windows recovery environment
/dev/nvme0n1p6 965509120  996978687  31469568    15G Windows recovery environment
/dev/nvme0n1p7 996980736 1000187903   3207168   1.5G Windows recovery environment
/dev/nvme0n1p8 929927168  963481599  33554432    16G Linux swap

Partition table entries are not in disk order.

Does this mean I simply have to execute

grub-install --target=x86_64-efi --efi-directory=/dev/nvme0n1p1 --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg

as sudo?

Scimmia · 2022-08-31 23:08:09

You need to point it at where you have the ESP mounted, not at the block device.

Enrico1989 · 2022-08-31 23:10:26

Can you be more explicit, please?

Scimmia · 2022-08-31 23:12:37

Where's the confusion at? Ask a specific question.

loqs · 2022-08-31 23:24:20

Does the output of `mount` contain an entry for /dev/nvme0n1p1 ?

V1del · 2022-08-31 23:26:27

You need to mount the ESP somewhere where you do that is/was up to you check your fstab for where you'd usually keep it. if you mounted the ESP to /boot mount it to /boot and run the command against /boot (... from a chroot into your actual root, otherwise chances are you get an old GRUB again)

Enrico1989 · 2022-08-31 23:28:05

Nope

$ mount | grep '/dev/'
/dev/nvme0n1p4 on / type ext4 (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)

Enrico1989 · 2022-08-31 23:31:59

V1del wrote:

if you mounted the ESP to /boot

I don't know.. I guess whatever I've done in this respect I've done it several years ago now.

V1del · 2022-08-31 23:45:27

What's your output of ls -l /boot ? If it is empty, you mounted the ESP to /boot and need to mount it there again, if it contains the kernel images but no EFI directory/file then you only installed GRUB on there in which case it is irrelevant where you mount it as long as you don't mask /boot, pick /efi or whatever. And as mentioned look at your fstab on whether you added an entry for it.

Enrico1989 · 2022-09-01 16:57:19

V1del wrote:

What's your output of ls -l /boot ?

total 54196
drwxr-xr-x 6 root root     4096 Jul 14  2020 grub/
-rw------- 1 root root 35357130 Aug 30 06:50 initramfs-linux-fallback.img
-rw------- 1 root root  9131258 Aug 30 06:50 initramfs-linux.img
-rw-r--r-- 1 root root 10991648 Aug 30 06:50 vmlinuz-linux

But there's quite a few files under /boot/grub/x86_64-efi/, so what scenario am I in?

V1del wrote:

And as mentioned look at your fstab on whether you added an entry for it.

cat /etc/fstab

gives

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p4
UUID=56194078-c063-48a7-bf73-fe604bdbf866	/         	ext4      	rw,relatime	0 1

# /dev/nvme0n1p8
UUID=8920f592-6eba-477b-8449-88a973c04ce1	none      	swap      	defaults  	0 0

V1del · 2022-09-01 20:50:02

You are in the "haven't mounted the ESP to /boot" camp and all the files in there will be loaded by the GRUB you are eventually loading from the ESP. So in that aspect it doesn't matter where you mount the ESP as long as you don't mask /boot. So pick whatever you want. "Convention" is to pick /efi

So do that

mount /dev/nvme0n1p1 /efi #Create /efi if it doesn't exist
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg

Enrico1989 · 2022-09-02 05:41:31

I think it worked, thank you very much!

zoltan · 2025-10-24 01:15:54

Enrico1989 wrote:

Can you be more explicit, please?

I know this is old, but I recently broke a system updating GRUB and couldn't figure out how to fix it, so I ended up just reinstalling (not necessarily the correct approach, but the easiest for me as reinstalling and restoring from a backup can be tedious, but is trivial). To help others who found their way here but still may be a little unclear on how to correctly update GRUB on UEFI systems (as I was after reading because I have a chicken nugget for a brain) I'll share my trial and error experience here.

What the wiki says

The GRUB Arch Wiki page says for installing on UEFI systems, you should run

# grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB

Where --efi-directory=esp, replace esp with the mountpoint where your EFI directory is located. If you're updating on the currently running system, your EFI directory should be mounted at /boot (at least mine is). You can check this by running lsblk and checking the MOUNTPOINTS column. This is what mine looks like as an example.

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme1n1     259:0    0 931.5G  0 disk
├─nvme1n1p1 259:3    0     1G  0 part  /boot
└─nvme1n1p2 259:4    0 930.5G  0 part
  └─root    253:0    0 930.5G  0 crypt /

The partition called nvme1n1p1 is where my EFI directory is located, and it's mounted at /boot. Note: If you're doing this from a live environment like your Arch Linux installer medium instead, the mountpoint will be whatever you named it when you mounted it (probably /dev/boot if you're reading the wiki).

What I did wrong the first time

I ran

# grub-install --target=x86_64-efi --efi-directory=/boot/EFI --bootloader-id=GRUB

which left me with an un-bootable system. I tried to fix it, derped my mostest hardest derp, and ended up reinstalling.

What I did right the second time

Luckily, I have an identical system where I was able to try again, and was totally willing to risk borking that install as well. This time, I ran

# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB

This was the correct way, as I am pleased to report I did not end up doing the herpaderp a second time. I regenerated grub.cfg and booted back into my system without incident.

Main take-aways

The main hangup seems to be putting in the wrong --efi-directory
If updating GRUB on a UEFI system that is currently booted and running, your "--efi-directory" is likely /boot
If you're not sure, run lsblk and check the mountpoints
You need the mountpoint, not the name of the block device or boot partition (i.e. not "sda" or "sda1")
Your grub-install command should probably look like (but please make sure first...)
```
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
```

Lastly, "remember to #Generate the main configuration file after finalizing the configuration or else your os will not be in the grub menu"

# grub-mkconfig -o /boot/grub/grub.cfg

Corrections and criticism are welcome. Be brutal if you must. I have thick skin, and I'm always eager to learn from my mistakes. Most importantly, I don't want to put out bad or false information. This is just my experience and what worked (and didn't work) for me. I'm pretty confident in everything I've written here, but I do also understand that not all systems are the same, which is why I keep saying that you should double-check what your mountpoints are. Maybe your EFI directory is mounted somewhere else for whatever reason. It depends on how your file system table is configured, which can be checked with

# cat /etc/fstab

Last edited by zoltan (2025-10-24 01:34:03)

WorMzy · 2025-10-24 02:14:44

Mod note: Closing this old thread.

Arch Linux

#1 2022-08-31 06:34:25