I updated my Manjaro instance yesterday. I went to login today. I entered my password at the encryption screen, and it tells me “Slot 0 opened”. It usually doesn’t take long for the Manjaro desktop to appear. Today, it’s taking 5-10+ minutes, and not even getting any further. I’ve tried at least 3 times now to reboot, and try again, but it just hangs here.
It sounds like an unfinished update.
If that’s the case, you’ll need to boot from USB, chroot (after you opened the encrypted container)
and make sure the the update did finish properly.
I think this is related to /etc/openswap.conf.
After you have booted a rescue ISO follow [root tip] [recovery] Basic Manjaro Linux Rescue and Recovery to mount your encrypted system and enter chroot.
Then check the configuration.
I recommend disabling hibernation on an encrypted system.
1 Like
Have you properly tended to your .pacnew files?
There was a change to /etc/mkinitcpio.conf a while ago, which also required a change to /etc/default/grub if your system uses encryption and hibernation.
2 Likes
I am in. I don’t see hibernation mentioned in this file.
I stepped away for a few minutes, and my screen is black. I move my mouse, it reveals itself, then goes away. I now can’t interact with my session.
When I try to do a pacman -Syu, it tells me System disk not found, Unable to run timeshift-autosnap! Please close timeshift and try again.
Can you expand upon this? I’m not familiar. Thanks!
You now need a new syntax for the resume device, using “rd.luks.key=”, as in the example below. 
GRUB_CMDLINE_LINUX="rd.luks.key=/crypto_keyfile.bin rd.luks.name=SOME-LONG-STRNG-HERE=root
Do I also need to change cryptdevice to rd.luks.name?
Yes, that is correct.
Thank you for the quick response.
It’s still not letting me in. Here’s what that line looks like:
rd.luks.key=/crypto_keyfile.bin quiet rd.luks.name=:luks- root=/dev/mapper/luks- splash udev.log_priority-3
Well, I’m afraid I could only give you the advice so far as I myself have picked it up from other forum members, because I don’t use either encryption or hibernation. But I’m sure someone else in the community will pick up this thread soon. 
P.S.: Did you run “sudo update-grub” after making the changes?
Nope, I was thinking maybe I’d have to do that… let me try that! I hate having to log out, then re-type all the commands again to get back into my chroot environment.
Well, of course you have to do that. How else would grub know about it at boot time, before it can even read the root filesystem, which is where /etc/default/grub lives? 
Still doesn’t want to load. 
And you are certain that the UUIDs are correct? 
The absolute easiest way to solve this is:
Restore the HOOKS line in /etc/mkinitcpio.conf to what it was.
… same goes for /etc/default/grub of course …
no problem whatsoever then
Then read up on what the change from busybox based init to systemd based init entails.
and be prepared for trial and error with an always safe and working option to fall back on.
“The old way” - it’ll keep working for quite some time.
(and the initrd is actually smaller )
No need for immediate action.
2 Likes
No expert here, but I’m not sure those two spaces should be there? 
1 Like
This is the part @BG405 is talking about, and he’s right.
rd.luks.name=:luks- root=/dev/mapper/luks- splash
↑ ↑
Those spaces should not be there.
2 Likes
when I posted, I had this in there: < u u i d > (spaces removed, of course), but I think it removed it.
No need to censor the UUID - it just makes things more unclear.
I think, apart from the spaces, there is also a colon
(:) in there which does not belong - at least not in this place
after the = sign
https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader
2 Likes