1
1
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-24 21:34:08 +03:00
systemd-stable/man/systemd-cryptsetup-generator.xml
Zbigniew Jędrzejewski-Szmek fdbbee37d5 man: drop unused <authorgroup> tags from man sources
Docbook styles required those to be present, even though the templates that we
use did not show those names anywhere. But something changed semi-recently (I
would suspect docbook templates, but there was only a minor version bump in
recent years, and the changelog does not suggest anything related), and builds
now work without those entries. Let's drop this dead weight.

Tested with F26-F29, debian unstable.

$ perl -i -0pe 's/\s*<authorgroup>.*<.authorgroup>//gms' man/*xml
2018-06-14 12:22:18 +02:00

170 lines
6.9 KiB
XML

<?xml version="1.0"?>
<!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
SPDX-License-Identifier: LGPL-2.1+
-->
<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 by initial RAM disk (initrd) while
<varname>luks=</varname> is honored by both the main system
and 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 by
initial RAM disk (initrd) while
<varname>luks.crypttab=</varname> is honored by both the main
system and 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 by initial RAM disk (initrd) while
<varname>luks.uuid=</varname> is honored by both the main
system and the initrd.</para>
<para>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
<literal>luks-UUID</literal>.</para>
<para>If /etc/crypttab 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><varname>rd.luks.name=</varname> is honored only by
initial RAM disk (initrd) while <varname>luks.name=</varname>
is honored by both the main system and 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>
<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>
<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><varname>rd.luks.key=</varname>
is honored only by initial RAM disk
(initrd) while
<varname>luks.key=</varname> is
honored by both the main system and
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 project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>