There are two boot option for Manjaro in Bios.
One is called " manjaro" the other is called “UEFI os(manjaro)”.
When my system can’t boot I used manjaro chroot fixed “manjaro” so now I can use manjaro. but I am curious why “UEFI manjaro” still give me the following error and how to fix this one also.
Does “UEFI manjaro” boot from efi wheras “manjaro” but from the partition where majaro was installed?
If you look at the contents of /boot/efi/EFI, you will see these two entries — among others, given that you also have Microsoft Windows on your system. 
nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] > tree /boot/efi/EFI
/boot/efi/EFI
├── boot
│ └── bootx64.efi
└── manjaro
└── grubx64.efi
/boot/efi has a FAT-derived filesystem on it, which does not support hard-linking. Therefore, bootx64.efi and grubx64.efi are two individual files. However, under normal circumstances, these files should be identical.
Now, the way the UEFI boot manager works is that entries labeled “UEFI OS” always invoke the bootx64.efi file, or put concretely, as seen from within a running GNU/Linux system, /boot/efi/EFI/boot/bootx64.efi, whereas the Manjaro entry in the UEFI boot manager menu invokes the file /boot/efi/EFI/manjaro/grubx64.efi.
From your description, I gather that the Manjaro menu entry works, but that the “UEFI OS” entry for Manjaro does not work. This can happen after an update to Microsoft Windows, whereby Windows messes with the boot variables in the UEFI’s CMOS memory, not to mention that Windows may also decide to modify the wrong EFI system partition.
The best way to restore the operation of the Manjaro-specific “UEFI OS” entry in the UEFI boot manager menu is to reinstall GRUB and tell it that the drive in question is removable, in which case it will create a new /boot/efi/EFI/boot/bootx64.efi.
For more information, see…
man grub-install
Thanks a lot. I couldn’t find a clear explanation on google before.
You are right. Windows and manjaro are installed on two separate disk.
what if I simply cover the messed-up bootx64.efi file with the one from a good manjaro installation, or the bootx64.efi file in the manjaro intallation iso?
Thanks.
Just run grub-install from within your normal installation.
sudo grub-install --recheck && sudo update-grub
Just run efibootmgr -v and you’ll see which entry is grubx64 and bootx64. It’s likely that all you have to do is to delete the extra entry with efibootmgr -b %entrynumber% -B.
Should “UEFI OS” be deleted generally? I am trying to fix it.
or do you mean “add a working “UEFI OS” and delete the nonworking one”?
The non-working “UEFI OS” manjaro should be 0001 in the following list.
~ >>> efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0000,0001,0005
Boot0000* Windows Boot Manager HD(2,GPT,be6b6188-be36-43b1-b5c7-7acea25fde5d,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000000000100000010000000040000007fff0400
dp: 04 01 2a 00 02 00 00 00 00 18 0e 00 00 00 00 00 00 20 03 00 00 00 00 00 88 61 6b be 36 be b1 43 b5 c7 7a ce a2 5f de 5d 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 49 00 43 00 52 00 4f 00 53 00 4f 00 46 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 4d 00 47 00 46 00 57 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
data: 57 49 4e 44 4f 57 53 00 01 00 00 00 88 00 00 00 78 00 00 00 42 00 43 00 44 00 4f 00 42 00 4a 00 45 00 43 00 54 00 3d 00 7b 00 39 00 64 00 65 00 61 00 38 00 36 00 32 00 63 00 2d 00 35 00 63 00 64 00 64 00 2d 00 34 00 65 00 37 00 30 00 2d 00 61 00 63 00 63 00 31 00 2d 00 66 00 33 00 32 00 62 00 33 00 34 00 34 00 64 00 34 00 37 00 39 00 35 00 7d 00 00 00 00 00 01 00 00 00 10 00 00 00 04 00 00 00 7f ff 04 00
Boot0001* UEFI OS HD(1,GPT,d70966fb-531d-5340-b2c2-e707a0d3d711,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
dp: 04 01 2a 00 01 00 00 00 00 10 00 00 00 00 00 00 00 60 09 00 00 00 00 00 fb 66 09 d7 1d 53 40 53 b2 c2 e7 07 a0 d3 d7 11 02 02 / 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot0002* manjaro HD(1,GPT,d70966fb-531d-5340-b2c2-e707a0d3d711,0x1000,0x96000)/File(\EFI\MANJARO\GRUBX64.EFI)
dp: 04 01 2a 00 01 00 00 00 00 10 00 00 00 00 00 00 00 60 09 00 00 00 00 00 fb 66 09 d7 1d 53 40 53 b2 c2 e7 07 a0 d3 d7 11 02 02 / 04 04 36 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 41 00 4e 00 4a 00 41 00 52 00 4f 00 5c 00 47 00 52 00 55 00 42 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
Boot0005* UEFI OS HD(2,GPT,be6b6188-be36-43b1-b5c7-7acea25fde5d,0xe1800,0x32000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
dp: 04 01 2a 00 02 00 00 00 00 18 0e 00 00 00 00 00 00 20 03 00 00 00 00 00 88 61 6b be 36 be b1 43 b5 c7 7a ce a2 5f de 5d 02 02 / 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
No, it is best to keep that one around. It is meant to invoke the default boot loader of the drive itself, as opposed to an OS-specific boot loader.
Of course, operating systems can change this default boot loader, and Microsoft Windows is known to do that, since it wants to claim the whole computer to itself.
I ran the command in the terminal in manjaro
sudo grub-install --recheck && sudo update-grub
The “UEFI OS” manjaro in the bios still gives me the same warning mistake.
Is the EFI partition mounted and writable?
Sorry, I shouldn’t make such a mistake.
I will mount it and this should work. Thanks.
Make sure you mount it in the right place, i.e. /boot/efi. 
Thanks.
I mkdir and mount
sudo mount -o rw /dev/nvme0n1p1 /mnt/boot/efi
Then grub-install by
~ >>> sudo grub-install --recheck && sudo update-grub [1]
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.
Previously, I didn’t mount the efi, when I ran the command, there is no above error.
The following is my mounted efi. The bootx64’s modification date is 2020 so it should be working as before. I thought it was modified by windows hence I couldn’t use that option to boot anymore.
The grubx64.efi was modified just now, is it because I ran sudo grub-install --recheck && sudo update-grub? but at that time I didn’t mount efi, how could it be modified by the command?
./efi/EFI:
total 8
drwxr-xr-x 2 root root 4096 Sep 6 2020 boot
drwxr-xr-x 2 root root 4096 Sep 6 2020 Manjaro
./efi/EFI/boot:
total 132
-rwxr-xr-x 1 root root 135168 Sep 6 2020 bootx64.efi
./efi/EFI/Manjaro:
total 148
-rwxr-xr-x 1 root root 151552 Nov 22 16:22 grubx64.efi
I said /boot/efi, not /mnt/boot/efi. 
It may have been, but like I said, Windows also messes with the boot manager entries in the CMOS memory.
Yes.
Apparently it was already mounted in the right place. The location where you mounted it was wrong, so that didn’t matter.
It makes sense to me now. it was mounted at /boot/efi, so when I mount it at /mnt, it is not in /boot/efi anymore so the following command give me error.
sudo grub-install --recheck && sudo update-grub
But since I already ran the command when it is mounted in the right place, the UEFI os should be fixed, right?
~ >>> sudo mount -o remount,rw /dev/nvme0n1p1 /boot/efi [130]
[sudo] password for ma:
~ >>> sudo grub-install --recheck && sudo update-grub
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.0-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.0-x86_64.img
Found initrd fallback image: /boot/initramfs-6.0-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/sda2@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done
Yes it is, but then it’s mounted in two places at the same time.
In theory, yes, but you are ignoring what I said about Windows messing with your UEFI boot manager entries that are stored in CMOS memory.
Now that’s a whole other thing… 
No it shouldn’t. It can have any number but if you would like to have a strict order, you can do the following: delete 0001 entry as I described above, and then without reboot create a new entry for Manjaro with either long and error-prone efibootmgr -c %options_list% command or (better) just reinstall grub according to @Aragorn 's instructions. This will create a bootable Manjaro entry with a number 0001. Then remove the other 2 entries (0002 and 0005).
And yeah, initially I meant just deleting those “UEFI” entries since they are somewhat redundant and not working anyway. In fact, those entries are not necessary for booting a OS from a hard drive or SSD, usually they exist as a way to boot from a USB stick, but a normal installed OS, be it Windows or Linux, relies on other bootloaders (files) from other directories down the tree of EFI folder. You can see it in the output of your “efibootmgr -c” command.
Not sure, such entries’ usefulness is close to zero. Ubuntu and others use it as a fallback loader that restores a broken respective distro entry in case of a failure to load a regular loader like EFI\ubuntu\grubx64.efi, but Manjaro has no such mechanism if I remember correctly.
Windows just tries to make sure that if something happens to its main boot entry, user would be able to boot using the fallback. Can’t blame it for that, the length of this thread speaks for itself while Windows just boots right?
Except for when it doesn’t 