Install-grub: a new way to keep your EFI/MBR in-sync with grub package

From Rod Smith:

GPT fdisk can create the EFI GPT (0xEE) placeholder partition either before or after the hybridized partitions in the MBR table. (Note that this has nothing to do with the disk sectors this partition protects.) Each placement has its advantages. Putting the 0xEE partition first in the table works best with GRUB Legacy and GRUB 2, which treat the disk as an MBR disk if the first slot in the MBR is not a 0xEE partition.

Could your first test show that the Protective MBR was somehow positioned last in the table, and appears as dev/sda2 (dos)?

Hybrid MBRs

After a lot of digging, reading manual pages and scanning image files I have found the following

 $ man grub
[...]
       INSTALL_DEVICE must be system device filename.  grub-install copies GRUB images into /boot/grub.  On
       some platforms, it may also install GRUB into the boot sector
[...]

As others has discovered - grub documentation is not clear on how to address the bios-grub partition or if it is even necessary.

I will do some further research into this - in the meantime I have edited the primer section - informing more research is needed.

There is a lot of info to be found on the topic and from some of it refers to the GPT bios-grub partition as a replacement for the MBR gap.

Search for grub bios gpt install to device or partition - sx.nix.dk

On a BIOS/MBR setup the loader is written into the post-MBR gap but on GPT partitioned devices that GAP may not be big enough - according to grub manual certain file systems may limit the available space - making it necessary to create the bios-grub partition.

Since I can find references to installing grub on a partition - there may have been a shift in how grub handles this.

If I install without a bios-grub - as you also found - the system boots equally well - grub must have some special logic making the jump to core.img possible without a bios-grub partition.


What have I learned

What I can say I have learned until now is that pointing the grub-install command for BIOS/GPT to the base device e.g. /dev/sdy is more correct than using the partition with the 0xEF02 identifier.

In any case the boot.img is written into the the first 512 bytes of the protected MBR of the selected disk.

If the partition is available the core.img is written to the partition and in case more than one - it will use the first partition with the 0xEF02 identifier.

If the partition is not available grub uses some internal logic to search out the core.img from the device where the boot.img is loaded from.

Hey @philm
This command you mentioned in the Topic:

$ sudo pacman -S grub

Is this command only needed for us to check if we see errors by a manual start now?

Is this script designed to always stay in background and it will be triggered till we downloaded another Release Version that included new Grub version and automatically doing its job in the background.

Or is it required after every release version to manually going in Terminal and type $ sudo pacman -S grub from now on?

Yes, the hook says exactly that:

[Trigger]
Type = Package
Operation = Upgrade
Target = grub

[Action]
Description = Installing Grub to MBR/EFI
When = PostTransaction
Exec = /usr/bin/install-grub

So you only need to install it, obviously keep it updated, and viola!

1 Like

Failing here saying WARNING: EFI directory not found! Grub couldn't be installed.

The main reason is that

> find /boot -name grubx64.efi 
/boot/efi/EFI/manjaro/grubx64.efi

Whereas the script is grepping for Manjaro (with a capital M that I don’t have in the path from a live-installer install in november)… The joys of vfat and case [in]sensitivity I guess…

so I guess a grep -i "$bootloader_id" is required insteadof a grep "$bootloader_id"

2 Likes

Latest version of script is working to remove /etc/grub.d/30_uefi-firmware for MBR

I have also deleted /etc/grub.d/30_os-prober to get rid of the warning message about os-prober


Most users don’t even know how grub got installed to begin with.

I know that grub is installed to MBR from recent check of calamares on new ISOs

some users can check calamares log

sudo cat /var/log/calamares.log | grep 'grub-install'

but my log is from 2017 and drives have been changed a few time since then

users could also check drive and partition information: inxi -DPa
and other users can also help new users if they have posted system information

Hmm, what you mean with keep it updated?

Keep it update = just keep doing downloading stable release version?
or keep it update with manually execute: $ sudo pacman -S grub so it still needs a little manual intervention?

How do you normally keep your system and packages up to date?
sudo pacman -Syu

FYI - I checked the boot order at the suggestion of another user who experienced the same problem, so it wasn’t just me. :slight_smile:

Yes, and the other user that gave the suggestion, was me. :slight_smile:

The point was that it’s happened to a few people lately as a consequence of the Grub upgrade, and being that it’s not a common occurrence, it leaves some users clueless as to what the problem is, and how to recover.

1 Like

Pamac GUI

no, the script is using the Bootloader-ID from /etc/default/grub file as in: GRUB_DISTRIBUTOR='Manjaro' You can check again in your install if that is the case and if your EFI folder really has a manjaro or Manjaro folder.

In my case DISTRIBUTOR is with capital letter, but bootloader-id as per grub-install is small case. Works fine.

[teo@teo-lenovo-v15 ~]$ sudo install-grub 
Grub will be installed on: EFI
Installing for x86_64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
Found linux image: /boot/vmlinuz-6.1-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.1-x86_64.img
Found initrd fallback image: /boot/initramfs-6.1-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done
[teo@teo-lenovo-v15 ~]$ sudo ls /boot/efi -Rl
/boot/efi:
total 1
drwx------ 3 root root 512 24. Jun 2023   EFI
drwx------ 2 root root 512 25. Jun 2023  'System Volume Information'

/boot/efi/EFI:
total 1
drwx------ 2 root root 512 24. Jun 2023  manjaro

/boot/efi/EFI/manjaro:
total 140
-rwx------ 1 root root 143360 28. Dez 11:22 grubx64.efi

'/boot/efi/System Volume Information':
total 0
[teo@teo-lenovo-v15 ~]$ cat /etc/default/grub |grep DISTRIBUTOR
GRUB_DISTRIBUTOR="Manjaro"

Just checked

GRUB_DISTRIBUTOR=“Manjaro”

and EFI folder really was all lowercase “manjaro” as per my previous post

→ I just manually corrected it to Manjaro… but had to

mv manjaro anjaro
mv anjaro Manjaro

because

mv manjaro Manjaro

Failed due to case insensitivity which wanted to move manjaro dir inside itself :frowning: !

This should work (untested):

sudo pacman -Syu perl-rename
rename manjaro Manjaro

Regardless, this isn’t necessary, as the named directory is usually created according to the content of bootloader-id=, unless created by a previous or foreign UEFI bootloader installation.

Hmm, what happens if the bootloader-id is all Capital. Might be UEFI BIOS related. I also saw EFI/Boot and EFI/boot folders.

In an actual Windows system, all-caps can sometimes be automatically converted to (sentence-case, I think) depending on default settings.
On a vfat filesystem (outside of Windows), I think the capitals will likely remain; the EFI directory is already allcaps, usually.

I think it doesn’t matter in the end for VFAT. It is all case insensitive, except the EFI folder. So a bootloader-id of Manjaro or manjaro or even MANJARO will act the same. Now we just have to figure out on how to make it case insensitive inside of the script.

Aren’t you glad there are no multi-language considerations?! :wink: At least, not as far as I’m aware; I don’t recall base UEFI locations being other than English.

If the directory already exists, say /EFI/manjaro and the bootloader-id is Manjaro does the script currently attempt to use the existing directory, or does it overwrite it with bootloader-id content? Maybe it’s better to first remove any existing directory (regardless of case) if it exists. VFAT is indeed case-insensitive, but tools needing to reference the directory, might not be.

Which will update this with everything else, like everything else…

1 Like