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

I had a quick look at other posts with a similar error, but they’re older and seem to be different.

After pamac updated my packages the computer froze, so at some point I could only force a reboot by holding the power button. Since then I get the following message after decrypting my harddrive (luks) and choosing Manjaro in gnome.

"Fehler [Error]: no such cryptodisk found, perhaps a needed disk or cryptodisk is not loaded.

Beliebige Taste drücken, um fortzusetzen [Push any key to continue]"

I can’t make sense of this at all, since I would expect the error to occur when I enter my luks password and the computer to not boot at all.

Lucky me :slight_smile:

(Please bear with me in case I should have posted this in an existing topic. I’ll get better at this.)

I have no dual boot but same happens to me, everything seems to work normally after I press any key to continue though.

Read [Stable Update] announcements for fix

It is always nice to open a support thread for things which is a hot topic right now and gets even discussed for days by now …

So here again:

  • /etc/default/grub needs to been checked for GRUB_PRELOAD_MODULES="cryptodisk part_gpt part_msdos" and GRUB_ENABLE_CRYPTODISK=y
  • grub menu needs to been updated via update-grub

That should be the only thing you may need. Installing grub to MBR/UEFI always should be the last resort unless you want to have security updates or the latest grub version on your system. If your system however has a broken bootloader installation you may need to restore it. Read the linked discussion thread for more info about further solutions.

@philm Having the same issue “no such cryptodisk found” since a couple of days, but the system boots successfully after pressing any key. I did not interrupt any system update and did not encounter any errors. Your suggested points are already applied for me so that does not fix the issue. (also ran update-grub again). Do you have other ideas?

@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?

3 Likes

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)
to
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.

3 Likes

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.