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