I installed a Manjaro system using ‘Encrypt system’ from graphical installer.
Partitions ‘/’ and ‘/home’ were encrypted.
I only updated the ‘/etc/crypttab’ file to replace ‘/crypto_keyfile.bin’ by ‘none’ for the root partition, so I’m now prompted for password at boot time.
Everything is running as expected.
However, after some days, I realized the ‘/crypto_keyfile.bin’ file didn’t exist (anymore?).
No issue with this, I might have deleted it by mistake.
What I do not understand is why in such case my ‘/home’ partition is still opened properly after booting.
Could you please give me some light about this ?
And by the way, what’s the way to rebuild this ‘/crypto_keyfile.bin’ file ?
Below the crypttab file:
# /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>
# Initial setup created by bootctl...
# It is providing a password so that no password request is performed at boot
# This is not the expected behaviour
# luks-66904d4b-b623-48c2-be8e-ac6f04db8d2f UUID=66904d4b-b623-48c2-be8e-ac6f04db8d2f /crypto_keyfile.bin luks
luks-66904d4b-b623-48c2-be8e-ac6f04db8d2f UUID=66904d4b-b623-48c2-be8e-ac6f04db8d2f none luks
luks-32f6c0f0-b899-4773-94f1-a39838d70c57 UUID=32f6c0f0-b899-4773-94f1-a39838d70c57 /crypto_keyfile.bin luks
journalctl error:
nov. 22 21:31:10 herezilo systemd-cryptsetup[886]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/32f6c0f0-b899-4773-94f1-a39838d70c57.
nov. 22 21:31:10 herezilo systemd-cryptsetup[886]: Failed to activate, key file '/crypto_keyfile.bin' missing.
lsblk:
[herezilo ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 953,9G 0 disk
├─nvme0n1p1 259:1 0 4G 0 part /boot/efi
├─nvme0n1p3 259:2 0 80G 0 part
│ └─luks-66904d4b-b623-48c2-be8e-ac6f04db8d2f 254:0 0 80G 0 crypt /
├─nvme0n1p4 259:3 0 39,5G 0 part
├─nvme0n1p5 259:4 0 299,4G 0 part
│ └─luks-32f6c0f0-b899-4773-94f1-a39838d70c57 254:1 0 299,4G 0 crypt /home
That file is normally used to auto-unlock partitions without prompting. If it’s gone, the root partition requires manual entry. But because /home shares the same passphrase, it still unlocks seamlessly once / is open.
Unlocking the root partition loads the key into memory, and because /home uses the same passphrase, it can be unlocked automatically without needing /crypto_keyfile.bin.
As I recall crypto_keyfile.bin is added to mkinitcpio.conf in the FILES=() array when the system is encrypted and configured to use hibernation.
When you run mkinitcpio -P the file is included in the init image.
If you have manually partitioned the disk - your mention of a separate /home point in that direction - there will be no swap configuration for hibernation and thus the file will not exist.
The file is created and used by mkinitcpio-openswap utility and a recent warning in openswap.conf discourage the use of a key file as it may lead to file system corruption as can be seen from a default config.
$ cat /etc/openswap.conf
## cryptsetup open $swap_device $crypt_swap_name
## get uuid using e.g. lsblk -f
swap_device=/dev/disk/by-uuid/2788eb78-074d-4424-9f1d-ebffc9c37262
crypt_swap_name=cryptswap
## unlock_method can be either password, keyfile or keyfile_raw
## keyfile will use the keyfile_device and keyfile_filename to unlock the swap
## keyfile_raw will use the keyfile_device and keyfile_block_number to unlock the swap
## password will prompt for the password to unlock the swap
## if unlock_method is not set, then method is keyfile if keyfile_device and keyfile_filename are set
## otherwise it is password
unlock_method="password"
####### WARNING: There is a risk of data loss when using unlock_method="keyfile"
## You should double-check keyfile_device_mount_options,
## and note that this method is potentially dangerous regardless.
## https://docs.kernel.org/power/swsusp.html
## https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption#busybox-based_initramfs
## keyfile_device is the device that contains the keyfile
## set it to the device that contains the keyfile
## e.g. /dev/mapper/root-device
####### THIS OPTION IS MANDATORY IF unlock_method IS keyfile OR keyfile_raw
keyfile_device=
## keyfile_filename is the path to the keyfile on the keyfile_device
## e.g. /etc/swap.key
####### THIS OPTION IS MANDATORY IF unlock_method IS keyfile
keyfile_filename=
## keyfile_block_number is the block number of the keyfile on the keyfile_device
## e.g. 12345
## on the ext4 filesystem, you can get the block number using
## debugfs $keyfile_device
## extents $keyfile_filename
## the relevant block number will appear under the Physical column in the output
####### THIS OPTION IS MANDATORY IF unlock_method IS keyfile_raw
keyfile_block_number=
## key_size is the size of the key in bytes
## e.g., 4096
## This is the size of the keyfile and should match the actual size of the keyfile.
## You can get the size of the keyfile using: wc -c <keyfile_filename>
## The openswap script will fail if the keyfile is fragmented,
## so keyfile_length should not exceed the filesystem block size.
## For ext4 filesystems, keyfile_length should not exceed 4096 bytes,
## and it SHOULD be greater than ~200 bytes to avoid inode inlining.
####### THIS OPTION IS MANDATORY IF unlock_method IS keyfile_raw
keyfile_length=4096
## additional arguments are given to mount for keyfile_device
## has to start with --options
## it is important to use the correct options for your filesystem
## to prevent any writes to the keyfile device and thus
## minimize the risk of data loss
#keyfile_device_mount_options="--options=subvol=__active/__"
keyfile_device_mount_options="--options=ro,noload"
## additional arguments are given to cryptsetup
## --allow-discards options is desired in case swap is on SSD partition
cryptsetup_options="--type luks"
I have not checked if the Calamares Installer Framework has been adapted to follow the warning about possible problems, but I like to think it has.
You are right, the same password is used for both partitions. Now I understand this ‘magic’.
And since I was about to encrypt my swap partition, you anticipated my next questions.
Please note the warning if you want to use suspend-to-disk
The following three methods are alternatives for setting up an encrypted swap for suspend-to-disk (hibernation). If you apply any of them, be aware that critical data swapped out by the system may potentially stay in the swap over a long period (i.e. until it is overwritten). To reduce this risk consider setting up a system job which re-encrypts swap, e.g. each time the system is going into a regular shut-down, along with the method of your choice.
Thanks to your message I could successfully encrypt my root, home and swap partitions.
I’m just struggleling now with ‘hibernate’ (what I’m implementing just for my own knowledge since I never use it) which is acting for now as a simple shutdown.
I’m booting a unified kernel image with secureboot and no boot loader (using UEFI directly) on ext4 filesystem.
My laptop is a ACER Nitro AN515-45.
I remember when I banged my head on the kernel cmdline - I initially took the cmdline as read from
cat /proc/cmdline
But that was a mistake. The initd= assignments should be removed - and since I don’t use hibernation - the suspend to ram work for me - and if I don’t need the laptop for a extended period of time - I shut it down - so I never bothered to figure out how to configure suspend-to-disk with LUKS.
But I noted from the Arch Wiki - should I ever want to add suspend-to-disk - using systemd with a swapfile instead of a partition should work without much trouble.
I removed the initd= assignments from /etc/kernel/cmdline since, you are right, they are already part of the Unified Kernel Image through the /etc/kernel/uki.conf.
I continue to struggle with hibernation, but this thread is fully solved.
I update the subject accordingly.