efi/boot/bootx64.efi is the “fallback” path that is used when UEFI configuration in bios is wrong. So this file works same as MBR boot, in that when you say to bios “boot from this disk” it boots from that path. Normal UEFI boot procedure is to boot the path stored in bios (here should be /EFI/Manjaro/grubx64.efi) .
Finally! This one solved the issue for me. Thank you! Don’t really know why the fallback is being used though… My bios configuration hasn’t changed since the stable update. I guess this will reappear next time I’ll run grub-install so need to remember that. Don’t really like the ‘solution’ though. Feels like it should work without it. Does anyone have an idea how this can be fixed permanently? What I’ve noticed was that the first unlock prompt was referencing UUID without dashes, the other unlock promt (after the cryptodisk error message) was referencing UUID with dashes. I guess that’s why the decryption failed and showed the cryptodisk error message. When I cp /boot/efi/EFI/Manjaro/grubx64.efi /boot/efi/EFI/boot/bootx64.efi the first password promt had the UUID displayed with dashes and then the futher decryption worked.
UPDATE:
Just run efibootmgr -v and it seems that the bootx64.efi is set as first in order
Timeout: 1 seconds
BootOrder: 0001,0000
Boot0000* manjaro HD(1,GPT,426c0f14-e61f-9249-97a9-4496a9a94d7f,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 14 0f 6c 42 1f e6 49 92 97 a9 44 96 a9 a9 4d 7f 02 02 / 04 04 36 00 5c 00 45 00 46 00 49 00 5c 00 6d 00 61 00 6e 00 6a 00 61 00 72 00 6f 00 5c 00 67 00 72 00 75 00 62 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
Boot0001* UEFI OS HD(1,GPT,426c0f14-e61f-9249-97a9-4496a9a94d7f,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 14 0f 6c 42 1f e6 49 92 97 a9 44 96 a9 a9 4d 7f 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
Will change to Manjaro and see if it works ok. Will update this post with results.
UPDATE 2:
After changing the boot order everything is working fine. 
@varikonniemi thanks for the explanation, @Ancestr thanks for the pointers. I still don’t quite understand it. The order changed and the fallback was working albeit with the ‘no such cryptodisk found’ error message. However, after installing the new grub into Manjaro, the fallback stopped working. Shouldn’t they be independent? In any case, I also changed the order and it works.
I have got 2 encrypted drives.
❯ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 116,8M 1 loop /var/lib/snapd/snap/core/14784
loop1 7:1 0 116,8M 1 loop /var/lib/snapd/snap/core/14946
loop2 7:2 0 55,6M 1 loop /var/lib/snapd/snap/core18/2714
loop3 7:3 0 55,6M 1 loop /var/lib/snapd/snap/core18/2721
sda 8:0 0 1,8T 0 disk
└─sda1 8:1 0 1,8T 0 part
└─luks-654e7435-e8ca-4b13-8abb-18733a64eff7
254:1 0 1,8T 0 crypt /home
nvme0n1 259:0 0 238,5G 0 disk
├─nvme0n1p1 259:1 0 1G 0 part /boot/efi
└─nvme0n1p2 259:2 0 237,5G 0 part
└─luks-3352fb98-8855-4902-9528-db429256c07d
254:0 0 237,5G 0 crypt /
How do I use grub-install the right way for this setting?
so you are using EFI?
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
and then update grub config
sudo grub-mkconfig -o /boot/grub/grub.cfg
Found some nice info in the stable branch announcement:
2 Likes
Are you sure about this?
I’ve used full disk encryption + TimeShift since original install 2 years ago aprox and
Even tho i havent restored anything last 6 months i restored snapshots many times earlier
when i was fiddling with Wayland and HW video decoding in firefox.
Never got that to work but each time i failed i restored a older snapshot
We’re talking probably about 15+ restores.
I dont think i did anything special to make it work. It’s just a basic Manjaro install
because i’m fairly new to linux and Manjaro.
List boot order
efibootmgr
…find the ‘manjaro’ number and if it isn’t the first (probably) then re-order things to put manjaro first…
sudo efibootmgr -o XXXX,YYYY... (smallcaps ‘o’)
For more details and formatting
man efibootmgr
efibootmgr is very important in this context (grub-install) and should go together, once the grub is installed we should recheck the boot order. Why the boot order gets messed up I’m not sure (could be due to some install or BIOS menu, or failure to boot). If you can’t boot into the system do the same from the Live USB.
1 Like
This solved my issue. 
Thanks. As a relative n00b, is this a process I should complete whenever I see GRUB mentioned in the update? Before rebooting, I imagine?
Watch for grub-related info in announcements posts, check the date of files under /boot/grub/…, do not update if you see grub / systemd / mkinitcpio / cryptsetup / lvm / %younamewhatelseyoufearbreakingof% and you know you have no time to fix it. Always works for me.
And yes: if you’re ready to update these packages, you’d better make a backup right before that.
1 Like
This change to cryptsetup might also affect this. currently trying to push a working version to testing and stable branches: these libraries are installed by systemd hook now · archlinux/svntogit-packages@1f0acab · GitHub
1 Like
If you don’t mind, what’s the ELI5 version of what this does? I’m not familiar enough with code to figure out what it does. 
If you are not sure about the incoming changes, you should search in the forum for upgrade guidelines or wait till people post if they encountered any troubles during the upgrade.
In my understanding grub-install is only necessary when grub (the bootloader code itself) was updated and is now incompatible with old generated configurations
(update-grub/grub-mkconfig → /boot/grub/grub.cfg) and therefore needs to be re-installed and re-configured.
Please correct me if I’m wrong…
It would be nice if pacman itself could detect if a re-installation of grub is necessary.
Due to [1] it is not completely clear to me if this could be done in the preparation phase of the update, or is even considerable due to its risk of ending in an unbootable state:
lenhuppe 2022-12-11 00:23:31
There is no pacman hook to reinstall and reconfigure grub because it can be configured many different ways.
You have the option of creating your own pacman hook to reinstall and reconfigure grub automagically.
References:
This bit me hard right when I started using Linux full time. Just over 2 years ago I think, I installed Manjaro as my daily. Ran it about a month before I hit a grub issue. Took me 2 or 3 days and a few years off my life to repair. Gotta lot of help here. 
I applied the 2023-04-06 update in which philm made changes to cryptsetup and systemd to fix the issue discussed in this thread, but unfortunately it didn’t fix the error and the nag screen persists.
For others going through this thread who also have the no such cryptodisk issue but can still boot, the solution reported as working most often seems to be the one described here or here, but running sudo grub-install does have some risks (also reported in the thread), so I’m going to find some time next week to back everything up before trying it and reporting back.
1 Like
Cross-posting as this topic seems to have more people, though technically not exactly the same thing (since my problem was having the message, but my computer did still boot). Hopefully that’s OK:
2 Likes
Thank you, @brn! That was what I needed - I tried first with the default menu entry only (can’t hurt to be careful) and worked as hoped for…
1 Like
Having same issue after recent system update.
I have the problem on two different machines now.
error: sparse file not allowed.
error: no such cryptodisk found, perhaps a needed disk or cryptodisk module is not loaded.
452: out of range pointer: 0x95d67020
Aborted. Press any key to exit.
I’m not an expert and I did not follow this thread - but I sound that the cryptodisk module was not added to GRUB_PRELOAD_MODULES (see Can't boot LUKS encrypted install after 2023-03-31 stable update - #7 by philm)
Can you try to boot from a live usb stick + check if you can boot into your original OS? Can't boot LUKS encrypted install after 2023-03-31 stable update - #26 by Tobiwan
I followed the following steps:
The problem was not solved, the errors come, but after entering the passphrase for the second time, my system boots. I have to enter the passphrase two times for my system to boot. Very weird…