shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2025-03-08 20:58:20 +03:00
Code

man: add more commas for clarify and reword a few sentences

Browse Source
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2017-02-08 22:53:16 -05:00
parent 08fe86d5be
commit ef3116b5d4
2 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
man/systemd-nspawn.xml
View File

@ -256,14 +256,14 @@
<listitem><para>Takes a data integrity (dm-verity) root hash specified in hexadecimal. This option enables data
integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above). The
specified hash must match the root hash of integrity data, and is usually at least 256bits (and hence 64
specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64
formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but
the image file carries the <literal>user.verity.roothash</literal> extended file attribute (see <citerefentry
project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>), then the root
hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or
not supported by the underlying file system), but a file with the <filename>.roothash</filename> suffix is
found next to the image file, bearing otherwise the same name the root hash is read from it and automatically
used (again, as formatted hexadecimal characters).</para></listitem>
is not supported by the underlying file system), but a file with the <filename>.roothash</filename> suffix is
found next to the image file, bearing otherwise the same name, the root hash is read from it and automatically
used, also as formatted hexadecimal characters.</para></listitem>
</varlistentry>
<varlistentry>

14
man/systemd.exec.xml
View File

@ -150,13 +150,13 @@
<term><varname>MountAPIVFS=</varname></term>
<listitem><para>Takes a boolean argument. If on, a private mount namespace for the unit's processes is created
and the API file systems <filename>/proc</filename>, <filename>/sys</filename> and <filename>/dev</filename>
will be mounted inside of it, unless they are already mounted. Note that this option has no effect unless used
in conjunction with <varname>RootDirectory=</varname>/<varname>RootImage=</varname> as these three mounts are generally mounted in the host
anyway, and unless the root directory is changed the private mount namespace will be a 1:1 copy of the host's,
and include these three mounts. Note that the <filename>/dev</filename> file system of the host is bind mounted
if this option is used without <varname>PrivateDevices=</varname>. To run the service with a private, minimal
version of <filename>/dev/</filename>, combine this option with
and the API file systems <filename>/proc</filename>, <filename>/sys</filename>, and <filename>/dev</filename>
are mounted inside of it, unless they are already mounted. Note that this option has no effect unless used in
conjunction with <varname>RootDirectory=</varname>/<varname>RootImage=</varname> as these three mounts are
generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace
will be a 1:1 copy of the host's, and include these three mounts. Note that the <filename>/dev</filename> file
system of the host is bind mounted if this option is used without <varname>PrivateDevices=</varname>. To run
the service with a private, minimal version of <filename>/dev/</filename>, combine this option with
<varname>PrivateDevices=</varname>.</para></listitem>
</varlistentry>