[root tip] [How To] Primer on handling a grub package update

Contributions Tutorials
, , , ,
1

How To update the system boot after updating grub itself

With the grub update 2023-12-22T23:00:00Z to v2.12, it was thus advised to ensure all parts of grub on the system are populated with the new binary and updated configuration.

This has revealed that a lot of users have doubts on how to correctly identify if their system needs special handling e.g. identifying whether to use EFI or BIOS commands.

This topic is aimed at being a primer to properly assess how to update grub on a system given the type of boot loader installation.

System type

To deduce whether you system is booted in EFI or BIOS mode

List the content of the efi firmware folder

ls /sys/firmware/efi/efivars

If you get an error or an empty list - your system is booted in BIOS mode and you should skip to the bios-section

EFI/GPT system

If your system is EFI you do not have to point the installation to a specific device but rather the $esp mount point.

Finding your efi mountpoint - commonly labelled $esp (Efi System Partition)

 $ lsblk -o parttypename,mountpoint | grep -e 'EFI'
EFI System           /boot/efi

Reinstall EFI grub

Reinstall grub a default Manjaro Linux EFI system.

This is an example - if your system is different use the mount point for your system.

Run as root (or prefix using sudo)

grub-install --target=x86_64-efi --efi-directory=/boot/efi --recheck --bootloader-id=Manjaro
grub-mkconfig -o /boot/grub/grub.cfg

Sync the fallback EFI loader

According to research one should ensure the EFI fallback image $esp/EFI/boot/bootx64.efi is updated as well. Otherwise your system may fail to boot if your system’s EFI firmware is pointing to the fallback entry.

To check if there is differences list the content (must be root or using sudo)

 # ls -l /boot/efi/EFI/Manjaro/grubx64.efi /boot/efi/EFI/boot/bootx64.efi 
-rwx------ 1 root root 143360 26 dec 10:11 /boot/efi/EFI/boot/bootx64.efi
-rwx------ 1 root root 143360 26 dec 10:11 /boot/efi/EFI/Manjaro/grubx64.efi

If they are identical no action is needed, however if they are not you need to replace the fallback loader (must be root or using sudo)

cp /boot/efi/EFI/Manjaro/grubx64.efi /boot/efi/EFI/boot/bootx64.efi

BIOS system

The most common BIOS type is using BIOS/MBR.

:reminder_ribbon: As a rule of thumb: the device containing your system root will likely be the primary boot device. This may not be true for all systems and if not then you know how to handle this anyway.

lsblk -o path,pttype,parttypename | grep -e 'dos' -e 'BIOS'

The output will show you devices and partitions which may be used to hold your grub bootloader.

NOTE: Keep in mind this is an example - your system will be different and you will have to adapt the following to your result.

BIOS/MBR system

With an output like this example grub is installed to the device Master Boot Record on the device never to the partition

/dev/sdy       dos
/dev/sdy1      dos    Linux

Reinstall grub on a Manjaro Linux BIOS/MBR system pointing to device MBR
Run as root (or prefix using sudo)
(Don’t forget to replace /dev/sdy with the correct block device name!)

grub-install --target=i386-pc --recheck /dev/sdy
grub-mkconfig -o /boot/grub/grub.cfg

BIOS/GPT system

If you are getting a response like this you are using a BIOS/GPT system and grub is installed to an empty partition

/dev/sdy1      gpt    BIOS boot

As grub will locate the bios-grub partition auto-magically when you reinstall grub on a Manjaro Linux BIOS/GPT system pointing to device path.
(Don’t forget to replace /dev/sdy with the correct device name!)
Run as root (or prefix using sudo)

grub-install --target=i386-pc --recheck /dev/sdy
grub-mkconfig -o /boot/grub/grub.cfg

Also see

The following topic is covering a new helper script package providing an automated way of running the checks and update the system as needed.

26 Likes
4

Hi,
I think it is a good solution for everyone.
Until now, I have added two aliases on the .bashrc in order to solve this on my efi boot configuration:
alias install-grub-efi='sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi/ --bootloader-id=Manjaro'
and
alias update-grub='sudo grub-mkconfig -o /boot/grub/grub.cfg'

It is good news not to need them in the future. Thank you for the script and hook.

Regards,

5

Thanks very much for this. This is the easiest explainer I’ve seen on how to determine if I’m running a EFT/GPT system of BIOS/MBR.

I have one quick clarifying question: With the latest update to Grub 2.12, when should the grub install commands be issued? Do I update the system via pamac/pacman, and then issue the commands?

Thank you!

6

After you updated your Manjaro repos based system (either using Pamac or pacman) run the grub-install command before rebooting.

2 Likes
7

I performed the update. Ran the two commands without any issue on my EFI system.

Rebooted with great optimism:

IMG_20231226_091431
IMG_20231226_0914311920Ă—1440 97.9 KB

And ended up greatly disappointed:

IMG_20231226_091447
IMG_20231226_0914471920Ă—1440 140 KB

I can’t understand what I did wrong!

8

Check your BIOS and make sure the boot order hasn’t changed; adjust if needed. Try UEFI OS (or similar) if Manjaro’s Grub isn’t defined in the list. Then save and exit the BIOS. It should then reboot (hopefully to Grub). Cheers.

9

Dont know many about the problem, but could it be that 'secure boot' is enabled in your bios/uefi?

For this problem you can also find a older discussion in the arch forum.

10

Thank you for your help! As it turns out, several mobo settings, settings which I have never had to modify before, had to be changed:

First, my X570 MSI motherboard has a CSM/UEFI setting which had to be changed to UEFI only. I rebooted, and the “shim_lock” error went away, but then the complaint was my “secure boot” settings.

So I changed the secure boot setting and tried again. This time, the “shim” error came back! Then I realized that when I changed the boot setting to UEFI only, I forgot to double check the boot order. Sure enough, “Manjaro” was second. I changed it to the first position and it booted normally!

I guess the takeaway here is that the recent update to GRUB mandated certain setting in the BIOS which were not required before.

And now my joy has returned. Thank you!

11

It’s easy to overlook. Glad I could help. Cheers.

1 Like
14 
lsblk -o path,pttype,parttypename | grep -e 'dos' -e 'BIOS'

Actually, I don’t think there is any problem.

In this script, the configuration drives for a partitionless btrfs raid are displayed as shown below. dos.

$ lsblk -o path,pttype,parttypename | grep -e 'dos' -e 'BIOS'
/dev/sda       dos    
/dev/sdb       dos    
/dev/sdc       dos    
/dev/sdd       dos    
/dev/sdf       dos

A btrfs RAID consisting of 5 HDDs.

15

I have an old ASUS laptop given to me as a free hand-me-down so I use it as a crash test dummy for, among other things, installing new Stable updates. It’s a BIOS/MBR setup and I decided to use the seemingly simple two commands noted in this excellent primer by @linux-aarhus rather than experiment with the new install-grub utility. As is my usual procedure using Yakuake, I checked the mirrors and did the sudo pacman -Syuw to download all the updates without installing, logged out and then in to a TTY to run sudo pacman -Su to install the updates. This time, before doing a reboot, I tried to use the two commands listed in this primer for a BIOS/MBR installation and was met with an error –

grub-install --target=i386-pc --recheck /dev/sda
warning: disk does not exist, so falling back to partition device /dev/sd4. <<< this line displayed three times
error: disk `hostdisk//dev/sda4’ not found

After a bit of teeth gnashing, I stumbled across something that made me consider using sudo grub-install –

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

And that worked!! The installation completed with no errors.

Perhaps the command shown in the primer for BIOS/MBR system should have sudo added to the command?

1 Like
16

I’m confused. There is no difference in the lines, except one is with sudo and the other not.

17

That’s exactly correct. The command without sudo threw an error. The command WITH sudo completed with no errors. In other words, on my system at least, I needed the sudo to get grub-install to execute properly.

18

How strange, you not getting access to stuff that needs root access without sudo. xD
OFC you need to be root or use sudo for it to work!

19

Well - you are most certainly not amongst the target audience for this topic :slight_smile:

That is normal - for commands that changes files in system folders - always use root or sudo.

I acknowledge there was some inconsistency in the commands as they were written - this has now been corrected.

Thank you for letting me know. :+1:

1 Like
20

Understandable mistake.

If you copy/pasted from the manjaro wiki, they start with sudo su :slight_smile:

22

I’m still taking baby steps and trying to learn as I go along. Each mistake, each misstep adds to my education and experience.

23

There used to be common to preface an example command with either $ or # to indicate whether elevated privileges were needed, or whether the command should be used at the user level. It doesn’t seem as widely used any longer, unfortunately.

24

And you are partly correct.

From experience I can say that it is - for those new to the syntax - common to assume the prefix is part of the command. I know I did a couple of times when I ventured into the Linux world :grin:

My writing style is usually adding the prefix when the output is essential to the context.

25

No. Not you. Surely not.

OK, I’ll stop calling you Surely.