"Cannot open access to console, the root account is locked." following 2026-05-27 Stable Update

[Pedrolas]

Big trouble after upgrade:

[TIME] Timed out waiting waiting for device /dev/.a88b71-(...)
[DEPEND] Dependency failed for File System .a88b71(...)
[DEPEND] Dependency failed for /sysroot.
[DEPEND] Dependency failed for Initrd Root File System
[DEPEND] Dependency failed for Mountpoints Configures in the Real Root
[DEPEND] Dependency failed for Initrd Root Device
You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, or "exit" to continue bootup.
Cannot open access to console, the root account is locked. See sulogin(8) man page for more details.
Pres Enter to continue.

I managed to boot from a Live USB and mount the / partition (encrypted with LUKS), and I was even able to successfully regenerate the initramfs image, but when I rebooted, I got the same error again.

I’ve also tried restoring a snapshot created with Timeshift, but I keep getting this error:

“Boot device not selected” An encrypted device is selected for the root file system (/). The boot directory (/boot) must be mounted on a non-encrypted device for the system to boot successfully.

And that’s where I’m stuck

Mod edit: Added code formatting.

[Aragorn]

Welcome to the forum, @Pedrolas!

Your problem appears to be that you have adopted the new systemd-based hooks in /etc/mkinitcpio.conf without also adopting the new and related syntax for the encrypted device in your boot loader configuration — /etc/default/grub, and possibly other places.

You must either adopt the correct new syntax (see this Arch Wiki page) or revert your /etc/mkinitcpio.conf back to the old udev/busybox-based hooks (see this Arch Wiki page).

[Teo]

Can't boot after stable update 2026-05-27

Nope, everything is as expected. This config cannot work For the sake of learning you can read the other similar topic starting at post 10 The easiest would be to return to udev until you learn how to make a proper systemd config (i have linked the wiki). So replace HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block filesystems fsck) With HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt filesystems fsc…

Did you happen to change something in you mkinitcpio? Look in the above topic for a solution.

[BG405]

Hi @Pedrolas and welcome! I’ve moved your post into its own dedicated Topic for better attention.

It may of course help if you provide your System Information:

inxi -zv8c0

… from within chroot.

Note that the output produced by this command is privacy-filtered.

Please also remember to use proper code formatting as this makes it much easier to read on the Forum:

[Mini How-To] format code or command output

Select and copy all the text in the Terminal window (minus the prompt, if you are using zsh).
Then paste the output in between two lines containing three backticks
```
or three tildes
~~~

Or:
Copy & paste, then highlight the pasted text and click the </> button at the top of the reply window (easier for smaller outputs).

Cheers!

[Pedrolas]

I’m pretty new to Linux, but I’m getting the hang of it and I think I’ll be able to follow your helpful instructions.

I changed the HOOKS in my mkinitcpio.conf file from:

“HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block filesystems fsck)”

to

“HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt filesystems fsck)”

I’m regenerating the ramdisk environment and will update this post with whatever happens

Post Update:
Finally, after changing the “HOOKS,” regenerating the initramfs, and updating GRUB, I can finally access my system.

This is the first time I’ve used chroot (manjaro-chroot)

Thank you very much for the help. Especially to @Teo, who pointed out how to modify mkinitcpio.conf to revert to udev and recover the system.

This is the first time this has happened to me. I guess that’s how you learn.