systemd-cryptsetup-generator implements systemd.generator(7).
If /etc/crypttab contains entries with the same UUID, then the name, keyfile and options specified there will be used. Otherwise, the device will have the name "luks-UUID".
If /etc/crypttab exists, only those UUIDs specified on the kernel command line will be activated in the initrd or the real root.
rd.luks.name= is honored only by initial RAM disk (initrd) while luks.name= is honored by both the main system and the initrd.
If only a list of options, without an UUID, is specified, they apply to any UUIDs not specified elsewhere, and without an entry in /etc/crypttab.
rd.luks.options= is honored only by initial RAM disk (initrd) while luks.options= is honored by both the main system and the initrd.
For those entries specified with rd.luks.uuid= or luks.uuid=, the password file will be set to the one specified by rd.luks.key= or luks.key= of the corresponding UUID, or the password file that was specified without a UUID.
It is also possible to specify an external device which should be mounted before we attempt to unlock the LUKS device. systemd-cryptsetup will use password file stored on that device. Device containing password file is specified by appending colon and a device identifier to the password file path. For example, rd.luks.uuid=b40f1abf-2a53-400a-889a-2eccc27eaa40 rd.luks.key=b40f1abf-2a53-400a-889a-2eccc27eaa40=/keyfile:LABEL=keydev. Hence, in this case, we will attempt to mount file system residing on the block device with label "keydev". This syntax is for now only supported on a per-device basis, i.e. you have to specify LUKS device UUID.
rd.luks.key= is honored only by initial RAM disk (initrd) while luks.key= is honored by both the main system and the initrd.