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
(Please bear with me in case I should have posted this in an existing topic. I’ll get better at this.)
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.
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.)
@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.
Changing those 5 lines (with the cryptomount -u command) worked for me, as long as I don’t runsudo 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.
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.
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.
