<para>This parameter is the analogue of the first <citerefentry><refentrytitle>crypttab</refentrytitle>

<manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para>

<term><varname>luks.data=</varname></term>

<term><varname>rd.luks.data=</varname></term>

<listitem><para>Takes a LUKS super block UUID followed by a <literal>=</literal> and a block device

specification for device hosting encrypted data.</para>

<para>For those entries specified with <varname>rd.luks.uuid=</varname> or

<varname>luks.uuid=</varname>, the data device will be set to the one specified by

<varname>rd.luks.data=</varname> or <varname>luks.data=</varname> of the corresponding UUID.</para>

<para>LUKS data device parameter is usefull for specifying encrypted data devices with detached headers specified in

<varname>luks.options</varname> entry containing <literal>header=</literal> argument. For example,

<varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40

<varname>rd.luks.options=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/path/to/luks.hdr

<varname>rd.luks.data=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx.

Hence, in this case, we will attempt to unlock LUKS device assembled from data device <literal>/dev/sdx</literal>

and LUKS header (metadata) put in <literal>/path/to/luks.hdr</literal> file. This syntax is for now

only supported on a per-device basis, i.e. you have to specify LUKS device UUID.</para>

<para>This parameter is the analogue of the second <citerefentry><refentrytitle>crypttab</refentrytitle>

<manvolnum>5</manvolnum></citerefentry> field <replaceable>encrypted-device</replaceable>.</para>

<para><varname>rd.luks.data=</varname> is honored only by initial RAM disk (initrd) while

<varname>luks.data=</varname> is honored by both the main system and the initrd.</para>

<para>This parameter is the analogue of the third <citerefentry><refentrytitle>crypttab</refentrytitle>

<manvolnum>5</manvolnum></citerefentry> field <replaceable>key-file</replaceable>.</para>

<varlistentry>

<term><varname>luks.options=</varname></term>

<term><varname>rd.luks.options=</varname></term>

<listitem><para>Takes a LUKS super block UUID followed by an

<literal>=</literal> and a string of options separated by

commas as argument. This will override the options for the

given UUID.</para>

<para>If only a list of options, without an UUID, is

specified, they apply to any UUIDs not specified elsewhere,

and without an entry in

<filename>/etc/crypttab</filename>.</para>

<para>This parameter is the analogue of the fourth <citerefentry><refentrytitle>crypttab</refentrytitle>

<manvolnum>5</manvolnum></citerefentry> field <replaceable>options</replaceable>.</para>

<para>It is possible to specify an external device which

should be mounted before we attempt to unlock the LUKS device.

systemd-cryptsetup will assemble LUKS device by combining

data device specified in <varname>luks.data</varname> with

detached LUKS header found in <literal>header=</literal>

argument. For example,

<varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40

<varname>rd.luks.options=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/luks.hdr:LABEL=hdrdev

<varname>rd.luks.data=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx.

Hence, in this case, we will attempt to mount file system

residing on the block device with label <literal>hdrdev</literal>, and look

for <literal>luks.hdr</literal> on that file system. Said header will be used

to unlock (decrypt) encrypted data stored on /dev/sdx.

This syntax is for now only supported on a per-device basis,

i.e. you have to specify LUKS device UUID.</para>

<para><varname>rd.luks.options=</varname> is honored only by initial

RAM disk (initrd) while <varname>luks.options=</varname> is

honored by both the main system and the initrd.</para>

</listitem>

</varlistentry>