Control: reassign -1 systemd 247.3-1 Control: retitle -1 systemd-cryptsetup@.service should ignore targets that are already mapped
Hi, On Sun, 28 Feb 2021 at 19:11:56 +0100, schaa...@gmx.de wrote: > Package: cryptsetup-initramfs > Version: 2:2.3.4-2~bpo10+2 > > systemd 247.2-5~bpo10+1 > > I recently switched to buster-backports and noticed an issue that (I think) > could potentially break > systems migrating to bullseye. > On a system having encrypted root, keyfile on usb-stick and multiple btrfs > subvolumes, the system > fails to mount all subvolumes. > > If there is no solution, then maybe a hint in the README could be added. We (src:crypttab) have precise semantics crypttab(5)'s 3rd column (after unescaping octal-sequences): - if a key script is used, the value of the 3rd column is used as 1st positional argument; - if the value is "none", the passphrase is read interactively from the console; - otherwise the assume is assumed to be an existing file or block/character device and the passphrase is read from it. In particular, one might very well use a key file named ‘/etc/my.key:LABEL=keydev’ in the 3rd column, or use ‘foo:bar:baz’ and have a custom keyscript split the string and interpret it as 3 arguments. (Our passkev key script does that with ‘blockdev:keyfile’ for instance.) I'm thus reassign this to systemd. With systemd 241-7~deb10u6 ‘/etc/my.key:LABEL=keydev’ is interpreted as the path to a key file, while after upgrading to Bullseye it ignores that file and waits for a block device with label ‘keydev’ to show up. This is arguably not a severe regression though. :-) However the device might have been mapped at an earlier stage (for instance at initramfs stage), and systemd-cryptsetup-generator should not generate units in that case; unlocking might have been done using a crypttab(5) entry systemd doesn't understand, cf. for instance -1 or #618862. At the very least it shouldn't delay the boot or end up in a failed state. AFAICT while systemd delays the boot until the device lookup timeouts (and ends up in a failed state), if the mapped target contains a file system with a matching fstab(5) entry then systemd does mount it. But unlike the OP I've only tried with ext4 not multi-volume btrfs. Cheers -- Guilhem.
signature.asc
Description: PGP signature
