system/systemd
system/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd synced 2024-07-22 10:44:58 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity

man: sprinkle some more markup around

Browse source
This commit is contained in:
David Tardon 2023-12-23 18:33:12 +01:00
parent 28ed1ba9bd
commit ee5bf48f7d
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
man/veritytab.xml
View file

@ -41,17 +41,17 @@ This is based on crypttab(5).
verity protected block device. Fields are delimited by
white space.</para>
<para>Each line is in the form<programlisting><replaceable>volume-name</replaceable> <replaceable>data-device</replaceable> <replaceable>hash-device</replaceable> <replaceable>roothash</replaceable> <replaceable>options</replaceable></programlisting>
<para>Each line is in the form<programlisting><replaceable>volume-name</replaceable> <replaceable>data-device</replaceable> <replaceable>hash-device</replaceable> <replaceable>roothash</replaceable> <optional><replaceable>options</replaceable></optional></programlisting>
The first four fields are mandatory, the remaining one is optional.</para>
<para>The first field contains the name of the resulting verity volume; its block device is set up
below <filename>/dev/mapper/</filename>.</para>
<para>The second field contains a path to the underlying block data device, or a specification of a block device via
<varname>UUID=</varname> followed by the UUID.</para>
<varname>UUID=</varname> followed by the <replaceable>UUID</replaceable>.</para>
<para>The third field contains a path to the underlying block hash device, or a specification of a block device via
<varname>UUID=</varname> followed by the UUID.</para>
<varname>UUID=</varname> followed by the <replaceable>UUID</replaceable>.</para>
<para>The fourth field is the <replaceable>roothash</replaceable> in hexadecimal.</para>
@ -71,7 +71,7 @@ This is based on crypttab(5).
<varlistentry>
<term><option>format=<replaceable>NUMBER</replaceable></option></term>
<listitem><para>Specifies the hash version type. Format type 0 is original Chrome OS version. Format type 1 is
<listitem><para>Specifies the hash version type. Format type <literal>0</literal> is original Chrome OS version. Format type <literal>1</literal> is
modern version.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
@ -125,8 +125,8 @@ This is based on crypttab(5).
<varlistentry>
<term><option>uuid=<replaceable>UUID</replaceable></option></term>
<listitem><para>Use the provided UUID for format command instead of generating new one. The UUID must be
provided in standard UUID format, e.g. 12345678-1234-1234-1234-123456789abc.</para>
<listitem><para>Use the provided <replaceable>UUID</replaceable> for format command instead of generating new one. The <replaceable>UUID</replaceable> must be
provided in standard <acronym>UUID</acronym> format, e.g. <literal>12345678-1234-1234-1234-123456789abc</literal>.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
@ -137,7 +137,7 @@ This is based on crypttab(5).
<term><option>panic-on-corruption</option></term>
<listitem><para>Defines what to do if a data verity problem is detected (data corruption). Without these
options kernel fails the IO operation with I/O error. With <option>--ignore-corruption</option> option the
options kernel fails the <acronym>IO</acronym> operation with <acronym>I/O</acronym> error. With <option>--ignore-corruption</option> option the
corruption is only logged. With <option>--restart-on-corruption</option> or
<option>--panic-on-corruption</option> the kernel is restarted (panicked) immediately.
@ -183,7 +183,7 @@ This is based on crypttab(5).
<varlistentry>
<term><option>fec-device=<replaceable>PATH</replaceable></option></term>
<listitem><para>Use forward error correction (FEC) to recover from corruption if hash verification fails. Use
<listitem><para>Use forward error correction (<acronym>FEC</acronym>) to recover from corruption if hash verification fails. Use
encoding data from the specified device. The fec device argument can be block device or file image. For format,
if fec device path doesn't exist, it will be created as file. Note: block sizes for data and hash devices must
match. Also, if the verity data_device is encrypted the fec_device should be too.</para>
@ -194,7 +194,7 @@ This is based on crypttab(5).
<varlistentry>
<term><option>fec-offset=<replaceable>BYTES</replaceable></option></term>
<listitem><para>This is the offset, in bytes, from the start of the FEC device to the beginning of the encoding
<listitem><para>This is the offset, in bytes, from the start of the <acronym>FEC</acronym> device to the beginning of the encoding
data. (Aligned on 512 bytes.)</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>