Manjaro's grubx64.efi is not automatically detected by UEFI

Support
, ,
1

As a question: Manjaro not found after reinstalling SSD or cloning to a new disk

Real use case of what happened: I wanted to use my laptop with two M.2 NVMe slots to migrate from an old SSD to new. Remove the SSD with Manjaro installed from my PC (where all boot entries exist in EFI settings). Put the SSD in my laptop. The laptop’s AMI-based firmware automatically detects Windows’ EFI bootloader, but it doesn’t find Manjaro’s grub.
Result: Manjaro is not at all bootable. Neither on the PC nor on laptop, the laptop didn’t detect it and PC erased the invalid entries after a reboot without the SSD inserted.

Expected: Firmware detects the bootloader automatically, even if all entries are removed with efibootmgr. This works for Debian, Ubuntu, Fedora; but Manjaro is broken and undetected (all tested). This was confirmed by my friend too. Secure Boot is off.

Where do I report this?

Workaround: Manually create a boot entry using efibootmgr. You need the path to Manjaro’s grubx64.efi (mount the boot partition aka ESP). For example when booting from a Live CD:

# mount the boot partition, as root:
mkdir /mnt/my-lost-boot
# My EFI boot partition is on p1
mount /dev/nvme0n1p1 /mnt/my-lost-boot
# Traverse the boot partition and copy the path:
cd /mnt/my-lost-boot/EFI/
ls
realpath manjaro/grubx64.efi | sed -e 's|/|\\|g'

Now that you’ve copied the path (it must have backslashes \), add the grub entry manually:

# My EFI boot partition is on p1
efibootmgr -c -L "My Manjaro Grub Loader" -d /dev/nvme0n1 -l '\EFI\manjaro\grubx64.efi'

Now you will be able to select the Manjaro loader after reboot. If it doesn’t let you, check Hard Drive priorities in UEFI Settings. It should have appeared here.

2

Since i’m no longer using Manjaro at moment i can’t check myself.

Do you have a \EFI\manjaro\BOOT.CSV file?
If not, that’s the reason why it isn’t added back automatically…

That file has info that is used by the fallback loader to regenerate boot entries…
It is an txt file that needs to be created via iconv: Managing EFI Boot Loaders for Linux: Using fallback.efi

1 Like
3

You are most likely right, I noticed the .CSV files in other bootloaders, I remember opening Ubuntu’s .CSV file, it’s a single line without a column definition.
I will reinstall later and see if this is it and update the post.

1 Like
4

I think I found the reason: the UEFI only adds the shim.efi to the boot list (because they’re signed by Microsoft?)

Reproduction:

  1. Use efibootmgr to delete all entries (efibootmgr -B -b 12af for each entry)
  2. Reboot the laptop, enter the UEFI settings
  3. Look at automatically created boot order for “Hard Disk” - Windows is there, “Fedora” is there. Manjaro is missing

Negative reproduction:

  1. As above
  2. Move/delete Fedora’s .CSV (they are not used if you reboot now, Fedora would still be autodetected.)
  3. Move/delete Fedora’s shims .efi
  4. Reboot into firmware settings. Fedora is gone from the list too.

You can double-check WHAT the firmware auto-detects if you look at the loader path in efibootmgr. Mine found shim.efi as the loader.

Conclusion: Auto-detection only works if the (signed?) shimx64.efi is found.

Unanswered: How does UEFI decide upon the “Fedora” name (spelled this way)? (could be the parent dir name i.e. /boot/efi/fedora/shim.efi

Who maintains this part of the distro, to talk about it?

If I look at Arch forums (one, two) or their wiki, it looks like Arch only has “grubx64.efi” too and most “installation issues” are solved by manually adding the boot entry with efibootmgr or using the so-called “firmware workarounds” where people drop grub.efi into UEFI’s fallback file paths instead of doing it properly.

UEFI by AMI:

BIOS Vendor: American Megatrends
Core Version: 5.19
Compliancy: UEFI 2.7; PI 1.6

For completeness, here are directory listings of /boot/efi/<dir>:

Listings 
# tree /boot/efi/fedora
fedora
├── BOOTIA32.CSV
├── BOOTX64.CSV
├── gcdia32.efi
├── gcdx64.efi
├── grub.cfg
├── grubia32.efi
├── grubx64.efi
├── mmia32.efi
├── mmx64.efi
├── shim.efi
├── shimia32.efi
└── shimx64.efi

# tree /boot/efi/manjaro
manjaro
└── grubx64.efi
Fedora's CSV files

UTF-16LE with BOM and \n new lines (the definition ends with an \n, thus the CSV has one populated and one empty line)

BOOTX64.CSV

shimx64.efi,Fedora,,This is the boot entry for Fedora

BOOTIA32.CSV

shimia32.efi,Fedora,,This is the boot entry for Fedora
5

Did you alread disable secure boot :wink: ?

6

Yes it is disabled during tests. If the UEFI settings are completely reset, SecureBoot would be “Enabled” and “SecureBoot Mode” “Standard” (i.e. built-in keys) - when Enabled, it doesn’t let me boot Manjaro’s Grub.

Corrected above post: UEFI auto-detects only fedora/shim.efi, not fedora/shimx64.efi