mirror of
https://github.com/systemd/systemd.git
synced 2026-11-06 05:17:24 +00:00
Lennart Poettering
f4bff983b2
Modelled after SplitName=/--split=: a new ManifestName= setting (defaulting to "%t", "-" disables) plus --manifest= make systemd-repart write a UAPI.16 manifest for each partition whose file system tree it populates. The manifest is generated right when the tree is populated (be it in the staging directory for mkfs --root style population, or in the child process that copies into the mounted file system), into an O_TMPFILE file in the image's directory, which is linked into place once the partition UUIDs and hence the final name are known, next to the image as <image>.<name>.Uapi16Manifest. The result is what systemd-manifest would generate for the tree, and can hence be verified with it. In addition --manifest-gpt= writes a manifest of the partition table itself as <image>.Uapi16Manifest: one object per partition, carrying the GPT type, UUID, label and flags, the partition size and the SHA256 digest of its contents, and referencing the partition data by its offset in the image in the "contents" array. Partitions are named like their split-out files, whether or not --split= is used. For verity signature partitions the size and digest cover the signature JSON object only, not the NUL padding after it, matching the (trimmed) split-out file. This is the format sysupdate consumes for partition resources. It also carries an object for the image as a whole, named like the image file, with the size and SHA256 digest of the complete disk. The partition table manifest is written to a temporary file first, and linked into place once complete. Incomplete manifests (i.e. where inodes had to be skipped or metadata omitted) are refused, as systemd-manifest does without --graceful. In dry-run mode no manifests are written. The manifest paths show up in the partition table dump, as the split paths do. --manifest-fields= selects the per-file fields to include in the manifests of the partitions' file system trees, like --field= of systemd-manifest does. If --manifest-private-key= and --manifest-certificate= (plus optionally --manifest-private-key-source= and --manifest-certificate-source=) are specified, all generated manifests are signed with a PKCS#7 signature object. These are deliberately separate from --private-key= and --certificate=, which remain in use for verity signature partitions only. All manifest related switches are grouped in a section of their own in --help and the man page.
447 lines
23 KiB
XML
447 lines
23 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.5/docbookx.dtd">
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
|
|
|
<refentry id="systemd-manifest"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
<refentryinfo>
|
|
<title>systemd-manifest</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd-manifest</refentrytitle>
|
|
<manvolnum>1</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd-manifest</refname>
|
|
<refpurpose>Generate and verify file manifests of directory trees</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>systemd-manifest</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="plain">make</arg>
|
|
<arg choice="opt"><replaceable>DIRECTORY</replaceable>
|
|
<arg choice="opt"><replaceable>MANIFEST</replaceable></arg></arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-manifest</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="plain">verify</arg>
|
|
<arg choice="opt"><replaceable>DIRECTORY</replaceable>
|
|
<arg choice="opt"><replaceable>MANIFEST</replaceable></arg></arg>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><command>systemd-manifest</command> generates file manifests of directory trees, and verifies
|
|
directory trees against such manifests. Four manifest formats are supported:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>list</option></term>
|
|
|
|
<listitem><para>A plain list of file names, one per line. Directories are suffixed with a
|
|
slash.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>sha256sums</option></term>
|
|
|
|
<listitem><para>The format generated by
|
|
<citerefentry project='man-pages'><refentrytitle>sha256sum</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
i.e. a hash and a file name per line. Only regular files are listed. This is the format
|
|
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
consumes as <filename>SHA256SUMS</filename> file.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>mtree</option></term>
|
|
|
|
<listitem><para>The BSD <command>mtree</command> format, listing inode type, access mode, ownership,
|
|
size, hash, symlink target and device numbers of each file. This format is supported for generation
|
|
only.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>uapi16</option></term>
|
|
|
|
<listitem><para>A <ulink url="https://uapi-group.org/specifications/specs/file_manifest/">UAPI.16
|
|
file manifest</ulink>, i.e. a JSON-SEQ stream with one object per file. This is the format
|
|
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
consumes as <filename>Uapi16Manifest</filename> file, and the same format
|
|
<citerefentry><refentrytitle>systemd-dissect</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
generates with <option>--uapi16</option>. This is the default.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Manifests are generated and verified in a streaming fashion, i.e. one file at a time, and never
|
|
loaded into memory as a whole, so that very large trees can be processed.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Commands</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>make</command> <optional><replaceable>DIRECTORY</replaceable> <optional><replaceable>MANIFEST</replaceable></optional></optional></term>
|
|
|
|
<listitem><para>Generates a manifest of the specified directory tree, and writes it to the specified
|
|
manifest file. If no directory is specified, the current working directory is used. If no manifest
|
|
file is specified (or if <literal>-</literal> is specified), the manifest is written to standard
|
|
output. The manifest file is replaced atomically, i.e. it is only put in place once it has been
|
|
written completely.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>verify</command> <optional><replaceable>DIRECTORY</replaceable> <optional><replaceable>MANIFEST</replaceable></optional></optional></term>
|
|
|
|
<listitem><para>Verifies the specified directory tree against the specified manifest file. If no
|
|
directory is specified, the current working directory is used. If no manifest file is specified (or
|
|
if <literal>-</literal> is specified), the manifest is read from standard input. If
|
|
<option>--format=</option> is not specified, the format is derived from the file name of the
|
|
manifest if possible, and otherwise defaults to <option>uapi16</option>.</para>
|
|
|
|
<para>Every entry of the manifest is checked against the tree: the file must exist, have the
|
|
listed inode type and, as far as the manifest carries this information and the
|
|
<option>--field=</option> setting asks for it, the listed size, hash, access mode, ownership,
|
|
modification time, extended attributes, symlink target and device numbers. All mismatches are
|
|
reported, and the command fails if there was at least one. The <option>mtree</option> format is not
|
|
supported for verification.</para>
|
|
|
|
<para>Note that the check only goes one way: every file listed in the manifest must exist in the tree
|
|
as described, but the tree may contain additional files that the manifest does not list. These are
|
|
not reported, and do not cause verification to fail. Hence a successful verification shows that the
|
|
tree contains everything the manifest describes, but not that it contains nothing else.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
<para>The following options are understood:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>--format=<replaceable>FORMAT</replaceable></option></term>
|
|
|
|
<listitem><para>Selects the manifest format. Takes one of <option>list</option>,
|
|
<option>sha256sums</option>, <option>mtree</option>, <option>uapi16</option>, see above. Defaults
|
|
to <option>uapi16</option> for <command>make</command>. For <command>verify</command> defaults to
|
|
the format derived from the file name of the manifest, and <option>uapi16</option> if that is not
|
|
possible.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--field=<replaceable>FIELDS</replaceable></option></term>
|
|
|
|
<listitem><para>Selects the per-file fields to include in the manifest when generating, and to check
|
|
when verifying. Takes a comma separated list of the field names listed in the table below. The
|
|
special values <option>all</option>, <option>default</option> and <option>none</option> may be used
|
|
to select all, the default set or no fields. Items may be prefixed with <literal>+</literal> or
|
|
<literal>-</literal> to add or remove fields from the current set instead of replacing it. The option
|
|
may be specified multiple times. Note that the inode type is always included, if the format can
|
|
express it. The <option>list</option> format carries no fields at all.</para>
|
|
|
|
<table>
|
|
<title>Manifest fields</title>
|
|
<tgroup cols='4'>
|
|
<colspec colname='field' />
|
|
<colspec colname='default' />
|
|
<colspec colname='formats' />
|
|
<colspec colname='description' />
|
|
<thead>
|
|
<row>
|
|
<entry>Field</entry>
|
|
<entry>Included by default</entry>
|
|
<entry>Formats</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><option>mode</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Access mode bits</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>uid</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Owning numeric UID</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>gid</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Owning numeric GID</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>size</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Size of regular files</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>hash</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>mtree, sha256sums, uapi16</entry>
|
|
<entry>Digest of the contents of regular files</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>symlink</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Symlink target</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>device</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Major/minor numbers of device nodes</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>hardlink</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>uapi16</entry>
|
|
<entry>Hardlink relationships</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>mtime</option></entry>
|
|
<entry><emphasis>no</emphasis></entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Modification time</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>user-xattr</option></entry>
|
|
<entry>yes</entry>
|
|
<entry>uapi16</entry>
|
|
<entry>Extended attributes in the <literal>user.</literal> namespace</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>user-name</option></entry>
|
|
<entry><emphasis>no</emphasis></entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Owning user name</entry>
|
|
</row>
|
|
<row>
|
|
<entry><option>group-name</option></entry>
|
|
<entry><emphasis>no</emphasis></entry>
|
|
<entry>mtree, uapi16</entry>
|
|
<entry>Owning group name</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para><emphasis>The fields <option>mtime</option>, <option>user-name</option> and
|
|
<option>group-name</option> are not included by default, and have to be enabled
|
|
explicitly</emphasis>, for example with <literal>--field=+user-name,+group-name</literal>.
|
|
Modification times typically complicate reproducibility. User and group names are resolved via the
|
|
user database of the host (i.e. via NSS, like
|
|
<citerefentry project='man-pages'><refentrytitle>tar</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
does), hence reflect the host's view, which is not necessarily the one of the tree or image the
|
|
manifest describes. IDs that cannot be resolved to a name are counted as omitted metadata. When
|
|
verifying, the names are compared with the ones the host resolves the IDs to.</para>
|
|
|
|
<para>If <option>user-xattr</option> is enabled (which it is by default), the extended attributes in
|
|
the <literal>user.</literal> namespace of all inodes except symlinks are recorded, including for
|
|
inodes that have no such attributes, so that a verifier can tell missing attributes apart from
|
|
unrecorded ones. On file systems that do not support extended attributes, inodes are considered to
|
|
have none. Extended attributes in other namespaces (such as security labels) are never
|
|
included.</para>
|
|
|
|
<para>The same default set of fields is used by
|
|
<citerefentry><refentrytitle>systemd-dissect</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
and
|
|
<citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
when generating manifests.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--hash=<replaceable>ALGORITHM</replaceable></option></term>
|
|
|
|
<listitem><para>Selects the hash algorithm to use for the <option>hash</option> field of the
|
|
<option>mtree</option> format. Takes one of <option>sha256</option> or <option>sha512</option>. With
|
|
<option>sha512</option> a <literal>sha512sum=</literal> keyword is listed instead of
|
|
<literal>sha256sum=</literal>. The other formats only support <option>sha256</option>. Defaults to
|
|
<option>sha256</option>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--graceful</option></term>
|
|
|
|
<listitem><para>When generating a manifest with <command>make</command>, do not fail if some inodes
|
|
had to be skipped or some of their metadata had to be omitted, because they could not be read (for
|
|
example due to missing privileges) or are not representable in the selected format. Instead, log a
|
|
warning and return success. The top-level inode must be covered by the manifest in any case, but its
|
|
metadata may be incomplete.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--private-key=<replaceable>PATH/URI</replaceable></option></term>
|
|
<term><option>--private-key-source=<replaceable>TYPE</replaceable>[:<replaceable>NAME</replaceable>]</option></term>
|
|
<term><option>--certificate=<replaceable>PATH</replaceable></option></term>
|
|
<term><option>--certificate-source=<replaceable>TYPE</replaceable>[:<replaceable>NAME</replaceable>]</option></term>
|
|
|
|
<listitem><para>Set the private key and certificate to use for signing. When generating a
|
|
<option>uapi16</option> manifest with <command>make</command>, the manifest is signed if (and only
|
|
if) <option>--private-key=</option> is specified, in which case <option>--certificate=</option> must
|
|
be specified too. A signature object is then appended to the manifest, carrying a detached PKCS#7
|
|
(CMS) signature in DER format. The signature covers the exact bytes of the manifest preceding the
|
|
signature object (without any color sequences that might be inserted when writing to a terminal).
|
|
RSA, ECDSA and Ed25519 keys are supported. For RSA and ECDSA keys the signature is made directly over
|
|
the digest of the manifest, for Ed25519 keys it is made over a set of signed attributes carrying the
|
|
SHA-512 digest of the manifest, as required by <ulink
|
|
url="https://www.rfc-editor.org/rfc/rfc8419">RFC 8419</ulink>. Signing requires OpenSSL.</para>
|
|
|
|
<para>When verifying, only <option>--certificate=</option> is used: if specified, the manifest must
|
|
carry a signature that verifies against this certificate, instead of one of the certificates found in
|
|
the VOA hierarchy, see <option>--verify-signature=</option> below. The
|
|
<option>--certificate=</option> option takes a path to a PEM encoded X.509 certificate or a URI
|
|
that's passed to the OpenSSL provider configured with <option>--certificate-source=</option>. The
|
|
<option>--certificate-source=</option> option takes one of <literal>file</literal> or
|
|
<literal>provider</literal>, with the latter being followed by a specific provider identifier,
|
|
separated with a colon, e.g. <literal>provider:pkcs11</literal>. The
|
|
<option>--private-key=</option> option can take a path or a URI that will be passed to the OpenSSL
|
|
engine or provider, as specified by <option>--private-key-source=</option> as a
|
|
<literal>type:name</literal> tuple, such as <literal>engine:pkcs11</literal>.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--verify-signature=<replaceable>BOOL</replaceable></option></term>
|
|
|
|
<listitem><para>Controls whether to verify the signature of <option>uapi16</option> manifests when
|
|
verifying a directory tree. Takes a boolean, defaults to true. If enabled, the manifest must carry a
|
|
PKCS#7 signature made with the private key of the certificate specified with
|
|
<option>--certificate=</option>, or, if that option is not used, of one of the X.509 certificates
|
|
found in the <ulink
|
|
url="https://uapi-group.org/specifications/specs/file_hierarchy_for_the_verification_of_os_artifacts/">File
|
|
Hierarchy for the Verification of OS Artifacts</ulink> (VOA), otherwise verification fails. In the
|
|
latter case, certificates are read from
|
|
<filename><replaceable>OS</replaceable>/manifest/<replaceable>CONTEXT</replaceable>/x509/<replaceable>NAME</replaceable>-certificate.pem</filename>
|
|
below the VOA load paths <filename>/etc/voa/</filename>, <filename>/run/voa/</filename>,
|
|
<filename>/usr/local/share/voa/</filename> and <filename>/usr/share/voa/</filename>, where
|
|
<replaceable>OS</replaceable> is derived from
|
|
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
|
|
<replaceable>CONTEXT</replaceable> is configured with <option>--voa-context=</option>. Only artifact
|
|
verifiers are supported, i.e. the certificates are trusted as they are, and are not checked against
|
|
trust anchors. Verification fails if no certificates are found. If disabled, signature objects in the
|
|
manifest are ignored. The <option>list</option> and <option>sha256sums</option> formats carry no
|
|
signatures, hence for these this option has no effect, except that explicitly enabling it results in
|
|
an error. Requires OpenSSL.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--voa-context=<replaceable>CONTEXT</replaceable></option></term>
|
|
|
|
<listitem><para>Selects the VOA context to look up certificates in, if signatures are verified
|
|
without <option>--certificate=</option>, see above. Defaults to <literal>default</literal>. Use
|
|
<option>--voa-context=sysupdate</option> to verify manifests against the same certificates
|
|
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
uses for verifying <filename>Uapi16Manifest</filename> files it downloads.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v263"/></listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="standard-options.xml" xpointer="json" />
|
|
<xi:include href="standard-options.xml" xpointer="no-pager" />
|
|
<xi:include href="standard-options.xml" xpointer="help" />
|
|
<xi:include href="standard-options.xml" xpointer="version" />
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Exit status</title>
|
|
|
|
<para>On success, 0 is returned, a non-zero failure code otherwise. In particular,
|
|
<command>verify</command> returns non-zero if the directory tree does not match the manifest, and
|
|
<command>make</command> returns non-zero if an inode had to be skipped or some of its requested metadata
|
|
had to be omitted, because it could not be read (for example due to missing privileges) or is not
|
|
representable in the selected format, unless <option>--graceful</option> is specified. In the latter
|
|
cases the manifest is still generated, but is not written to the output file if one is specified. Inodes
|
|
other than regular files skipped in <option>sha256sums</option> format are not considered a failure,
|
|
since this format does not list them by design.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Examples</title>
|
|
|
|
<example>
|
|
<title>Generate an unsigned UAPI.16 manifest of a directory tree and verify it</title>
|
|
|
|
<programlisting>$ systemd-manifest make /srv/tree > Uapi16Manifest
|
|
$ systemd-manifest verify --verify-signature=no /srv/tree Uapi16Manifest</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Generate a SHA256SUMS file of the current directory, without ownership or mode information</title>
|
|
|
|
<programlisting>$ systemd-manifest make --format=sha256sums > SHA256SUMS
|
|
$ sha256sum -c SHA256SUMS</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Only verify file contents, ignoring ownership and access modes</title>
|
|
|
|
<programlisting>$ systemd-manifest verify --verify-signature=no --field=size,hash /srv/tree Uapi16Manifest</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Generate a signed manifest, and verify it against the certificate</title>
|
|
|
|
<programlisting>$ systemd-manifest make --private-key=foo-private-key.pem --certificate=foo-certificate.pem /srv/tree > Uapi16Manifest
|
|
$ systemd-manifest verify --certificate=foo-certificate.pem /srv/tree Uapi16Manifest</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Verify a manifest against the certificates systemd-sysupdate trusts</title>
|
|
|
|
<programlisting># cp foo-certificate.pem /etc/voa/$(. /etc/os-release; echo $ID)/manifest/sysupdate/x509/
|
|
$ systemd-manifest verify --voa-context=sysupdate /srv/tree Uapi16Manifest</programlisting>
|
|
</example>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para><simplelist type="inline">
|
|
<member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-dissect</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry project='man-pages'><refentrytitle>sha256sum</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
</simplelist></para>
|
|
</refsect1>
|
|
|
|
</refentry>
|