mirror of
https://github.com/systemd/systemd
synced 2024-09-06 16:56:43 +00:00
![Zbigniew Jędrzejewski-Szmek](/assets/img/avatar_default.png)
Fixes #22974. The text is reworded a bit too. In particular, it's "partitions" that are not reordered, not "partition table slots". If we were reordering things, we'd move the partitions between slots. The slots themselves are not moveable.
428 lines
25 KiB
XML
428 lines
25 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-repart" conditional='ENABLE_REPART'
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<refentryinfo>
|
|
<title>systemd-repart</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd-repart</refentrytitle>
|
|
<manvolnum>8</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd-repart</refname>
|
|
<refname>systemd-repart.service</refname>
|
|
<refpurpose>Automatically grow and add partitions</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>systemd-repart</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="opt" rep="repeat"><replaceable><optional>BLOCKDEVICE</optional></replaceable></arg>
|
|
</cmdsynopsis>
|
|
|
|
<para><filename>systemd-repart.service</filename></para>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><command>systemd-repart</command> grows and adds partitions to a partition table, based on the
|
|
configuration files described in
|
|
<citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
</para>
|
|
|
|
<para>If invoked with no arguments, it operates on the block device backing the root file system
|
|
partition of the running OS, thus growing and adding partitions of the booted OS image itself. If
|
|
<varname>--image=</varname> is used it will operate on the specified image file. When called in the
|
|
initrd it operates on the block device backing <filename>/sysroot/</filename> instead, i.e. on the block
|
|
device the system will soon transition into. The <filename>systemd-repart.service</filename> service is
|
|
generally run at boot in the initrd, in order to augment the partition table of the OS before its
|
|
partitions are mounted. <command>systemd-repart</command> (mostly) operates in a purely incremental mode:
|
|
it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions.
|
|
The service is intended to be run on every boot, but when it detects that the partition table already
|
|
matches the installed <filename>repart.d/*.conf</filename> configuration files, it executes no
|
|
operation.</para>
|
|
|
|
<para><command>systemd-repart</command> is intended to be used when deploying OS images, to automatically
|
|
adjust them to the system they are running on, during first boot. This way the deployed image can be
|
|
minimal in size and may be augmented automatically at boot when needed, taking possession of disk space
|
|
available but not yet used. Specifically the following use cases are among those covered:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>The root partition may be grown to cover the whole available disk space.</para></listitem>
|
|
<listitem><para>A <filename>/home/</filename>, swap or <filename>/srv/</filename> partition can be
|
|
added.</para></listitem>
|
|
<listitem><para>A second (or third, …) root partition may be added, to cover A/B style setups
|
|
where a second version of the root file system is alternatingly used for implementing update
|
|
schemes. The deployed image would carry only a single partition ("A") but on first boot a second
|
|
partition ("B") for this purpose is automatically created.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The algorithm executed by <command>systemd-repart</command> is roughly as follows:</para>
|
|
|
|
<orderedlist>
|
|
<listitem><para>The <filename>repart.d/*.conf</filename> configuration files are loaded and parsed,
|
|
and ordered by filename (without the directory prefix). For each configuration file,
|
|
drop-in files are looked for in directories with same name as the configuration file
|
|
with a suffix ".d" added.</para></listitem>
|
|
|
|
<listitem><para>The partition table already existing on the block device is loaded and
|
|
parsed.</para></listitem>
|
|
|
|
<listitem><para>The existing partitions in the partition table are matched up with the
|
|
<filename>repart.d/*.conf</filename> files by GPT partition type UUID. The first existing partition
|
|
of a specific type is assigned the first configuration file declaring the same type. The second
|
|
existing partition of a specific type is then assigned the second configuration file declaring the same
|
|
type, and so on. After this iterative assigning is complete any left-over existing partitions that have
|
|
no matching configuration file are considered "foreign" and left as they are. And any configuration
|
|
files for which no partition currently exists are understood as a request to create such a partition.
|
|
</para></listitem>
|
|
|
|
<listitem><para>Partitions that shall be created are now allocated on the disk, taking the size
|
|
constraints and weights declared in the configuration files into account. Free space is used within the
|
|
limits set by size and padding requests. In addition, existing partitions that should be grown are
|
|
grown. New partitions are always appended to the end of the partition table, taking the first partition
|
|
table slot whose index is greater than the indexes of all existing partitions. Partitions are never
|
|
reordered and thus partition numbers remain stable. When partitions are created, they are placed in the
|
|
smallest area of free space that is large enough to satisfy the size and padding limits. This means
|
|
that partitions might have different order on disk than in the parition table. Note that this
|
|
allocation happens in memory only, the partition table on disk is not updated yet.</para></listitem>
|
|
|
|
<listitem><para>All existing partitions for which configuration files exist and which currently have no
|
|
GPT partition label set will be assigned a label, either explicitly configured in the configuration or
|
|
— if that's missing — derived automatically from the partition type. The same is done for all
|
|
partitions that are newly created. These assignments are done in memory only, too, the disk is not
|
|
updated yet.</para></listitem>
|
|
|
|
<listitem><para>Similarly, all existing partitions for which configuration files exist and which
|
|
currently have an all-zero identifying UUID will be assigned a new UUID. This UUID is cryptographically
|
|
hashed from a common seed value together with the partition type UUID (and a counter in case multiple
|
|
partitions of the same type are defined), see below. The same is done for all partitions that are
|
|
created anew. These assignments are done in memory only, too, the disk is not updated yet.
|
|
</para></listitem>
|
|
|
|
<listitem><para>Similarly, if the disk's volume UUID is all zeroes it is also initialized, also
|
|
cryptographically hashed from the same common seed value. This is done in memory only too.
|
|
</para></listitem>
|
|
|
|
<listitem><para>The disk space assigned to new partitions (i.e. what was previously free space) is now
|
|
erased. Specifically, all file system signatures are removed, and if the device supports it, the
|
|
<constant>BLKDISCARD</constant> I/O control command is issued to inform the hardware that the space is
|
|
now empty. In addition any "padding" between partitions and at the end of the device is similarly
|
|
erased.</para></listitem>
|
|
|
|
<listitem><para>The new partition table is finally written to disk. The kernel is asked to reread the
|
|
partition table.</para></listitem>
|
|
</orderedlist>
|
|
|
|
<para>As exception to the normally strictly incremental operation, when called in a special "factory
|
|
reset" mode, <command>systemd-repart</command> may also be used to erase existing partitions to
|
|
reset an installation back to vendor defaults. This mode of operation is used when either the
|
|
<option>--factory-reset=yes</option> switch is passed on the tool's command line, or the
|
|
<option>systemd.factory_reset=yes</option> option specified on the kernel command line, or the
|
|
<varname>FactoryReset</varname> EFI variable (vendor UUID
|
|
<constant>8cf2644b-4b0b-428f-9387-6d876050dc67</constant>) is set to "yes". It alters the algorithm above
|
|
slightly: between the 3rd and the 4th step above any partition marked explicitly via the
|
|
<varname>FactoryReset=</varname> boolean is deleted, and the algorithm restarted, thus immediately
|
|
re-creating these partitions anew empty.</para>
|
|
|
|
<para>Note that <command>systemd-repart</command> only changes partition tables, it does not create or
|
|
resize any file systems within these partitions. A separate mechanism should be used for that, for
|
|
example
|
|
<citerefentry><refentrytitle>systemd-growfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> and
|
|
<command>systemd-makefs</command>.</para>
|
|
|
|
<para>The UUIDs identifying the new partitions created (or assigned to existing partitions that have no
|
|
UUID yet), as well as the disk as a whole are hashed cryptographically from a common seed value. This
|
|
seed value is usually the
|
|
<citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> of the
|
|
system, so that the machine ID reproducibly determines the UUIDs assigned to all partitions. If the
|
|
machine ID cannot be read (or the user passes <option>--seed=random</option>, see below) the seed is
|
|
generated randomly instead, so that the partition UUIDs are also effectively random. The seed value may
|
|
also be set explicitly, formatted as UUID via the <option>--seed=</option> option. By hashing these UUIDs
|
|
from a common seed images prepared with this tool become reproducible and the result of the algorithm
|
|
above deterministic.</para>
|
|
|
|
<para>The positional argument should specify the block device to operate on. Instead of a block device
|
|
node path a regular file may be specified too, in which case the command operates on it like it would if
|
|
a loopback block device node was specified with the file attached. If <option>--empty=create</option> is
|
|
specified the specified path is created as regular file, which is useful for generating disk images from
|
|
scratch.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
|
|
<para>The following options are understood:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>--dry-run=</option></term>
|
|
<listitem><para>Takes a boolean. If this switch is not specified <option>--dry-run=yes</option> is
|
|
the implied default. Controls whether <filename>systemd-repart</filename> executes the requested
|
|
re-partition operations or whether it should only show what it would do. Unless
|
|
<option>--dry-run=no</option> is specified <filename>systemd-repart</filename> will not actually
|
|
touch the device's partition table.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--empty=</option></term>
|
|
<listitem><para>Takes one of <literal>refuse</literal>, <literal>allow</literal>,
|
|
<literal>require</literal>, <literal>force</literal> or <literal>create</literal>. Controls how to
|
|
operate on block devices that are entirely empty, i.e. carry no partition table/disk label yet. If
|
|
this switch is not specified the implied default is <literal>refuse</literal>.</para>
|
|
|
|
<para>If <literal>refuse</literal> <command>systemd-repart</command> requires that the block device
|
|
it shall operate on already carries a partition table and refuses operation if none is found. If
|
|
<literal>allow</literal> the command will extend an existing partition table or create a new one if
|
|
none exists. If <literal>require</literal> the command will create a new partition table if none
|
|
exists so far, and refuse operation if one already exists. If <literal>force</literal> it will create
|
|
a fresh partition table unconditionally, erasing the disk fully in effect. If
|
|
<literal>force</literal> no existing partitions will be taken into account or survive the
|
|
operation. Hence: use with care, this is a great way to lose all your data. If
|
|
<literal>create</literal> a new loopback file is create under the path passed via the device node
|
|
parameter, of the size indicated with <option>--size=</option>, see below.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--discard=</option></term>
|
|
|
|
<listitem><para>Takes a boolean. If this switch is not specified <option>--discard=yes</option> is
|
|
the implied default. Controls whether to issue the <constant>BLKDISCARD</constant> I/O control
|
|
command on the space taken up by any added partitions or on the space in between them. Usually, it's
|
|
a good idea to issue this request since it tells the underlying hardware that the covered blocks
|
|
shall be considered empty, improving performance. If operating on a regular file instead of a block
|
|
device node, a sparse file is generated.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--size=</option></term>
|
|
|
|
<listitem><para>Takes a size in bytes, using the usual K, M, G, T suffixes, or the special value
|
|
<literal>auto</literal>. If used the specified device node path must refer to a regular file, which
|
|
is then grown to the specified size if smaller, before any change is made to the partition table. If
|
|
specified as <literal>auto</literal> the minimal size for the disk image is automatically determined
|
|
(i.e. the minimal sizes of all partitions are summed up, taking space for additional metadata into
|
|
account). This switch is not supported if the specified node is a block device. This switch has no
|
|
effect if the file is already as large as the specified size or larger. The specified size is
|
|
implicitly rounded up to multiples of 4096. When used with <option>--empty=create</option> this
|
|
specifies the initial size of the loopback file to create.</para>
|
|
|
|
<para>The <option>--size=auto</option> option takes the sizes of pre-existing partitions into
|
|
account. However, it does not accommodate for partition tables that are not tightly packed: the
|
|
configured partitions might still not fit into the backing device if empty space exists between
|
|
pre-existing partitions (or before the first partition) that cannot be fully filled by partitions to
|
|
grow or create.</para>
|
|
|
|
<para>Also note that the automatic size determination does not take files or directories specified
|
|
with <option>CopyFiles=</option> into account: operation might fail if the specified files or
|
|
directories require more disk space then the configured per-partition minimal size
|
|
limit.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--factory-reset=</option></term>
|
|
|
|
<listitem><para>Takes boolean. If this switch is not specified <option>--factory=reset=no</option> is
|
|
the implied default. Controls whether to operate in "factory reset" mode, see above. If set to true
|
|
this will remove all existing partitions marked with <varname>FactoryReset=</varname> set to yes
|
|
early while executing the re-partitioning algorithm. Use with care, this is a great way to lose all
|
|
your data. Note that partition files need to explicitly turn <varname>FactoryReset=</varname> on, as
|
|
the option defaults to off. If no partitions are marked for factory reset this switch has no
|
|
effect. Note that there are two other methods to request factory reset operation: via the kernel
|
|
command line and via an EFI variable, see above.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--can-factory-reset</option></term>
|
|
|
|
<listitem><para>If this switch is specified the disk is not re-partitioned. Instead it is determined
|
|
if any existing partitions are marked with <varname>FactoryReset=</varname>. If there are the tool
|
|
will exit with exit status zero, otherwise non-zero. This switch may be used to quickly determine
|
|
whether the running system supports a factory reset mechanism built on
|
|
<command>systemd-repart</command>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--root=</option></term>
|
|
|
|
<listitem><para>Takes a path to a directory to use as root file system when searching for
|
|
<filename>repart.d/*.conf</filename> files, for the machine ID file to use as seed and for the
|
|
<varname>CopyFiles=</varname> and <varname>CopyBlocks=</varname> source files and directories. By
|
|
default when invoked on the regular system this defaults to the host's root file system
|
|
<filename>/</filename>. If invoked from the initrd this defaults to <filename>/sysroot/</filename>,
|
|
so that the tool operates on the configuration and machine ID stored in the root file system later
|
|
transitioned into itself.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--image=</option></term>
|
|
|
|
<listitem><para>Takes a path to a disk image file or device to mount and use in a similar fashion to
|
|
<option>--root=</option>, see above.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="standard-options.xml" xpointer="image-policy-open" />
|
|
|
|
<varlistentry>
|
|
<term><option>--seed=</option></term>
|
|
|
|
<listitem><para>Takes a UUID as argument or the special value <constant>random</constant>. If a UUID
|
|
is specified the UUIDs to assign to partitions and the partition table itself are derived via
|
|
cryptographic hashing from it. If not specified it is attempted to read the machine ID from the host
|
|
(or more precisely, the root directory configured via <option>--root=</option>) and use it as seed
|
|
instead, falling back to a randomized seed otherwise. Use <option>--seed=random</option> to force a
|
|
randomized seed. Explicitly specifying the seed may be used to generated strictly reproducible
|
|
partition tables.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--pretty=</option></term>
|
|
|
|
<listitem><para>Takes a boolean argument. If this switch is not specified, it defaults to on when
|
|
called from an interactive terminal and off otherwise. Controls whether to show a user friendly table
|
|
and graphic illustrating the changes applied.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--definitions=</option></term>
|
|
|
|
<listitem><para>Takes a file system path. If specified the <filename>*.conf</filename> files are read
|
|
from the specified directory instead of searching in <filename>/usr/lib/repart.d/*.conf</filename>,
|
|
<filename>/etc/repart.d/*.conf</filename>,
|
|
<filename>/run/repart.d/*.conf</filename>.</para>
|
|
|
|
<para>This parameter can be specified multiple times.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--key-file=</option></term>
|
|
|
|
<listitem><para>Takes a file system path. Configures the encryption key to use when setting up LUKS2
|
|
volumes configured with the <varname>Encrypt=key-file</varname> setting in partition files. Should
|
|
refer to a regular file containing the key, or an <constant>AF_UNIX</constant> stream socket in the
|
|
file system. In the latter case a connection is made to it and the key read from it. If this switch
|
|
is not specified the empty key (i.e. zero length key) is used. This behaviour is useful for setting
|
|
up encrypted partitions during early first boot that receive their user-supplied password only in a
|
|
later setup step.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--private-key=</option></term>
|
|
|
|
<listitem><para>Takes a file system path. Configures the signing key to use when creating verity
|
|
signature partitions with the <varname>Verity=signature</varname> setting in partition files.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--certificate=</option></term>
|
|
|
|
<listitem><para>Takes a file system path. Configures the PEM encoded X.509 certificate to use when
|
|
creating verity signature partitions with the <varname>Verity=signature</varname> setting in
|
|
partition files.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--tpm2-device=</option></term>
|
|
<term><option>--tpm2-pcrs=</option></term>
|
|
|
|
<listitem><para>Configures the TPM2 device and list of PCRs to use for LUKS2 volumes configured with
|
|
the <varname>Encrypt=tpm2</varname> option. These options take the same parameters as the identically
|
|
named options to
|
|
<citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
and have the same effect on partitions where TPM2 enrollment is requested.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--tpm2-public-key=</option><arg>PATH</arg></term>
|
|
<term><option>--tpm2-public-key-pcrs=</option><arg rep="repeat">PCR</arg></term>
|
|
|
|
<listitem><para>Configures a TPM2 signed PCR policy to bind encryption to. See
|
|
<citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
for details on these two options.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--split=</option><arg>BOOL</arg></term>
|
|
|
|
<listitem><para>Enables generation of split artifacts from partitions configured with
|
|
<varname>SplitName=</varname>. If enabled, for each partition with <varname>SplitName=</varname> set,
|
|
a separate output file containing just the contents of that partition is generated. The output
|
|
filename consists of the loopback filename suffixed with the name configured with
|
|
<varname>SplitName=</varname>. If the loopback filename ends with <literal>.raw</literal>, the suffix
|
|
is inserted before the <literal>.raw</literal> extension instead.</para>
|
|
|
|
<para>Note that <option>--split</option> is independent from <option>--dry-run</option>. Even if
|
|
<option>--dry-run</option> is enabled, split artifacts will still be generated from an existing image
|
|
if <option>--split</option> is enabled.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--include-partitions=</option><arg rep="repeat">PARTITION</arg></term>
|
|
<term><option>--exclude-partitions=</option><arg rep="repeat">PARTITION</arg></term>
|
|
|
|
<listitem><para>These options specify which partition types <command>systemd-repart</command> should
|
|
operate on. If <option>--include-partitions=</option> is used, all partitions that aren't specified
|
|
are excluded. If <option>--exclude-partitions=</option> is used, all partitions that are specified
|
|
are excluded. Both options take a comma separated list of GPT partition type UUIDs or identifiers
|
|
(see <varname>Type=</varname> in
|
|
<citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--defer-partitions=</option><arg rep="repeat">PARTITION</arg></term>
|
|
|
|
<listitem><para>This option specifies for which partition types <command>systemd-repart</command>
|
|
should defer. All partitions that are deferred using this option are still taken into account when
|
|
calculating the sizes and offsets of other partitions, but aren't actually written to the disk image.
|
|
The net effect of this option is that if you run <command>systemd-repart</command> again without this
|
|
option, the missing partitions will be added as if they had not been deferred the first time
|
|
<command>systemd-repart</command> was executed.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--sector-size=</option><arg>BYTES</arg></term>
|
|
|
|
<listitem><para>This option allows configuring the sector size of the image produced by
|
|
<command>systemd-repart</command>. It takes a value that is a power of <literal>2</literal> between
|
|
<literal>512</literal> and <literal>4096</literal>. This option is useful when building images for
|
|
disks that use a different sector size as the disk on which the image is produced.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="standard-options.xml" xpointer="help" />
|
|
<xi:include href="standard-options.xml" xpointer="version" />
|
|
<xi:include href="standard-options.xml" xpointer="no-pager" />
|
|
<xi:include href="standard-options.xml" xpointer="no-legend" />
|
|
<xi:include href="standard-options.xml" xpointer="json" />
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Exit status</title>
|
|
|
|
<para>On success, 0 is returned, a non-zero failure code otherwise.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|