Your booted entry 'UEFI OS' is not the same as 'Manjaro'

Anthony · 13 August 2025 12:44

Hi,
after the latest manjaro update [Stable Update] 2025-08-11, this message was part of the output.

[ALPM-SCRIPTLET] Warning: GRUB bootloader at '/boot/efi/EFI/Manjaro' was updated.
[ALPM-SCRIPTLET] Your booted entry 'UEFI OS' is not the same as 'Manjaro'.
[ALPM-SCRIPTLET] This may be a rescue ISO, but if not check your EFI boot priority.

No, I’m not using a rescue ISO.

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

have been updated and are identical.

Is this “EFI boot priority”?

efibootmgr -v
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* Manjaro     HD(1,GPT, ...)/\EFI\Manjaro\grubx64.efi
Boot0001* UEFI OS     HD(1,GPT, ...)/\EFI\BOOT\BOOTX64.EFI0000424f

It boots perfectly fine, but I want to make sure that I am not booting a leftover entry from another location or something else.

How do I check if everything is really okay?
Why was this warning displayed?

philm · 13 August 2025 13:04

Boot order seems fine. @linux-aarhus added the warning message. Seems your 2nd entry triggered it somehow …

Anthony · 13 August 2025 14:27

Could it have something to do with me using
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --removable
to fix broken manjaro boot once?

Teo · 13 August 2025 14:31

Yes, because --removable writes to EFi/boot (and ignores efi/manjaro). Repeat it without that. (Or with --recheck, although it should not make a difference…but i use it as it is in the wiki)

Anthony · 13 August 2025 15:18

That command was used more than a year ago. Now after the update, both entries are binary identical. Not sure if I also checked before updating. Maybe the warning was referring to the state before the update.

Aragorn · 13 August 2025 15:23

This is what the install-grub script — not to be confused with grub-install — (and pacman hook) is for. It makes sure both EFI stubs are identical.

linux-aarhus · 13 August 2025 16:19

The script originally printed a waning message - but it was not clear what it was about.

I only changed it to make it clear it is not a failure in any way - as there is valid reasons why the currently active bootnum is not the Manjaro efi entry - e.g. booting from a live media or some kind of rescue ISO.

The message is just that - a message - it can be ignored - it simply follows the standard of using Warning to signal an important change.

This output shows the importance of keeping the grub EFI-loaders in sync.

If the EFI-loaders are not identical, the grub configuration file ((etc/grub/grub.cfg) generated by the grub-mkconfig or update-grub will not match the configuration expected by EFI/BOOT/BOOTX64.EFI and the system becomes unbootable.

The install-grub script ensures they are in binary identical, generates the configuration and ensures there is a Manjaro EFI entry in the system’s list of EFI-loaders - if none exist the script creates one.

omano · 13 August 2025 21:37

This kind of entry is what the motherboard detects automatically for Manjaro, for example after a BIOS update, it erases the BIOS with new defaults and motherboard can not detect Manjaro directly (maybe in some rare case it can I don’t know). This entry is not bootable you’ll end up in GRUB Rescue Mode. In this case you simply need to boot a Manjaro live USB and boot your system from there by using the Detect Boot Loader entry (I think this is what it is called) and after booting your system, you reinstall GRUB properly to get the proper Manjaro entry (see WIKI).

bendipa1 · 14 August 2025 11:38

Anthony:

Hi,
after the latest manjaro update [Stable Update] 2025-08-11, this message was part of the output.

[ALPM-SCRIPTLET] Warning: GRUB bootloader at '/boot/efi/EFI/Manjaro' was updated.
[ALPM-SCRIPTLET] Your booted entry 'UEFI OS' is not the same as 'Manjaro'.
[ALPM-SCRIPTLET] This may be a rescue ISO, but if not check your EFI boot priority.

No, I’m not using a rescue ISO.

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

have been updated and are identical.

Is this “EFI boot priority”?

efibootmgr -v
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* Manjaro     HD(1,GPT, ...)/\EFI\Manjaro\grubx64.efi
Boot0001* UEFI OS     HD(1,GPT, ...)/\EFI\BOOT\BOOTX64.EFI0000424f
`

bootx64.efi and grubx64.efi should be identical. The latter is the all important UEFI boot file that takes you to the grub menu. Bootx64.efi is just a standard copy - like a backup of grubx64.efi. You could change its name to … cauliflower and you’d still be able to boot to grub.

linux-aarhus · 14 August 2025 12:03

I wouldn’t rename it - all firmware implementations are coded to look for this specific name - for a Manjaro Linux system it is a fallback - in case the firmware lose the Manjaro entry - which is why it is super important the two loaders are binary identical.

bendipa1 · 14 August 2025 14:14

I was just making the point that bootx64.efi seems to play no direct part in the booting process for Linux. But in Windows it does. IIRC if you remove it or rename it in a Windows ESP you will get a BSOD booting error.

omano · 14 August 2025 16:35

Are you able to boot from the ‘fallback’ entry? Because it never works on all the computers I had on my hands. You go to Grub Rescue mode with that entry.

linux-aarhus · 14 August 2025 16:42

Yes - but only if below condition is true - and I had precisely this issue - they were not identical - and I was greeted with the grub_shim error message - this was described in the unstable update thread a couple of weeks back.

That is correct - if the EFI/BOOT/BOOTX64.EFI is not binary identical to EFI/Manjaro/grubx64.efi - the grub.cfg will throw you into Grub Rescue mode.

That is the install-grub task - to ensure the fallback entry is the same as the primary entry…

omano · 14 August 2025 16:46

Then I will recheck the WIKI because I don’t recall a mention about manually making sure this is identical to the Manjaro binary, in the GRUB Install/Restore page (when the WIKI will work because currently it is down…).

Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Cannot access the database)

Backtrace:

#0 /var/www/html/includes/libs/rdbms/loadbalancer/LoadBalancer.php(995): Wikimedia\Rdbms\LoadBalancer->reportConnectionError()
#1 /var/www/html/includes/libs/rdbms/loadbalancer/LoadBalancer.php(960): Wikimedia\Rdbms\LoadBalancer->getServerConnection(0, 'manjarowiki_fZ7...', 0)
#2 /var/www/html/includes/page/WikiPage.php(512): Wikimedia\Rdbms\LoadBalancer->getConnection(-1)
#3 /var/www/html/includes/page/WikiPage.php(655): WikiPage->loadPageData()
#4 /var/www/html/includes/page/WikiPage.php(729): WikiPage->exists()
#5 /var/www/html/includes/page/WikiPage.php(328): WikiPage->getContentModel()
#6 /var/www/html/includes/page/WikiPage.php(314): WikiPage->getContentHandler()
#7 /var/www/html/includes/page/Article.php(2400): WikiPage->getActionOverrides()
#8 /var/www/html/includes/actions/Action.php(119): Article->getActionOverrides()
#9 /var/www/html/includes/actions/Action.php(178): Action::factory('view', Object(Article), Object(RequestContext))
#10 /var/www/html/includes/MediaWiki.php(171): Action::getActionName(Object(RequestContext))
#11 /var/www/html/includes/MediaWiki.php(875): MediaWiki->getAction()
#12 /var/www/html/includes/MediaWiki.php(546): MediaWiki->main()
#13 /var/www/html/index.php(53): MediaWiki->run()
#14 /var/www/html/index.php(46): wfIndexMain()
#15 {main}

linux-aarhus · 14 August 2025 16:48

You are possibly correct - this has never been described in detail before - I was lucky to run into this specific issue and thus be able to describe it more detailed.

@philm - the wiki instance has run out of disk space - try pruning the logs or whatever needs to be done.

Teo · 14 August 2025 19:07

I can boot perfectly fine from both entries on my Lenovo (Insyde) bios. In fact i made the fallback one a uefi shell instead of grub.

But my config is simple - no secure boot, no encryption, ext4. I suspect adding luks or btrfs will complicate things.

omano · 15 August 2025 07:29

I installed install-grub package but it made no difference, the EUFI_OS entry is not bootable.
I tried different things to try to make it bootable, I manually triggered the /usr/bin/install-grub script, I reinstalled Grub manually with sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro --recheck and also just reinstalled the grub package. The EUFI_OS entry is still not bootable it goes to Grub Rescue Mode.

Teo · 15 August 2025 10:54

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable

…Would be the command to replace the default entry (because there is supposedly only one bootloader on removable drives).
But i would put something else there. Refind for example. In case grub breaks.

linux-aarhus · 15 August 2025 11:58

Are you sure the files are identical?

Listing the efi loaders using efibootmgr

[tiger efi]# efibootmgr
BootCurrent: 000A
Timeout: 1 seconds
BootOrder: 000A,0001,0003,0008,000B,0002,0004,0000,0007,0006,0005
Boot0000  Lenovo Cloud  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(https://download.lenovo.com/pccbbs/cdeploy/efi/boot.efi)
Boot0001* UEFI OS       HD(1,GPT,519fa53d-c862-4efb-948b-eee1a5d9c584,0x1000,0x96000)/\EFI\BOOT\BOOTX64.EFI0000424f
Boot0002  UEFI: HTTP IPv4 Marvell AQtion 10Gbit Network Adapter PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri()0000424f
Boot0003* UEFI: PXE IPv4 Marvell AQtion 10Gbit Network Adapter  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)0000424f
Boot0004  UEFI: HTTP IPv6 Marvell AQtion 10Gbit Network Adapter PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv6([::],0,Static,[::],[::],64)/Uri()0000424f
Boot0005* Generic Usb Device    VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0006* CD/DVD Device VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0007  Win VDI Boot  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(https://download.lenovo.com/pccbbs/cdeploy/vdiboot/efi/vdi.efi)
Boot0008* UEFI: PXE IPv6 Marvell AQtion 10Gbit Network Adapter  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv6([::],0,Static,[::],[::],64)0000424f
Boot000A* Manjaro       HD(1,GPT,519fa53d-c862-4efb-948b-eee1a5d9c584,0x1000,0x96000)/\EFI\MANJARO\GRUBX64.EFI
Boot000B* UEFI OS       HD(2,GPT,212361e5-1ff9-c90e-c5bb-719baa5ae586,0x3a5c0fd8,0x10000)/\EFI\BOOT\BOOTX64.EFI0000424f

[tiger efi]# tree .
.
├── EFI
│   ├── boot
│   │   └── bootx64.efi
│   ├── Manjaro
│   │   ├── fw
│   │   ├── fwupdx64.efi
│   │   └── grubx64.efi
│   ├── Test
│   │   └── grubx64.efi
│   └── UpdateCapsule
│       └── fwupd-94d6edee-8f19-40a9-be14-d881e2e3d55c.cap
├── loader
│   └── random-seed
└── main.efi

8 directories, 7 files

[tiger efi]# ls -la EFI/Manjaro
total 232
drwx------ 3 root root   4096 24 jun 14:21 .
drwx------ 6 root root   4096  2 aug 16:19 ..
drwx------ 2 root root   4096  1 aug 07:01 fw
-rwx------ 1 root root  67753 21 sep  2024 fwupdx64.efi
-rwx------ 1 root root 155648  3 aug 13:09 grubx64.efi

[tiger efi]# ls -la EFI/boot
total 164
drwx------ 2 root root   4096  7 aug  2024 .
drwx------ 6 root root   4096  2 aug 16:19 ..
-rwx------ 1 root root 157816 11 jul 16:33 bootx64.efi

As you can see the loaders are not binary identical - and booting the UEFI OS entry result in the famous grub shim message.

[tiger efi]# install-grub
[D] GRUB 2 EFI-x64 found
[D] Checking EFI-Directory: /boot/efi
[D] Found EFI Bootloader: /boot/efi/EFI/Manjaro/grubx64.efi
Install command will be: grub-install --no-nvram --target=x86_64-efi --efi-directory=/boot/efi         --bootloader-id=Manjaro --recheck --force
Do you want to proceed? (yes/no) y
ok, we will proceed
Grub will be installed on: EFI
Installing for x86_64-efi platform.
Installation finished. No error reported.
Update Grub Menu
Do you want to proceed? (yes/no) y
ok, we will proceed
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-linux616
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux616.img
Found linux image: /boot/vmlinuz-6.16-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.16-x86_64.img
Found initrd fallback image: /boot/initramfs-6.16-x86_64-fallback.img
Found linux image: /boot/vmlinuz-6.12-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.12-x86_64.img
Found initrd fallback image: /boot/initramfs-6.12-x86_64-fallback.img
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
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

[tiger efi]# ls -la EFI/boot
total 164
drwx------ 2 root root   4096  7 aug  2024 .
drwx------ 6 root root   4096  2 aug 16:19 ..
-rwx------ 1 root root 157816 11 jul 16:33 bootx64.efi

[tiger efi]# ls -la EFI/Manjaro
total 232
drwx------ 3 root root   4096 24 jun 14:21 .
drwx------ 6 root root   4096  2 aug 16:19 ..
drwx------ 2 root root   4096  1 aug 07:01 fw
-rwx------ 1 root root  67753 21 sep  2024 fwupdx64.efi
-rwx------ 1 root root 155648 15 aug 13:51 grubx64.efi

The original intention with the install-grub script - for what I know - was to ensure the two loaders is kept in sync - but it is clear from this test run - that does not happen in this run.

I am going to investigate this - but I think it is failing because one of the checks is not case insensitive - and while FAT32 is indeed case insensitive file system - it will become case sensitive when mounted by a Linux kernel - possibly caused by inheritance.

I found the reason why the fallback was not updated.

With this fix - install-grub correctly updates the fallback entry to match the Manjaro entry and it is then possible to boot the UEFI OS entry too

[tiger efi]# efibootmgr -b 000B -B
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 000A,0001,0003,0008,0002,0004,0000,0007,0006,0005
Boot0000  Lenovo Cloud  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(https://download.lenovo.com/pccbbs/cdeploy/efi/boot.efi)
Boot0001* UEFI OS       HD(1,GPT,519fa53d-c862-4efb-948b-eee1a5d9c584,0x1000,0x96000)/\EFI\BOOT\BOOTX64.EFI0000424f
Boot0002  UEFI: HTTP IPv4 Marvell AQtion 10Gbit Network Adapter PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri()0000424f
Boot0003* UEFI: PXE IPv4 Marvell AQtion 10Gbit Network Adapter  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)0000424f
Boot0004  UEFI: HTTP IPv6 Marvell AQtion 10Gbit Network Adapter PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv6([::],0,Static,[::],[::],64)/Uri()0000424f
Boot0005* Generic Usb Device    VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0006* CD/DVD Device VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0007  Win VDI Boot  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(https://download.lenovo.com/pccbbs/cdeploy/vdiboot/efi/vdi.efi)
Boot0008* UEFI: PXE IPv6 Marvell AQtion 10Gbit Network Adapter  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/MAC(047bcba9a1ee,0)/IPv6([::],0,Static,[::],[::],64)0000424f
Boot000A* Manjaro       HD(1,GPT,519fa53d-c862-4efb-948b-eee1a5d9c584,0x1000,0x96000)/\EFI\MANJARO\GRUBX64.EFI

[tiger efi]# ls -la EFI/boot
total 160
drwx------ 2 root root   4096  7 aug  2024 .
drwx------ 5 root root   4096 15 aug 14:12 ..
-rwx------ 1 root root 155648 15 aug 14:19 bootx64.efi

[tiger efi]# ls -la EFI/Manjaro
total 232
drwx------ 3 root root   4096 24 jun 14:21 .
drwx------ 5 root root   4096 15 aug 14:12 ..
drwx------ 2 root root   4096  1 aug 07:01 fw
-rwx------ 1 root root  67753 21 sep  2024 fwupdx64.efi
-rwx------ 1 root root 155648 15 aug 14:18 grubx64.efi

Teo · 15 August 2025 13:06

The original intention with the install-grub script - for what I know - was to ensure the two loaders is kept in sync

Ahm, a semi offtopic: i do not think install-grub serves that purpose. It is more of a easy way to input the long grub-install with suitable parameters and do it automatically instead of the need to fix later with live usb.
Me personally is totally against some script doing something without me asking for it. This is actually the problem with the OEM firmware updates sometimes and some windows upgrades - they reset the fallback or EFI variables.

In any case, so far it didn’t happen to me that install-grub borked my fallback efi (which is a shell). For me it is the right behavior.

So i hope it is a language misunderstanding. The thing has to keep the grub on the root partition and the manjaro grub on the ESP in sync.
This is what it did when i last checked the code in the early development (have to admit i didn’t read the latest changes, maybe that’s why i misunderstood something).

The whole case (in) sensitivity problem comes from trying to detect where the current entry is installed and update it in the rare case someone installed the manjaro grub as fallback.
So it is a sync between
rootgrub AND (fallbackgrub OR namedgrub) and not
rootgrub AND fallbackgrub AND namedgrub

This was my understanding until now.