Dear Maintainer,
when using the `decrypt_derived` keyscript, the `cryptroot` initramfs hook expects the `key file` in `/etc/crypttab` to be the `target name` of another crypttab entry. Beside the runtime-use as argument to the keyscript, the `key file` is in this case also used during initramfs creation to make sure the "parent" is unlocked beforehand. And this all works fine. One thing I noticed thought is that systemd throws a few messages with such a setup. These appear after the initrd, so with the real root already mounted. (I slightly reordered the messages to increase readability)
```
ERROR systemd[1]: /run/systemd/generator/systemd-cryptsetup@luks\x2dtwo.service:14: RequiresMountsFor= path is not absolute, ignoring: luks-one
[...]
INFO systemd[1]: Starting Cryptography Setup for luks-one...
WARN systemd-cryptsetup[944]: Encountered unknown /etc/crypttab option 'initramfs', ignoring.
INFO systemd-cryptsetup[944]: Volume luks-one already active.
INFO systemd[1]: Finished Cryptography Setup for luks-one.
INFO systemd[1]: Starting Cryptography Setup for luks-two...
WARN systemd-cryptsetup[910]: Password file path 'luks-one' is not absolute. Ignoring.
WARN systemd-cryptsetup[910]: Encountered unknown /etc/crypttab option 'initramfs', ignoring.
WARN systemd-cryptsetup[910]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
INFO systemd-cryptsetup[910]: Volume luks-two already active.
INFO systemd[1]: Finished Cryptography Setup for luks-two.
```
I am not worried about the three `Encountered unknown /etc/crypttab option` warnings, because they are valid; these options are specific to Debian's cryptroot hook. But the other two regarding the non-absolute key file bothered me a bit, especially because one is an error. Out of pure curiosity, I changed the key file in my crypttab from the target name `luks-one` to the absolute block device path `/dev/mapper/luks-one` to see what happens. To my surprise does the keyscript not *require* a target name as argument, it also works fine with a absolute device path. You get the same result when calling `./decrypt_derived luks-one` and `./decrypt_derived /dev/mapper/luks-one` (also works with `dev/disk/by-id/...` and others). And the error/warning from systemd are gone, plus it now actually adds `dev-mapper-luks\x2done.device` as a proper dependency to `systemd-cryptsetup@luks\x2dtwo.service`. The only thing that breaks when using a absolute device path is the recursive unlocking, which the hook will warn about during initramfs creation:
```
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64
cryptsetup: WARNING: target '/dev/mapper/luks-one' not found in /etc/crypttab
```
This can be functionally worked around by not relying on the recursion and explicitly setting the initramfs option for all needed entries. But being annoyed by that warning, I took a dive into the cryptroot hook sourcecode and created the attached patch, which detects a absolute key file and runs it through `dmsetup` to resolve it to a target name. With that, both the `cryptroot` hook and `systemd-cryptsetup` work.
I saw a few comments in the scripts to not trust `/dev/mapper/` so I am not sure if this breaks anything with regards to name-mangling, but I am sure you subject experts will be able to easily assess that.
I also acknowledge that one could partially or completely disable the systemd-cryptsetup-generator using kernel command line parameters, but that would prevent using the generated device/service units directly or as dependencies for other units. Unfortunately there is no systemd-cryptsetup-generator specific crypttab option to only disable unit generation for specific entries. I haven't tried to mask the generated services for the hook-handled devices, that would probably also work; the services are effectively no-ops in that case anyway.