mirror of
https://github.com/systemd/systemd.git
synced 2024-10-30 14:55:37 +03:00
8b9f092112
Fixes #25780. > Man page: crypttab.5 > Issue 1: Missing fullstop > Issue 2: I<cipher=>, I<hash=>, I<size=> → B<cipher=>, B<hash=>, B<size=> > > "Force LUKS mode\\&. When this mode is used, the following options are " > "ignored since they are provided by the LUKS header on the device: " > "I<cipher=>, I<hash=>, I<size=>" Seems OK to me. The full stop is there and has been for at least a few years. And we use <option> for the markup, which is appropriate here. > Man page: crypttab.5 > Issue 1: Missing fullstop > Issue 2: I<cipher=>, I<hash=>, I<keyfile-offset=>, I<keyfile-size=>, I<size=> → B<cipher=>, B<hash=>, B<keyfile-offset=>, B<keyfile-size=>, B<size=> > > "Use TrueCrypt encryption mode\\&. When this mode is used, the following " > "options are ignored since they are provided by the TrueCrypt header on the " > "device or do not apply: I<cipher=>, I<hash=>, I<keyfile-offset=>, I<keyfile-" > "size=>, I<size=>" Same. > Man page: journalctl.1 > Issue 1: make be → may be Fixed. > Issue 2: below\\&. → below: Fixed. > Man page: journalctl.1 > Issue: Colon at the end? > > "The following commands are understood\\&. If none is specified the default " > "is to display journal records\\&." > msgstr "" > "Die folgenden Befehle werden verstanden\\&. Falls keiner festgelegt ist, ist " > "die Anzeige von Journal-Datensätzen die Vorgabe\\&." This is a bit awkward, but I'm not sure how to fix it. > Man page: kernel-install.8 > Issue: methods a fallback → methods fallback It was correct, but I added a comma to make the sense clearer. > Man page: loader.conf.5 > Issue 1: secure boot variables → Secure Boot variables > Issue 2: one → one for (multiple times) > > "Supported secure boot variables are one database for authorized images, one " > "key exchange key (KEK) and one platform key (PK)\\&. For more information, " > "refer to the \\m[blue]B<UEFI specification>\\m[]\\&\\s-2\\u[2]\\d\\s+2, " > "under Secure Boot and Driver Signing\\&. Another resource that describe the " > "interplay of the different variables is the \\m[blue]B<EDK2 " > "documentation>\\m[]\\&\\s-2\\u[3]\\d\\s+2\\&." "one of" would sound strange. "One this and one that" is OK. > Man page: loader.conf.5 > Issue: systemd-boot → B<systemd-boot>(7) Fixed. > Man page: logind.conf.5 > Issue: systemd-logind → B<systemd-logind>(8) We use <filename>systemd-logind</> on subsequent references… I think that's good enough. > Man page: nss-myhostname.8 > Issue: B<getent> → B<getent>(1) Fixed. > Man page: nss-resolve.8 > Issue: B<systemd-resolved> → B<systemd-resolved>(8) The first reference does this, subsequent are shorter. > Man page: os-release.5 > Issue: Portable Services → Portable Services Documentation? Updated. > Man page: pam_systemd_home.8 > Issue: auth and account use "reason", while session and password do not? Reworded. > Man page: portablectl.1 > Issue: In systemd-portabled.service(8): Portable Services Documentation Updated. > Man page: repart.d.5 > Issue: The partition → the partition Fixed. > Man page: repart.d.5 > Issue: B<systemd-repart> → B<systemd-repart>(8) The first reference does this. I also change this one, because it's pretty far down in the text. > Man page: systemd.1 > Issue: kernel command line twice? > > "Takes a boolean argument\\&. If false disables importing credentials from " > "the kernel command line, qemu_fw_cfg subsystem or the kernel command line\\&." Apparently this was fixed already. > Man page: systemd-boot.7 > Issue: enrollement → enrollment Fixed. > Man page: systemd-cryptenroll.1 > Issue: multiple cases: any specified → the specified Reworded. > Man page: systemd-cryptenroll.1 > Issue: If this this → If this Fixed tree-wide. > Man page: systemd-cryptsetup-generator.8 > Issue: and the initrd → and in the initrd "Is honoured by the initrd" is OK, because we often speak about the initrd as a single unit. But in the same paragraph we also used "in the initrd", which makes the other use look sloppy. I changed it to "in the initrd" everywhere in that file. > Man page: systemd.directives.7 > Issue: Why are these two quoted (but not others)? > > "B<\\*(Aqh\\*(Aq>" > > B<\\*(Aqs\\*(Aq>" > > "B<\\*(Aqy\\*(Aq>" This is autogenerated from files… We use slightly different markup in different files, and it's just too hard to make it consistent. We gave up on this. > Man page: systemd.exec.5 > Issue 1: B<at>(1p) → B<at>(1) > Issue 2: B<crontab>(1p) → B<crontab>(1) Fixed. > Man page: systemd.exec.5 > Issue: B<select()> → B<select>(2) Fixed. > Man page: systemd.exec.5 > Issue: qemu → B<qemu>(1) The man page doesn't seem to be in any of the canonical places on the web. I added a link to online docs. > Man page: systemd.exec.5 > Issue: variable → variables Seems to be fixed already. > Man page: systemd-integritysetup-generator.8 > Issue: systemd-integritysetup-generator → B<systemd-integritysetup-generator> I changed <filename> to <command>. > Man page: systemd-integritysetup-generator.8 > Issue: superfluous comma at the end Already fixed. > Man page: systemd-measure.1 > Issue: (see B<--pcr-bank=>) below → (see B<--pcr-bank=> below) Reworded. > Man page: systemd-measure.1 > Issue: =PATH> → =>I<PATH> Fixed. > Man page: systemd-measure.1.po > Issue: B<--bank=DIGEST> → B<--bank=>I<DIGEST> Fixed. > Man page: systemd.netdev.5 > Issue: os the → on the Appears to have been fixed already. > Man page: systemd.netdev.5 > Issue: Onboard → On-board (as in previous string) Updated. > Man page: systemd.network.5 > Issue: B<systemd-networkd> -> B<systemd-networkd>(8) First reference does this, subsequent do not. > Man page: systemd.network.5 > Issue: B<netlabelctl> → B<netlabelctl>(8) First reference does this, subsequent do not. > Man page: systemd.network.5 > Issue: Missing verb (aquired? configured?) in the half sentence starting with "or by a " I dropped the comma. > Man page: systemd-nspawn.1 > Issue: All host users outside of that range → All other host users Reworded. > # FIXME no effect → no effect\\&. > #. type: Plain text > #: archlinux debian-unstable fedora-rawhide mageia-cauldron opensuse-tumbleweed > msgid "" > "Whichever ID mapping option is used, the same mapping will be used for users " > "and groups IDs\\&. If B<rootidmap> is used, the group owning the bind " > "mounted directory will have no effect" A period is added. Not sure if there's some other issue. > Man page: systemd-oomd.service.8 > Issue: B<systemd> → B<systemd>(1) Done. > Man page: systemd.path.5 > Issue 1: B<systemd.exec>(1) → B<systemd.exec>(5) > Issue 2: This section does not (yet?) exist Fixed. > Man page: systemd-pcrphase.service.8 > Issue 1: indicate phases into TPM2 PCR 11 ?? > Issue 2: Colon at the end of the paragraph? Fixed. > Man page: systemd-pcrphase.service.8 > Issue: final boot phase → final shutdown phase? Updated. > Man page: systemd-pcrphase.service.8 > Issue: for the the → for the Fixed tree-wide. > Man page: systemd-portabled.service.8 > Issue: In systemd-portabled.service(8): Portable Services Documentation Updated. > Man page: systemd-pstore.service.8 > Issue: Here and the following paragraphs: . → \\&. // Upstream: What does this comment mean? // You normally write \\&. for a full dot (full stop etc.); here you write only "." (i.e. a plain dot). > > "and we look up \"localhost\", nss-dns will send the following queries to " > "systemd-resolved listening on 127.0.0.53:53: first \"localhost.foobar.com\", " > "then \"localhost.barbar.com\", and finally \"localhost\". If (hopefully) the " > "first two queries fail, systemd-resolved will synthesize an answer for the " > "third query." Looks all OK to me. > Man page: systemd.resource-control.5 > Issue: Missing closing bracket after link to Control Groups version 1 Fixed. > Man page: systemd-sysext.8 > Issue: In systemd-portabled.service(8): Portable Services Documentation Updated. > Man page: systemd.timer.5 > Issue 1: B<systemd.exec>(1) → B<systemd.exec>(5) > Issue 2: This section does not (yet?) exist Fixed. > Man page: systemd.unit.5 > Issue: that is → that are Fixed. > Man page: systemd-veritysetup-generator.8 > Issue: systemd-veritysetup-generator → B<systemd-veritysetup-generator> > > "systemd-veritysetup-generator implements B<systemd.generator>(7)\\&." > > "systemd-veritysetup-generator understands the following kernel command line " > "parameters:" Updated. > Man page: systemd-volatile-root.service.8 > Issue: initrdyes → Initrd Fixed. > Man page: sysupdate.d.5 > Issue: : → \\&. (As above in TRANSFER) Updated. > Man page: sysupdate.d.5 > Issue: some → certain Updated. > Man page: sysupdate.d.5 > Issue 1: i\\&.e\\& → I\\&.e\\& Fixed. > Issue 2: the image → the system "image" seems correct. > Man page: tmpfiles.d.5 > Issue: systemd-tmpfiles → B<systemd-tmpfiles>(8) Updated.
225 lines
11 KiB
XML
225 lines
11 KiB
XML
<?xml version="1.0"?>
|
|
<!--*-nxml-*-->
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
|
<refentry id="systemd-cryptsetup-generator" conditional='HAVE_LIBCRYPTSETUP'>
|
|
|
|
<refentryinfo>
|
|
<title>systemd-cryptsetup-generator</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd-cryptsetup-generator</refentrytitle>
|
|
<manvolnum>8</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd-cryptsetup-generator</refname>
|
|
<refpurpose>Unit generator for <filename>/etc/crypttab</filename></refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<para><filename>/usr/lib/systemd/system-generators/systemd-cryptsetup-generator</filename></para>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><filename>systemd-cryptsetup-generator</filename> is a
|
|
generator that translates <filename>/etc/crypttab</filename> into
|
|
native systemd units early at boot and when configuration of the
|
|
system manager is reloaded. This will create
|
|
<citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
units as necessary.</para>
|
|
|
|
<para><filename>systemd-cryptsetup-generator</filename> implements
|
|
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Kernel Command Line</title>
|
|
|
|
<para><filename>systemd-cryptsetup-generator</filename>
|
|
understands the following kernel command line parameters:</para>
|
|
|
|
<variablelist class='kernel-commandline-options'>
|
|
<varlistentry>
|
|
<term><varname>luks=</varname></term>
|
|
<term><varname>rd.luks=</varname></term>
|
|
|
|
<listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
|
|
<literal>no</literal>, disables the generator entirely. <varname>rd.luks=</varname> is honored only
|
|
in the initrd while <varname>luks=</varname> is honored by both the main system and in the initrd.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>luks.crypttab=</varname></term>
|
|
<term><varname>rd.luks.crypttab=</varname></term>
|
|
|
|
<listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
|
|
<literal>no</literal>, causes the generator to ignore any devices configured in
|
|
<filename>/etc/crypttab</filename> (<varname>luks.uuid=</varname> will still work however).
|
|
<varname>rd.luks.crypttab=</varname> is honored only in initrd while
|
|
<varname>luks.crypttab=</varname> is honored by both the main system and in the initrd.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>luks.uuid=</varname></term>
|
|
<term><varname>rd.luks.uuid=</varname></term>
|
|
|
|
<listitem><para>Takes a LUKS superblock UUID as argument. This will activate the specified device as
|
|
part of the boot process as if it was listed in <filename>/etc/crypttab</filename>. This option may
|
|
be specified more than once in order to set up multiple devices. <varname>rd.luks.uuid=</varname> is
|
|
honored only in the initrd, while <varname>luks.uuid=</varname> is honored by both the main system
|
|
and in the initrd.</para>
|
|
|
|
<para>If <filename>/etc/crypttab</filename> contains entries with the same UUID, then the name,
|
|
keyfile and options specified there will be used. Otherwise, the device will have the name
|
|
<literal>luks-UUID</literal>.</para>
|
|
|
|
<para>If <filename>/etc/crypttab</filename> exists, only those UUIDs specified on the kernel command
|
|
line will be activated in the initrd or the real root.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>luks.name=</varname></term>
|
|
<term><varname>rd.luks.name=</varname></term>
|
|
|
|
<listitem><para>Takes a LUKS super block UUID followed by an
|
|
<literal>=</literal> and a name. This implies
|
|
<varname>rd.luks.uuid=</varname> or
|
|
<varname>luks.uuid=</varname> and will additionally make the
|
|
LUKS device given by the UUID appear under the provided
|
|
name.</para>
|
|
|
|
<para>This parameter is the analogue of the first <citerefentry><refentrytitle>crypttab</refentrytitle>
|
|
<manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para>
|
|
|
|
<para><varname>rd.luks.name=</varname> is honored only in the initrd, while
|
|
<varname>luks.name=</varname> is honored by both the main system and in the initrd.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<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 useful 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 in the initrd, while
|
|
<varname>luks.data=</varname> is honored by both the main system and in the initrd.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>luks.key=</varname></term>
|
|
<term><varname>rd.luks.key=</varname></term>
|
|
|
|
<listitem><para>Takes a password file name as argument or a
|
|
LUKS super block UUID followed by a <literal>=</literal> and a
|
|
password file name.</para>
|
|
|
|
<para>For those entries specified with
|
|
<varname>rd.luks.uuid=</varname> or
|
|
<varname>luks.uuid=</varname>, the password file will be set
|
|
to the one specified by <varname>rd.luks.key=</varname> or
|
|
<varname>luks.key=</varname> of the corresponding UUID, or the
|
|
password file that was specified without a UUID.</para>
|
|
|
|
<para>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,
|
|
<varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40
|
|
<varname>rd.luks.key=</varname>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 <literal>keydev</literal>.
|
|
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 third <citerefentry><refentrytitle>crypttab</refentrytitle>
|
|
<manvolnum>5</manvolnum></citerefentry> field <replaceable>key-file</replaceable>.</para>
|
|
|
|
<para><varname>rd.luks.key=</varname> is honored only in the initrd, while
|
|
<varname>luks.key=</varname> is honored by both the main system and in the initrd.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<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 in the initrd.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|