1SYSTEMD-CRYPTSETUP-GENERATsOyRs(t8e)md-cryptsetup-geneSrYaStToErMD-CRYPTSETUP-GENERATOR(8)
2
3
4

NAME

6       systemd-cryptsetup-generator - Unit generator for /etc/crypttab
7

SYNOPSIS

9       /usr/lib/systemd/system-generators/systemd-cryptsetup-generator
10

DESCRIPTION

12       systemd-cryptsetup-generator is a generator that translates
13       /etc/crypttab into native systemd units early at boot and when
14       configuration of the system manager is reloaded. This will create
15       systemd-cryptsetup@.service(8) units as necessary.
16
17       systemd-cryptsetup-generator implements systemd.generator(7).
18

KERNEL COMMAND LINE

20       systemd-cryptsetup-generator understands the following kernel command
21       line parameters:
22
23       luks=, rd.luks=
24           Takes a boolean argument. Defaults to "yes". If "no", disables the
25           generator entirely.  rd.luks= is honored only by initial RAM disk
26           (initrd) while luks= is honored by both the main system and the
27           initrd.
28
29       luks.crypttab=, rd.luks.crypttab=
30           Takes a boolean argument. Defaults to "yes". If "no", causes the
31           generator to ignore any devices configured in /etc/crypttab
32           (luks.uuid= will still work however).  rd.luks.crypttab= is honored
33           only by initial RAM disk (initrd) while luks.crypttab= is honored
34           by both the main system and the initrd.
35
36       luks.uuid=, rd.luks.uuid=
37           Takes a LUKS superblock UUID as argument. This will activate the
38           specified device as part of the boot process as if it was listed in
39           /etc/crypttab. This option may be specified more than once in order
40           to set up multiple devices.  rd.luks.uuid= is honored only by
41           initial RAM disk (initrd) while luks.uuid= is honored by both the
42           main system and the initrd.
43
44           If /etc/crypttab contains entries with the same UUID, then the
45           name, keyfile and options specified there will be used. Otherwise,
46           the device will have the name "luks-UUID".
47
48           If /etc/crypttab exists, only those UUIDs specified on the kernel
49           command line will be activated in the initrd or the real root.
50
51       luks.name=, rd.luks.name=
52           Takes a LUKS super block UUID followed by an "=" and a name. This
53           implies rd.luks.uuid= or luks.uuid= and will additionally make the
54           LUKS device given by the UUID appear under the provided name.
55
56           This parameter is the analogue of the first crypttab(5) field
57           volume-name.
58
59           rd.luks.name= is honored only by initial RAM disk (initrd) while
60           luks.name= is honored by both the main system and the initrd.
61
62       luks.data=, rd.luks.data=
63           Takes a LUKS super block UUID followed by a "=" and a block device
64           specification for device hosting encrypted data.
65
66           For those entries specified with rd.luks.uuid= or luks.uuid=, the
67           data device will be set to the one specified by rd.luks.data= or
68           luks.data= of the corresponding UUID.
69
70           LUKS data device parameter is useful for specifying encrypted data
71           devices with detached headers specified in luks.options entry
72           containing "header=" argument. For example,
73           rd.luks.uuid=b40f1abf-2a53-400a-889a-2eccc27eaa40
74           rd.luks.options=b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/path/to/luks.hdr
75           rd.luks.data=b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx. Hence,
76           in this case, we will attempt to unlock LUKS device assembled from
77           data device "/dev/sdx" and LUKS header (metadata) put in
78           "/path/to/luks.hdr" file. This syntax is for now only supported on
79           a per-device basis, i.e. you have to specify LUKS device UUID.
80
81           This parameter is the analogue of the second crypttab(5) field
82           encrypted-device.
83
84           rd.luks.data= is honored only by initial RAM disk (initrd) while
85           luks.data= is honored by both the main system and the initrd.
86
87       luks.key=, rd.luks.key=
88           Takes a password file name as argument or a LUKS super block UUID
89           followed by a "=" and a password file name.
90
91           For those entries specified with rd.luks.uuid= or luks.uuid=, the
92           password file will be set to the one specified by rd.luks.key= or
93           luks.key= of the corresponding UUID, or the password file that was
94           specified without a UUID.
95
96           It is also possible to specify an external device which should be
97           mounted before we attempt to unlock the LUKS device.
98           systemd-cryptsetup will use password file stored on that device.
99           Device containing password file is specified by appending colon and
100           a device identifier to the password file path. For example,
101           rd.luks.uuid=b40f1abf-2a53-400a-889a-2eccc27eaa40
102           rd.luks.key=b40f1abf-2a53-400a-889a-2eccc27eaa40=/keyfile:LABEL=keydev.
103           Hence, in this case, we will attempt to mount file system residing
104           on the block device with label "keydev". This syntax is for now
105           only supported on a per-device basis, i.e. you have to specify LUKS
106           device UUID.
107
108           This parameter is the analogue of the third crypttab(5) field
109           key-file.
110
111           rd.luks.key= is honored only by initial RAM disk (initrd) while
112           luks.key= is honored by both the main system and the initrd.
113
114       luks.options=, rd.luks.options=
115           Takes a LUKS super block UUID followed by an "=" and a string of
116           options separated by commas as argument. This will override the
117           options for the given UUID.
118
119           If only a list of options, without an UUID, is specified, they
120           apply to any UUIDs not specified elsewhere, and without an entry in
121           /etc/crypttab.
122
123           This parameter is the analogue of the fourth crypttab(5) field
124           options.
125
126           It is possible to specify an external device which should be
127           mounted before we attempt to unlock the LUKS device.
128           systemd-cryptsetup will assemble LUKS device by combining data
129           device specified in luks.data with detached LUKS header found in
130           "header=" argument. For example,
131           rd.luks.uuid=b40f1abf-2a53-400a-889a-2eccc27eaa40
132           rd.luks.options=b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/luks.hdr:LABEL=hdrdev
133           rd.luks.data=b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx. Hence,
134           in this case, we will attempt to mount file system residing on the
135           block device with label "hdrdev", and look for "luks.hdr" on that
136           file system. Said header will be used to unlock (decrypt) encrypted
137           data stored on /dev/sdx. This syntax is for now only supported on a
138           per-device basis, i.e. you have to specify LUKS device UUID.
139
140           rd.luks.options= is honored only by initial RAM disk (initrd) while
141           luks.options= is honored by both the main system and the initrd.
142

SEE ALSO

144       systemd(1), crypttab(5), systemd-cryptsetup@.service(8), systemd-
145       cryptenroll(1), cryptsetup(8), systemd-fstab-generator(8)
146
147
148
149systemd 251                                    SYSTEMD-CRYPTSETUP-GENERATOR(8)
Impressum