dm-crypt (Русский)/System configuration (Русский)

From ArchWiki

Эта статья или раздел нуждается в переводе

Примечания: Перевод не завершён (обсуждение: Talk:Dm-crypt (Русский)/System configuration (Русский)#)

Разблокировка в начальном пользовательском пространстве

Booting an encrypted root volume requires that the initramfs contains the necessary tools for early userspace to unlock the volume. The instructions on what to unlock are topically passed via kernel parameters.

The following sections describe how to configure mkinitcpio and list which kernel parameters are required.


Depending on the particular scenarios, a subset of the following mkinitcpio hooks will have to be enabled:

busybox systemd Use case
encrypt sd-encrypt Needed when the root partition is encrypted or when an encrypted partition needs to be mounted before the root partition. Not needed in other cases as system initialization scripts like /etc/crypttab already take care of unlocking other non-root partitions. This hook must be placed after the udev or systemd hook.
keyboard Needed to make keyboards work in early userspace.
Tip: For systems that are booted with different hardware configurations (e.g. laptops with external keyboard vs. internal keyboard or headless systems), it is helpful to place this hook before autodetect in order to always include all keyboard drivers. Otherwise the external keyboard only works in early userspace if it was connected when creating the image.
keymap sd-vconsole Provides support for non-US keymaps for typing encryption passwords; it must come before the encrypt hook, otherwise you will need to enter your encryption password using the default US keymap. Set your keymap in /etc/vconsole.conf, see Keyboard configuration in console#Persistent configuration.
consolefont Loads an alternative console font in early userspace. Set your font in /etc/vconsole.conf, see Linux console#Persistent configuration.

Other hooks needed should be clear from other manual steps followed during the installation of the system.

Note: Remember to regenerate the initramfs after making any changes to /etc/mkinitcpio.conf.


A typical /etc/mkinitcpio.conf configuration using encrypt hook:

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

A configuration with systemd-based initramfs using sd-encrypt hook:

HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole block sd-encrypt lvm2 filesystems fsck)

Параметры ядра

The kernel parameters you need to specify depend on whether the encrypt hook or the sd-encrypt hook is being used. root and resume are specified the same way for both.

For example, if using GRUB, the relevant parameters are added to /etc/default/grub before generating the main configuration file. See also GRUB#Warning when installing in chroot as another point to be aware of when installing the GRUB loader.


The root= parameter specifies the device of the actual (decrypted) root file system:

  • If the file system is formatted directly on the decrypted device file this will be /dev/mapper/dmname.
  • If a LVM gets activated first and contains an encrypted logical rootvolume, the above form applies as well.
  • If the root file system is contained in a logical volume of a fully encrypted LVM, the device mapper for it will be in the general form of root=/dev/volumegroup/logicalvolume.
Tip: When using GRUB and generating grub.cfg with grub-mkconfig, this parameter does not need to be specified manually. grub-mkconfig will determine the correct UUID of the decrypted root filesystem and add it to grub.cfg automatically.


  • device is the device file of the decrypted (swap) filesystem used for suspend to disk. If swap is on a separate partition, it will be in the form of /dev/mapper/swap. See also dm-crypt/Swap encryption.

Использование хука encrypt

Note: Compared to the sd-encrypt hook, the encrypt hook does not support:

This specifies the device containing the encrypted root on a cold boot. It is parsed by the encrypt hook to identify which device contains the encrypted system:

  • device is the path to the device backing the encrypted device. Usage of persistent block device naming is strongly recommended.
  • dmname is the device-mapper name given to the device after decryption, which will be available as /dev/mapper/dmname.
  • options (optional) are comma separated options, e.g. for TRIM support. If no options are required, omit this parameter (use cryptdevice=device:dmname).
  • If a LVM contains the encrypted root, the LVM gets activated first and the volume group containing the logical volume of the encrypted root serves as device. It is then followed by the respective volume group to be mapped to root. The parameter follows the form of cryptdevice=/dev/vgname/lvname:dmname.
Tip: One may want to enable Discard/TRIM support for solid state drives (SSD).

This parameter specifies the location of a keyfile and is required by the encrypt hook for reading such a keyfile to unlock the cryptdevice (unless a key is in the default location, see below). It can have three parameter sets, depending on whether the keyfile exists as a file in a particular device, a bitstream starting on a specific location, or a file in the initramfs.

For a file in a device the format is:

  • device is the raw block device where the key exists. Usage of persistent block device naming is strongly recommended.
  • fstype is the filesystem type of device (or auto).
  • path is the absolute path of the keyfile within the device.

Example: cryptkey=LABEL=usbstick:vfat:/secretkey

For a bitstream on a device the key's location is specified with the following:


where the offset and size are in bytes. For example, cryptkey=UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ:0:512 reads a 512 byte keyfile starting at the beginning of the device.

Tip: If the device path you want to access contains the character :, you have to escape it with a backslash \. In that case the cryptkey parameter would be as follows: cryptkey=/dev/disk/by-id/usb-123456-0\:0:0:512 for a USB key with the ID usb-123456-0:0.

For a file included in the initramfs the format is[1]:


Example: cryptkey=rootfs:/secretkey

Also note that if cryptkey is not specified, it defaults to /crypto_keyfile.bin (in the initramfs).[2]

See also dm-crypt/Device encryption#Keyfiles.


This parameter is specific to pass dm-crypt plain mode options to the encrypt hook.

It takes the form


The arguments relate directly to the cryptsetup options. See dm-crypt/Device encryption#Encryption options for plain mode.

For a disk encrypted with just plain default options, the crypto arguments must be specified, but each entry can be left blank:


A specific example of arguments is


Использование systemd-cryptsetup-generator

systemd-cryptsetup-generator is a systemd unit generator that reads a subset of kernel parameters, and /etc/crypttab, for the purpose of unlocking encrypted devices. See the systemd-cryptsetup-generator(8) man page for more details about it and all options it supports.

systemd-cryptsetup-generator is run during the initramfs stage when using the sd-encrypt mkinitcpio hook or the systemd dracut module.

In what follows, we describe some of the kernel parameters that systemd-cryptsetup-generator interprets.

  • If the file /etc/crypttab.initramfs exists, it will be added to the initramfs as /etc/crypttab, there you can specify devices that need to be unlocked at the initramfs phase. See #crypttab for the syntax. If /etc/crypttab.initramfs does not exist, there will be no /etc/crypttab in the initramfs and the unlockable devices will need to be specified via kernel parameters listed below.
  • /etc/crypttab.initramfs is not limited to using only UUID like rd.luks. You can use any of the persistent block device naming methods.
  • Passwords entered during boot are cached in the kernel keyring by systemd-cryptsetup(8), so if multiple devices can be unlocked with the same password (this includes devices in crypttab that are unlocked after boot), then you will only need to input each password once.
  • All of the rd.luks parameters can be specified multiple times to unlock multiple LUKS encrypted volumes.
  • The rd.luks parameters only support unlocking LUKS devices. To unlock a plain dm-crypt device, you must specify it in /etc/crypttab.initramfs. See #crypttab for the syntax.
Warning: If you are using /etc/crypttab or /etc/crypttab.initramfs together with luks.* or rd.luks.* parameters, only those devices specified on the kernel command line will be activated and you will see Not creating device 'devicename' because it was not specified on the kernel command line.. This is because the luks.* or rd.luks.* parameters control which devices from the crypttab get activated. To activate all devices in /etc/crypttab do not specify any luks.* parameters and use rd.luks.*. To activate all devices in /etc/crypttab.initramfs do not specify any luks.* or rd.luks.* parameters.
Tip: rd.luks.uuid can be omitted when using

Specify the UUID of the device to be decrypted on boot with this flag.

By default, the mapped device will be located at /dev/mapper/luks-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX where XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX is the UUID of the LUKS partition.
Tip: When using this parameter you can omit rd.luks.uuid.

Specify the name of the mapped device after the LUKS partition is open, where XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX is the UUID of the LUKS partition. This is equivalent to the second parameter of encrypt's cryptdevice.

For example, specifying causes the unlocked LUKS device with UUID 12345678-9ABC-DEF0-1234-56789ABCDEF0 to be located at /dev/mapper/root.


Specify the location of a password file used to decrypt the device specified by its UUID. There is no default location like there is with the encrypt hook parameter cryptkey.

If the keyfile is included in the initramfs:



Tip: The whole rd.luks.key parameter can be omitted if the keyfile is included as /etc/cryptsetup-keys.d/name.key.

If the keyfile is on another device:


Replace UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ with the identifier of the device on which the keyfile is located.

  • If the type of file system is different than your root file system, you must include the kernel module for it in the initramfs.
  • rd.luks.key with a keyfile on another device by default does not fallback to asking for a password if the device is not available. To fallback to a password prompt, specify the keyfile-timeout= option in rd.luks.options. E.g. for a 10 second timeout:



Set options for the device specified by it UUID or, if not specified, for all UUIDs not specified elsewhere (e.g., crypttab).

This parameter is the analogue of crypttab's options field. The format is the same—options are separated by commas, options with values are specified using option=value. This is roughly equivalent to the third parameter of encrypt's cryptdevice.

For example:


There are two options that affect the timeout for entering the password during boot:

  • rd.luks.options=timeout=mytimeout specifies the timeout for querying for a password
  • rootflags=x-systemd.device-timeout=mytimeout specifies how long systemd should wait for the rootfs device to show up before giving up (defaults to 90 seconds)

If you want to disable the timeout altogether, then set both timeouts to zero:

rd.luks.options=timeout=0 rootflags=x-systemd.device-timeout=0
Password echo

When the user is typing the password, systemd-cryptsetup by default outputs asterisks (*) for each typed character. This is unlike the encrypt hook, which does not output anything. To silence the output, set the password-echo=no option:

Модуль доверенной платформы и ключи FIDO2

If a TPM2 chip is available in your system, or you use FIDO2-compatible security key, you can use it to automatically unlock your volume instead of using a password or a keyfile.


  • for TPM2 chip: rd.luks.options=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=tpm2-device=auto
  • for FIDO2 key: rd.luks.options=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=fido2-device=auto

in addition to rd.luks.uuid or

Alternatively, /etc/crypttab.initramfs can be used which avoids the need to specify any kernel options.

Note: Remember to regenerate the initramfs after making any changes to /etc/crypttab.initramfs.

Here the encrypted volume is mounted under the name root (appearing in /dev/mapper/root), mounted via the UUID of the storage device, with no password, and retrieving the key from the TPM2 device.

Note that none must be provided in the password field order for the TPM2 device to be used, otherwise the value given will be used as a password or key, and if it does not work it will ask you to type in the passkey during boot without attempting to load the key from the TPM2 device.

If specifying the device via UUID as shown above, ensure it is that of the underlying (encrypted) storage device, not the UUID of the decrypted volume that is specified elsewhere as the root filesystem.

When using a detached LUKS header, specify the block device with the encrypted data. Must be used together with rd.luks.options to specify the header file location.

See dm-crypt/Specialties#Encrypted system using a detached LUKS header for details and instructions.

Разблокировка в позднем пользовательском пространстве


The /etc/crypttab (encrypted device table) file is similar to the fstab file and contains a list of encrypted devices to be unlocked during system boot up. This file can be used for automatically mounting encrypted swap devices or secondary file systems.

crypttab is read before fstab, so that dm-crypt containers can be unlocked before the file system inside is mounted. Note that crypttab is read after the system has booted up, therefore it is not a replacement for unlocking encrypted partitions by using mkinitcpio hooks and configuring them by using kernel parameters as in the case of encrypting the root partition. crypttab processing at boot time is made by the systemd-cryptsetup-generator automatically.

See crypttab(5) for details, read below for some examples, and the #Монтирование во время загрузки section for instructions on how to use UUIDs to mount an encrypted device.

  • If the nofail option is specified, the password entry screen may disappear while typing the password. nofail should therefore only be used together with keyfiles.
  • For dm-crypt plain mode devices, the plain option must be explicitly set to force systemd-cryptsetup to recognize them. See systemd issue 442.
# Example crypttab file. Fields are: name, underlying device, passphrase, cryptsetup options.

# Mount /dev/lvm/swap re-encrypting it with a fresh key each reboot
 swap	/dev/lvm/swap	/dev/urandom	swap,cipher=aes-xts-plain64,size=256

# Mount /dev/lvm/tmp as /dev/mapper/tmp using plain dm-crypt with a random passphrase, making its contents unrecoverable after it is dismounted.
tmp	/dev/lvm/tmp	/dev/urandom	tmp,cipher=aes-xts-plain64,size=256 

# Mount /dev/lvm/home as /dev/mapper/home using LUKS, and prompt for the passphrase at boot time.
home   /dev/lvm/home

# Mount /dev/sdb1 as /dev/mapper/backup using LUKS, with a passphrase stored in a file.
backup /dev/sdb1       /home/alice/backup.key

# Unlock /dev/sdX using the only available TPM, naming it myvolume
myvolume	/dev/sdX	none	tpm2-device=auto

To test your crypttab immediately after editing it, reload the systemd manager configuration with a daemon-reload and start the newly generated systemd-cryptsetup@name.service.

# cryptsetup status name
/dev/mapper/name is active.
  type:    ...
  cipher:  ...
  keysize: ... bits
  key location: ...
  device:  /dev/sdxN
  sector size:  ...
  offset:  ... sectors
  size:    ... sectors
  mode:    ...
  flags:   ...

For more on systemd-cryptsetup@name.service, see #Монтирование по запросу.

Tip: If you use GPT and specific partition type UUIDs, you can avoid using crypttab and fstab for some mount points with systemd. For more information, see systemd#GPT partition automounting.

Монтирование во время загрузки

This article or section is a candidate for merging with #crypttab.

Notes: Нет необходимости в двух разделах для объяснения использования одного файла. (Discuss in Talk:Dm-crypt (Русский)/System configuration (Русский))

Если вы хотите монтировать зашифрованный диск во время загрузки, введите UUID устройства в /etc/crypttab. UUID (раздела) можно получить с помощью команды lsblk -f и добавьте его в crypttab в виде:

externaldrive         UUID=2f9a8428-ac69-478a-88a2-4aa458565431        none    timeout=180

Первый параметр - это предпочитаемое вами отображаемое имя устройства для зашифрованного диска. Параметр none вызывает при загрузке запрос на ввод парольной фразы для разблокировки раздела. Параметр timeout задает тайм-аут в секундах для ввода пароля расшифровки во время загрузки.

Tip: Пароли, введенные в подсказке пароля, кэшируются в связке ключей ядра командой systemd-cryptsetup(8) (при использовании хука sd-encrypt это также включает пароли, введенные на этапе initramfs). Если устройство в crypttab использует ранее введенный пароль, третий параметр может быть установлен в none и автоматически будет использован кэшированный пароль.
Примечание: Помните, что параметр timeout в crypttab определяет только количество времени, разрешенное для ввода пароля зашифрованного устройства. Кроме того, sd также имеет таймаут по умолчанию, определяющий количество времени, отведенное на доступность устройства (по умолчанию 90 секунд), что не зависит от таймера пароля. В результате, даже если опция timeout в crypttab установлена на значение больше 90 секунд (или она имеет значение по умолчанию 0, что означает неограниченное время), systemd будет ждать разблокировки устройства не более 90 секунд. Чтобы изменить время, в течение которого systemd будет ждать, пока устройство станет доступным, используйте опцию x-systemd.device-timeout (см. systemd.mount(5)) может быть установлена в fstab для данного устройства. Вероятно, желательно, чтобы количество времени опции timeout в crypttab было равно количеству времени опции x-systemd.device-timeout в fstab для каждого устройства, смонтированного во время загрузки


Разблокировка с помощью файла ключей

Если файл ключей для вторичной файловой системы сам хранится внутри зашифрованного корня, он находится в безопасности, пока система выключена, и может быть использован для автоматического разблокирования монтирования при загрузке через crypttab. Например, разблокировать зашифрованный диск с указанным UUID:

home-crypt    UUID=UUID-identifier    /etc/cryptsetup-keys.d/home-crypt.key
  • Если файл ключей не указан, systemd-cryptsetup(8) автоматически попытается загрузить его из /etc/cryptsetup-keys.d/name.key и /run/cryptsetup-keys.d/name.key.[3].
  • Если вы предпочитаете использовать блокчейн в режиме --plain, параметры шифрования, необходимые для его разблокировки, указываются в /etc/crypttab. Позаботьтесь о применении обходного пути systemd, упомянутого в crypttab в этом случае.

Затем используйте имя связующего устройства (определенное в /etc/crypttab) для записи в /etc/fstab:

/dev/mapper/home-crypt        /home   ext4        defaults        0       2

Поскольку /dev/mapper/externaldrive уже является результатом уникального сопоставления разделов, нет необходимости указывать для него UUID. В любом случае, связка с файловой системой будет иметь другой UUID, чем раздел, в котором она зашифрована.

Монтирование блочного устройства в стеке

Генераторы systemd также автоматически обрабатывают стекированные блочные устройства при загрузке.

Например, можно создать установку RAID, использовать на ней cryptsetup и создать логический том LVM с соответствующей файловой системой внутри зашифрованного блочного устройства. В результате:

$ lsblk -f
─sdXX                  linux_raid_member    
│ └─md0                 crypto_LUKS   
│   └─cryptedbackup     LVM2_member 
│     └─vgraid-lvraid   ext4              /mnt/backup
└─sdYY                  linux_raid_member    
  └─md0                 crypto_LUKS       
    └─cryptedbackup     LVM2_member 
      └─vgraid-lvraid   ext4              /mnt/backup

будет запрашивать парольную фразу и автоматически монтироваться при загрузке.

Given you specify the correct corresponding crypttab (e.g. UUID for the crypto_LUKS device) and fstab (/dev/vgraid/lvraid) entries, there is no need to add additional mkinitcpio hooks/configuration, because /etc/crypttab processing applies to non-root mounts only. One exception is when the mdadm_udev hook is used already (e.g. for the root device). In this case /etc/madadm.conf and the initramfs need updating to achieve the correct root raid is picked first.

Монтирование по запросу

Вместо того чтобы использовать

# cryptsetup open UUID=... externaldrive

you can start systemd-cryptsetup@externaldrive.service when you have an entry as follows in your /etc/crypttab:

externaldrive UUID=... none noauto

That way you do not need to remember the exact crypttab options. It will prompt you for the passphrase if needed.

The corresponding unit file is generated automatically by systemd-cryptsetup-generator(8). You can list all generated unit files using:

$ systemctl list-unit-files | grep systemd-cryptsetup

Решение проблем

Система зависла при загрузке/запрос пароля не отображается

Если вы используете Plymouth, убедитесь, что используете правильные модули (см. Plymouth (Русский)#mkinitcpio) или отключите его. В противном случае Plymouth проглотит запрос пароля, что сделает загрузку системы невозможной.

Клавиатура или файл ключей в файловой системе недоступны для разблокировки

Если вы разблокируете устройство LUKS с помощью клавиатуры или файла ключей в файловой системе, которая не присутствует при генерации initramfs, вам может понадобиться добавить соответствующие модули в массив MODULES mkinitcpio. Это также может понадобиться, если клавиатура подключена через USB-концентратор. Смотрите mkinitcpio (Русский)#MODULES для получения дополнительной информации по этому вопросу и Minimal initramfs#Sorting out modules в качестве отправной точки для потенциальных имен модулей клавиатуры и файловой системы, которые необходимо добавить.

В общем случае, для клавиатур, не подключенных к компьютеру во время генерации initramfs, необходимо поместить хук keyboard перед хуком autodetect, иначе будут сохранены только части, необходимые для подключенного в данный момент оборудования, см. mkinitcpio (Русский)#Доступные хуки.