A LUKS root volume with a detached header on a device without partitioning will not have a UUID and will not have an attribute ENV{ID_FS_TYPE}=="crypto_LUKS".
Therefore, several areas need to be addressed: identification of the LUKS device, inclusion of entries within crypttab, and provision of the detached header file.
- Added support for an option (4th column: "force") in /etc/crypttab to force the inclusion of the entry in the initramfs version (avoiding the fs type test).
- Added support for an option (4th column: "header=/path/to/file") in /etc/crypttab to provide a path to a detached header file embedded within the initramfs.
- Added ID and PARTUUID support to the device (2nd column) in /etc/crypttab (complementing the existing UUID functionality).
- Added cmdline support to indicate LUKS device ("rd.luks.serial=") that refers to the attribute ENV{ID_SERIAL_SHORT}.
Tested successfully on Void Linux (x86_64 musl) (no systemd) with a LUKS root volume accessed with a keyfile and using a detached header.
Not tested on systemd, or on a LUKS root volume with a passphrase rather than a keyfile.
If a non-default device mapper name is used for an encrypted partion is
used, (i.e. not luks-$UUID) due to parsing of /etc/crypttab, then the
short-circuits put in place to prevent asking the password twice do not
work.
This would not normally be an issue as the settled job itself should be
removed after it has run and thus cannot be run again. Sadly, due to
the corresponding udev rule using ACTION="add|changed", and the fact
that trying to unlock the device (whether successful or not) seems to
trigger a changed event, it means the settled job is recreated with
each itteration thus causing the whole loop to run again.
It is this situation that the short-circuit exits would normally come
into play but sadly do not work when non-standard names are used.
By the time the /tmp/cryptroot-asked-$2 file is written near the end of
the script, the value of $2 has already been lost due to the argument
parsing code's use of 'shift'. So while on systems where the default
name is used are protected by checking /dev/mapper/xxxx, the
/tmp/cryptroot-asked-$2 file didn't help on systems where this was not
used due to this bug.
So this commit shuffles things around somewhat such that:
1. The /dev/mapper/xxxx device is checked *after* resolving $2 (which
contains the default name) to whatever /etc/crypttab specifies.
2. The cryptroot-asked-xxxx file also uses the translated name both
for the initial check and to flag when it's written.
As a separate fix, it might make sense to change the udev rule to only
act on add events rather than add|change events, but I'm not sure of the
ramifications of such a change and there may be cases where the add
event is missed and thus the change event needs to be included.
1) strstr " $discarduuids " did not remove the optional
'luks-' prefix from the argument as the documentation says.
2) The lookup seems backwards. $luksdev ($luks in the other code copy)
is the full uuid and thus one should check whether the user-supplied
argument (short form) is contained therein, not the other way around.
Before this commit, the only way to trigger allow-discards was to
specify the full uuid without the 'luks-' prefix.
This asks for the luks passphrase if key is not found for defined time (if defined with rd.luks.tout cmd line):
modules.d/90crypt/cryptroot-ask.sh | 21 ++++++++++++++++++---
modules.d/90crypt/parse-crypt.sh | 5 +++--
2 files changed, 21 insertions(+), 5 deletions(-)
Otherwise there is no way to skip pasword prompt. --has-active-vt
seems to correctly catch also the case when plymouthd is started
but splash is disabled.
Signed-off-by: Andrey Borzenkov <arvidjaar@gmail.com>
New kernel argument syntax for LUKS-keydev is introduced:
rd.luks.key=<key_path>[:<key_dev>[:<luks_dev>]]
Unfolding <key_dev> in BNF:
<key_dev> ::= "UUID=" <uuid> | "LABEL=" <label> | <kname>
Where <kname> matches following regular expression:
^/dev/.*
<kname> need to be a character device and not a symlink for now.
For every rd.luks.key argument udev rule is created. That rule runs
test to check whether matching device contains <key_path>. If it does
it's applied to matching <luks_dev>.
First, it's duplicate code.
Second, it did not allow those who had plymouth installed to use other
methods, like the new usb key file. When building the initram,
it would install the plymouth cryptroot-ask script, and not
the crypt module one.
Added these new items to crypt module's cryptroot-ask.sh:
- 'unset' for used variables
- udevsettle
The non-plymouth cryptsetup prompt was using $1 instead of $device.
Changed prompt number from 1 to 5, as this is much nicer.
I believe plymouth already does infinite prompts.
Also added unset for usb key. Just saw it didn't unset its vars.
LVM
rd_NO_LVM
disable LVM detection
rd_LVM_VG=<volume group name>
only activate the volume groups with the given name
crypto LUKS
rd_NO_LUKS
disable crypto LUKS detection
rd_LUKS_UUID=<luks uuid>
only activate the LUKS partitions with the given UUID
MD
rd_NO_MD
disable MD RAID detection
rd_MD_UUID=<md uuid>
only activate the raid sets with the given UUID
DMRAID
rd_NO_DM
disable DM RAID detection
rd_DM_UUID=<dmraid uuid>
only activate the raid sets with the given UUID
If we purport to test booting to an md raid, we may as well test it.
We do not need the plymouth module and the normal crypt module to include
duplicate functionality.
Nicolas Porcel