"no such cryptodisk found" error without breaking boot-up ?!

@philm I can confirm that modifying /etc/default/grub and running update-grub did not fix the issue, like in @TrueRandom’s case. I’ve been reading related threads today (both old and recent) and had tried those fixes separately and together.

No dual boot, I’m on testing, the error first appeared after the last round of updates (which I installed yesterday), the system boots successfully after pressing a key or just waiting 10 seconds. Interestingly, that error also appears when the system’s shutting down.

@TrueRandom, I suggest going through the main thread shared by philm where this is being discussed: Can't boot LUKS encrypted install after 2023-03-31 stable update

As of now, the solution reported as working most times seems to be the one described here or here, but running sudo grub-install does have some risks (also reported in the thread), so worth thinking about twice.

For me it also didn’t work, but as my machine boots I’ll rather wait a bit for more insights.

(Something else that started malfunctioning are the brightness keys, which are on F11&12. I know there are other posts for this topic, just mentioning, as it also started after the update.)

If nothing works to fix, just back up your data and make a new install.

@eugen-b This is exactly what I did. I re-installed to the same partition, encrypted using the default method of the installer. Boots fine for the first time. After the upgrade, it is broken with the error message above. Fresh installation, no customization.

The new installation should be done with a newer install medium if available. One which would come with the latest version of grub and cryptsetup.

I’d tried everything people suggested in many places, and only one thing worked, but I’m pretty sure it’ll be temporary (until grub is updated):

Mentioned in [Stable Update] 2023-03-31 - Kernels, Plasma 5.27 LTS, Pamac, Phosh, Mesa, LibreOffice:

Changing those 5 lines (with the cryptomount -u command) worked for me, as long as I don’t run sudo update-grub, because that will put back the malformed UUIDs.

Hopefully that will help others and potentially help fix this issue permanently (remove the dashes automatically for encrypted filesystems in the 'cryptomount -ucommand when building the/boot/grub/grub.cfg` file)? Where should I add this information for the involved developers to see?


I just started using Manjaro yesterday and also have this issue. I downloaded the minimal image for the KDE and installed with btrfs and encryption. After the first quite large upgrade of packages, the same error as mentioned by others popped up during boot. The notebook I am running Manjaro on is about 10 years old not sure if that can have some impact.

Thank you for that Solution! It’s the only one, that worked for me.

Remove the dash separators for all cryptomount -u entries

cryptomount -u 3722dfb2-3b32-414b-bd59-4329fa92b6a9 (example)
cryptomount -u 3722dfb23b32414bbd594329fa92b6a9

in /boot/grub/grub.cfg

To edit the grub.cfg I had to

sudo chmod 644 /boot/grub/grub.cfg

Even on a fresh Manjaro installation with encryption that error appears after the first update and reboot. I hope they will fix that soon.


I would, if there would be a newer one available than 22.0.5 which still has this issue.

Try this one [Call for Testers] Manjaro 22.1.0 Talos

I tried. When I was testing, RC2 was available with the broken services. To be honest, it is easier for me to just run update-grub than to fix systemd. Now that RC3 is available, I might give it another try as I still haven’t installed my backup and running a naked system at the moment. But there are already bug reports, so I am unsure whether this is a stable basis for a system that’s supposed to be my daily driver.

1 Like

Minor bugs will get fixed with rolling updates and there will be no difference between an RC3 and a future stable install.

The most important thing is that Grub is fixed.

Thanks. Will give it another try then before I restore my backup.

Is there a difference if I do it with sudo nano grub.cfg?
I tried but it didn’t solve the problem.

If you dont chmod 644 before, you cant edit the grub.cfg. After editing you can chmod back to 444 for correct rights. That was in my case. Because when i dont chmod 644 i got an error, i couldnt open the grub.cfg with Kate. I dont know how Nano handles that.

Did you changed all entries? I tink there was 5 in my grub.cfg.
Did you rechecked, that your changes was properly saved?

Keep in mind, if there is an update that triggers update-grub command, your grub.cfg will be overwritten again by that faulty uuids until anyone (Manjaro, Arch or Grub-Team) will fix that faulty generation of grub.cfg.

Those who have the issue should install this grub package and confirm it is working …


Now there was an update for grub. installed it. everything is fine after reboot. also after “update-grub” command and reboot everything works like a charm. thank you very much, philm!!!

1 Like

Administratively marked as solved :white_check_mark: to show as visible solution for everyone !

Same experience. Installed with my fingers crossed, restarted and everything stayed fine. :+1:t2:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.