systemd-cryptsetup[601]: Failed to activate with specified passphrase. (Passphrase incorrect?)
but works fine in emergency mode after Ctrl-D
systemd[1]: Finished Cryptography Setup for luks-******
My passphrase contain special character requiring AltGr on an azerty keyboard.
This matches a known recurring plymouth bug, previously reported on Ubuntu’s forum.
It might be relevant since plymouth 26’s changelog specifically lists keymap/XKB-related changes
Initial comment - not needed after verification - kept for historical purpose
As the /home is part of the base root file system - the system will attempt to mount the /home folder on boot - but it cannot as the entire partition is encrypted.
This is often an issue when using a grub EFI stub to boot.
The reason is the grub EFI stub, it only supports the standard ASCII character set.
It is possible to create a custom grub EFI which supports other key-maps but it is next to impossible to support with an installer.
When emergency mode is entered it usually loads the configuration from /etc/vconsole.conf which then sets the correct keymap.
When using the custom partitioning and installing using a normal root file-system but use and encrypted /home partition you can configure the system to use an unified kernel EFI loader to have support for your azerty keymap in loader.
With a single boot system it is fairly easy to setup.
edit the preset for your kernel /etc/mkinitcpio.d/linuxXY.preset
uncomment the lines to for generating the unified kernel
change the path for the default_uki to “/boot/efi/EFI/Manjaro/…”
add hooks sd-vconsole and sd-encrypt to /etc/mkinitcpio.conf
run mkinitcpio to generate uki
install refind bootloader
run refind-install
EDIT: 2026-06-28T05:50:00Z
I decided to test the scenario - so I have created a virtual machine.
I decided to use the Cinnamon ISO from the download page - because it is a year old and I would be in better position to investigate how it works before and after updated.
For the initial installation I created a custom partitioning on a 25GiB disk
2048MiB EFI
16384MiB / (root)
the rest for /home - which I encrypted with a phrase
unique to the danish keymap TestÆØÅæøå
I have not been able to reproduce the issue causing the problem with unlocking the luks encrypted home partition /home.
When your root is unencrypted the configuration found in /etc/vconsole.conf is applied before the passphrase prompt and thus it your keymap will be applied.
So I suggest you verify your configuration, and ensure it is valid.
# /etc/crypttab: mappings for encrypted partitions.
#
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/<name> paths for encrypted devices.
#
# See crypttab(5) for the supported syntax.
#
# NOTE: You need not list your root (/) partition here, but it must be set up
# beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
# to encrypted swap, which should be set up with mkinitcpio-openswap
# for resume support.
#
# <name> <device> <password> <options>
luks-045cdc63-6069-4551-8980-1ad79e84bf5c UUID=045cdc63-6069-4551-8980-1ad79e84bf5c none
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=B6FB-B170 /boot/efi vfat defaults,umask=0077 0 2
UUID=f4ac491e-da68-4189-82eb-93b5330f40eb / ext4 defaults 0 1
/dev/mapper/luks-045cdc63-6069-4551-8980-1ad79e84bf5c /home btrfs defaults,compress=zstd:1 0 0
My configuration must be valid.
Sorry for forgetting to mention that it is not a fresh install.
This setup was running fine since at least a year just before the update.
~ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat FAT32 efi system A1B8-8CAD 510,7M 0% /boot/efi
├─nvme0n1p2 ext4 1.0 linux boot ce4b9c4a-edf4-4d7b-b5f8-b4778b845716 733,9M 18% /boot
├─nvme0n1p3 ext4 1.0 linux root 7d319f47-5098-4323-a107-17f2685c2fb4 43,1G 50% /
├─nvme0n1p4 crypto_LUKS 1 8217cc68-55db-4de4-bdf7-c8f13840c590
│ └─luks-8217cc68-55db-4de4-bdf7-c8f13840c590 btrfs linux home 12cf0b4e-5911-41fa-99be-bb0acaab7ac7 69,8G 27% /home
├─nvme0n1p5 swap 1 linux swap b1e24377-6f7d-4842-ab9e-d0b9fb859d85 [SWAP]
Initially I was in doubt on how the scenario is installed - that is why my initial comment is now irrelevant - because now I know.
I only kept the original comment - because it would look out of place - if I simply removed it.
Your configuration looks good. There is nothing catching attention.
The only thing I can think of is to run mkinitcpio to ensure your system boots from the correct place - sometimes the /EFI/Manjaro/grubx64.efi and the /EFI/boot/bootx64.efi gets mixed up in the firmware.
If they are not binary identical it may create a weird issue at boot.
To ensure they are identical you can run the Manjaro specific script install-grub followed by mkinitpcio -P
These two commands will first ensure the grub binaries are identical and rebuild the grub.cfg - the second will rebuild the initramfs.
When using the encrypt or sd-encrypt hook, the keyboard modules and/or filesystems needed to unlock the LUKS device during system boot need to be added to the MODULES array when the target system differs from the one used to run mkinitcpio. For example, if you use a keyfile on an ext2 file system but no ext2 file system is mounted at the time mkinitcpio runs, add ext2. See dm-crypt/System configuration#cryptkey for more details.
If using a keyboard through a USB 3 hub and wish to use it to unlock a LUKS device, add usbhid xhci_hcd. Some laptops need i2c_hid_acpi module for the built-in keyboard.
uses the old-fashioned busybox + udev approach during early boot and unlocks encrypted devices using hook encrypt (the OP apparently uses this approach, but without the encrypt hook, as their encrypted home is instead unlocked by systemd during normal boot, i.e. after the initramfs has handed over control).
Regarding @Meeloo 's issue, if everything works correctly when plymouth is disabled (by removing it from HOOKS + running mkinitcpio -P), then plymouth is at fault as discussed here.
Yes. When dealing with encrypted root filesyetms, as much as I groan about systemd, I would trust it over busybox scripts in your ramfs.
I was a massive busybox fan 25 years ago. Oh the things I was able to build with it! I would have never even dreamed that it would make it into the official kernel source.
And I believe the official Manjaro way is to use systemd, you are just more on your own with udev, which should be perfectly fine too.
Turns out it wasn’t the problem, but it wouldn’t surprise me that down the road udev, especially with LUKS, will be. Especially if Arch and every Arch based distro moves this way.
The first thing I do on any Linux distro that uses plymouth, is disable it. (So I took it out of my suggested HOOKS.)
I’ve had my share of problems in the past with it, and on old hardware, it increases boot times substantially for me.
But yes, I see others have got down to the root of the problem.
Interesting - why? BusyBox has been the solid foundation of Linux preboot environments for more than 15 years. And there is no reason to assume that this has changed in any way.
BusyBox is a separate project, always has been. It is not part of the Linux kernel sources. You must be thinking of something else.
busybox is loaded very early in the boot process, and is included in the initramfs. Before control is handed off to the real init system. (Not part of the kernel, it was late over on this side of the globe.)
Much of this is only personal opinion, so it doesn’t mean much. I have nothing against Busybox, it’s genius, and great for certain things. (Like smart TVs! j/k it can do so much more.)
But the old way is very sequential, then purges itself from memory during the root switch.
They claim much of this is streamlined by introducing parallel processing, which is a huge plus for multi-drive LUKS unlocking, even if it makes the initial RAM disk a bit heavier.
And there’s just the fact that the Fedora camp phased out the old way years ago (obviously), Arch is in transition, and it seems like more are hopping on board all the time.
I just want stability over everything else, so I made the switch.
Funny you would mention that - performance is the one reason why I’m currently staying with the old approach, using a forked version of the encrypt hook with added support for parallelization. Systemd-based unlocking of multiple drives works fine, but takes an eternity in comparison.
I would have never even dreamed that it would make it into the official kernel source.
j/k it can do so much more.)