]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd-nspawn.xml
os-release: define /usr/lib/os-release as fallback for /etc/os-release
[thirdparty/systemd.git] / man / systemd-nspawn.xml
1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4
5 <!--
6 This file is part of systemd.
7
8 Copyright 2010 Lennart Poettering
9
10 systemd is free software; you can redistribute it and/or modify it
11 under the terms of the GNU Lesser General Public License as published by
12 the Free Software Foundation; either version 2.1 of the License, or
13 (at your option) any later version.
14
15 systemd is distributed in the hope that it will be useful, but
16 WITHOUT ANY WARRANTY; without even the implied warranty of
17 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
18 Lesser General Public License for more details.
19
20 You should have received a copy of the GNU Lesser General Public License
21 along with systemd; If not, see <http://www.gnu.org/licenses/>.
22 -->
23
24 <refentry id="systemd-nspawn"
25 xmlns:xi="http://www.w3.org/2001/XInclude">
26
27 <refentryinfo>
28 <title>systemd-nspawn</title>
29 <productname>systemd</productname>
30
31 <authorgroup>
32 <author>
33 <contrib>Developer</contrib>
34 <firstname>Lennart</firstname>
35 <surname>Poettering</surname>
36 <email>lennart@poettering.net</email>
37 </author>
38 </authorgroup>
39 </refentryinfo>
40
41 <refmeta>
42 <refentrytitle>systemd-nspawn</refentrytitle>
43 <manvolnum>1</manvolnum>
44 </refmeta>
45
46 <refnamediv>
47 <refname>systemd-nspawn</refname>
48 <refpurpose>Spawn a namespace container for debugging, testing and building</refpurpose>
49 </refnamediv>
50
51 <refsynopsisdiv>
52 <cmdsynopsis>
53 <command>systemd-nspawn</command>
54 <arg choice="opt" rep="repeat">OPTIONS</arg>
55 <arg choice="opt"><replaceable>COMMAND</replaceable>
56 <arg choice="opt" rep="repeat">ARGS</arg>
57 </arg>
58 </cmdsynopsis>
59 <cmdsynopsis>
60 <command>systemd-nspawn</command>
61 <arg choice="plain">-b</arg>
62 <arg choice="opt" rep="repeat">OPTIONS</arg>
63 <arg choice="opt" rep="repeat">ARGS</arg>
64 </cmdsynopsis>
65 </refsynopsisdiv>
66
67 <refsect1>
68 <title>Description</title>
69
70 <para><command>systemd-nspawn</command> may be used to
71 run a command or OS in a light-weight namespace
72 container. In many ways it is similar to
73 <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
74 but more powerful since it fully virtualizes the file
75 system hierarchy, as well as the process tree, the
76 various IPC subsystems and the host and domain
77 name.</para>
78
79 <para><command>systemd-nspawn</command> limits access
80 to various kernel interfaces in the container to
81 read-only, such as <filename>/sys</filename>,
82 <filename>/proc/sys</filename> or
83 <filename>/sys/fs/selinux</filename>. Network
84 interfaces and the system clock may not be changed
85 from within the container. Device nodes may not be
86 created. The host system cannot be rebooted and kernel
87 modules may not be loaded from within the
88 container.</para>
89
90 <para>Note that even though these security precautions
91 are taken <command>systemd-nspawn</command> is not
92 suitable for secure container setups. Many of the
93 security features may be circumvented and are hence
94 primarily useful to avoid accidental changes to the
95 host system from the container. The intended use of
96 this program is debugging and testing as well as
97 building of packages, distributions and software
98 involved with boot and systems management.</para>
99
100 <para>In contrast to
101 <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry> <command>systemd-nspawn</command>
102 may be used to boot full Linux-based operating systems
103 in a container.</para>
104
105 <para>Use a tool like
106 <citerefentry><refentrytitle>yum</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
107 <citerefentry><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
108 or
109 <citerefentry><refentrytitle>pacman</refentrytitle><manvolnum>8</manvolnum></citerefentry>
110 to set up an OS directory tree suitable as file system
111 hierarchy for <command>systemd-nspawn</command>
112 containers.</para>
113
114 <para>Note that <command>systemd-nspawn</command> will
115 mount file systems private to the container to
116 <filename>/dev</filename>,
117 <filename>/run</filename> and similar. These will
118 not be visible outside of the container, and their
119 contents will be lost when the container exits.</para>
120
121 <para>Note that running two
122 <command>systemd-nspawn</command> containers from the
123 same directory tree will not make processes in them
124 see each other. The PID namespace separation of the
125 two containers is complete and the containers will
126 share very few runtime objects except for the
127 underlying file system. Use
128 <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
129 <command>login</command> command to request an
130 additional login prompt in a running container.</para>
131
132 <para><command>systemd-nspawn</command> implements the
133 <ulink
134 url="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container
135 Interface</ulink> specification.</para>
136
137 <para>As a safety check
138 <command>systemd-nspawn</command> will verify the
139 existence of <filename>/usr/lib/os-release</filename>
140 or <filename>/etc/os-release</filename> in the
141 container tree before starting the container (see
142 <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>). It
143 might be necessary to add this file to the container
144 tree manually if the OS of the container is too old to
145 contain this file out-of-the-box.</para>
146 </refsect1>
147
148 <refsect1>
149 <title>Options</title>
150
151 <para>If option <option>-b</option> is specified, the
152 arguments are used as arguments for the init
153 binary. Otherwise, <replaceable>COMMAND</replaceable>
154 specifies the program to launch in the container, and
155 the remaining arguments are used as arguments for this
156 program. If <option>-b</option> is not used and no
157 arguments are specifed, a shell is launched in the
158 container.</para>
159
160 <para>The following options are understood:</para>
161
162 <variablelist>
163 <varlistentry>
164 <term><option>-D</option></term>
165 <term><option>--directory=</option></term>
166
167 <listitem><para>Directory to use as
168 file system root for the container. If
169 neither <option>--directory=</option>
170 nor <option>--image=</option> are
171 specified, the current directory will
172 be used. May not be specified together with
173 <option>--image=</option>.</para></listitem>
174 </varlistentry>
175
176 <varlistentry>
177 <term><option>-i</option></term>
178 <term><option>--image=</option></term>
179
180 <listitem><para>Disk image to mount
181 the root directory for the container
182 from. Takes a path to a regular file
183 or to a block device node. The file or
184 block device must contain a GUID
185 Partition Table with a root partition
186 which is mounted as the root directory
187 of the container. Optionally, it may
188 contain a home and/or a server data
189 partition which are mounted to the
190 appropriate places in the
191 container. All these partitions must
192 be identified by the partition types
193 defined by the <ulink
194 url="http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/">Discoverable
195 Partitions Specification</ulink>. Any
196 other partitions, such as foreign
197 partitions, swap partitions or EFI
198 system partitions are not mounted. May
199 not be specified together with
200 <option>--directory=</option>.</para></listitem>
201 </varlistentry>
202
203 <varlistentry>
204 <term><option>-b</option></term>
205 <term><option>--boot</option></term>
206
207 <listitem><para>Automatically search
208 for an init binary and invoke it
209 instead of a shell or a user supplied
210 program. If this option is used,
211 arguments specified on the command
212 line are used as arguments for the
213 init binary. This option may not be
214 combined with
215 <option>--share-system</option>.
216 </para></listitem>
217 </varlistentry>
218
219 <varlistentry>
220 <term><option>-u</option></term>
221 <term><option>--user=</option></term>
222
223 <listitem><para>After transitioning
224 into the container, change to the
225 specified user-defined in the
226 container's user database. Like all
227 other systemd-nspawn features, this is
228 not a security feature and provides
229 protection against accidental
230 destructive operations
231 only.</para></listitem>
232 </varlistentry>
233
234 <varlistentry>
235 <term><option>-M</option></term>
236 <term><option>--machine=</option></term>
237
238 <listitem><para>Sets the machine name
239 for this container. This name may be
240 used to identify this container on the
241 host, and is used to initialize the
242 container's hostname (which the
243 container can choose to override,
244 however). If not specified, the last
245 component of the root directory of the
246 container is used.</para></listitem>
247 </varlistentry>
248
249 <varlistentry>
250 <term><option>--uuid=</option></term>
251
252 <listitem><para>Set the specified UUID
253 for the container. The init system
254 will initialize
255 <filename>/etc/machine-id</filename>
256 from this if this file is not set yet.
257 </para></listitem>
258 </varlistentry>
259
260 <varlistentry>
261 <term><option>--slice=</option></term>
262
263 <listitem><para>Make the container
264 part of the specified slice, instead
265 of the default
266 <filename>machine.slice</filename>.</para>
267 </listitem>
268 </varlistentry>
269
270 <varlistentry>
271 <term><option>--private-network</option></term>
272
273 <listitem><para>Disconnect networking
274 of the container from the host. This
275 makes all network interfaces
276 unavailable in the container, with the
277 exception of the loopback device and
278 those specified with
279 <option>--network-interface=</option>
280 and configured with
281 <option>--network-veth</option>. If
282 this option is specified, the
283 CAP_NET_ADMIN capability will be added
284 to the set of capabilities the
285 container retains. The latter may be
286 disabled by using
287 <option>--drop-capability=</option>.</para></listitem>
288 </varlistentry>
289
290 <varlistentry>
291 <term><option>--network-interface=</option></term>
292
293 <listitem><para>Assign the specified
294 network interface to the
295 container. This will remove the
296 specified interface from the calling
297 namespace and place it in the
298 container. When the container
299 terminates, it is moved back to the
300 host namespace. Note that
301 <option>--network-interface=</option>
302 implies
303 <option>--private-network</option>. This
304 option may be used more than once to
305 add multiple network interfaces to the
306 container.</para></listitem>
307 </varlistentry>
308
309 <varlistentry>
310 <term><option>--network-macvlan=</option></term>
311
312 <listitem><para>Create a
313 <literal>macvlan</literal> interface
314 of the specified Ethernet network
315 interface and add it to the
316 container. A
317 <literal>macvlan</literal> interface
318 is a virtual interface that adds a
319 second MAC address to an existing
320 physical Ethernet link. The interface
321 in the container will be named after
322 the interface on the host, prefixed
323 with <literal>mv-</literal>. Note that
324 <option>--network-macvlan=</option>
325 implies
326 <option>--private-network</option>. This
327 option may be used more than once to
328 add multiple network interfaces to the
329 container.</para></listitem>
330 </varlistentry>
331
332 <varlistentry>
333 <term><option>--network-veth</option></term>
334
335 <listitem><para>Create a virtual
336 Ethernet link
337 (<literal>veth</literal>) between host
338 and container. The host side of the
339 Ethernet link will be available as a
340 network interface named after the
341 container's name (as specified with
342 <option>--machine=</option>), prefixed
343 with <literal>ve-</literal>. The
344 container side of the Ethernet
345 link will be named
346 <literal>host0</literal>. Note that
347 <option>--network-veth</option>
348 implies
349 <option>--private-network</option>.</para></listitem>
350 </varlistentry>
351
352 <varlistentry>
353 <term><option>--network-bridge=</option></term>
354
355 <listitem><para>Adds the host side of
356 the Ethernet link created with
357 <option>--network-veth</option> to the
358 specified bridge. Note that
359 <option>--network-bridge=</option>
360 implies
361 <option>--network-veth</option>. If
362 this option is used, the host side of
363 the Ethernet link will use the
364 <literal>vb-</literal> prefix instead
365 of <literal>ve-</literal>.</para></listitem>
366 </varlistentry>
367
368 <varlistentry>
369 <term><option>-Z</option></term>
370 <term><option>--selinux-context=</option></term>
371
372 <listitem><para>Sets the SELinux
373 security context to be used to label
374 processes in the container.</para>
375 </listitem>
376 </varlistentry>
377
378 <varlistentry>
379 <term><option>-L</option></term>
380 <term><option>--selinux-apifs-context=</option></term>
381
382 <listitem><para>Sets the SELinux security
383 context to be used to label files in
384 the virtual API file systems in the
385 container.</para>
386 </listitem>
387 </varlistentry>
388
389 <varlistentry>
390 <term><option>--capability=</option></term>
391
392 <listitem><para>List one or more
393 additional capabilities to grant the
394 container. Takes a comma-separated
395 list of capability names, see
396 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
397 for more information. Note that the
398 following capabilities will be granted
399 in any way: CAP_CHOWN,
400 CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH,
401 CAP_FOWNER, CAP_FSETID, CAP_IPC_OWNER,
402 CAP_KILL, CAP_LEASE,
403 CAP_LINUX_IMMUTABLE,
404 CAP_NET_BIND_SERVICE,
405 CAP_NET_BROADCAST, CAP_NET_RAW,
406 CAP_SETGID, CAP_SETFCAP, CAP_SETPCAP,
407 CAP_SETUID, CAP_SYS_ADMIN,
408 CAP_SYS_CHROOT, CAP_SYS_NICE,
409 CAP_SYS_PTRACE, CAP_SYS_TTY_CONFIG,
410 CAP_SYS_RESOURCE, CAP_SYS_BOOT,
411 CAP_AUDIT_WRITE,
412 CAP_AUDIT_CONTROL. Also CAP_NET_ADMIN
413 is retained if
414 <option>--private-network</option> is
415 specified. If the special value
416 <literal>all</literal> is passed, all
417 capabilities are
418 retained.</para></listitem>
419 </varlistentry>
420
421 <varlistentry>
422 <term><option>--drop-capability=</option></term>
423
424 <listitem><para>Specify one or more
425 additional capabilities to drop for
426 the container. This allows running the
427 container with fewer capabilities than
428 the default (see above).</para></listitem>
429 </varlistentry>
430
431 <varlistentry>
432 <term><option>--link-journal=</option></term>
433
434 <listitem><para>Control whether the
435 container's journal shall be made
436 visible to the host system. If enabled,
437 allows viewing the container's journal
438 files from the host (but not vice
439 versa). Takes one of
440 <literal>no</literal>,
441 <literal>host</literal>,
442 <literal>guest</literal>,
443 <literal>auto</literal>. If
444 <literal>no</literal>, the journal is
445 not linked. If <literal>host</literal>,
446 the journal files are stored on the
447 host file system (beneath
448 <filename>/var/log/journal/<replaceable>machine-id</replaceable></filename>)
449 and the subdirectory is bind-mounted
450 into the container at the same
451 location. If <literal>guest</literal>,
452 the journal files are stored on the
453 guest file system (beneath
454 <filename>/var/log/journal/<replaceable>machine-id</replaceable></filename>)
455 and the subdirectory is symlinked into the host
456 at the same location. If
457 <literal>auto</literal> (the default),
458 and the right subdirectory of
459 <filename>/var/log/journal</filename>
460 exists, it will be bind mounted
461 into the container. If the
462 subdirectory does not exist, no
463 linking is performed. Effectively,
464 booting a container once with
465 <literal>guest</literal> or
466 <literal>host</literal> will link the
467 journal persistently if further on
468 the default of <literal>auto</literal>
469 is used.</para></listitem>
470 </varlistentry>
471
472 <varlistentry>
473 <term><option>-j</option></term>
474
475 <listitem><para>Equivalent to
476 <option>--link-journal=guest</option>.</para></listitem>
477 </varlistentry>
478
479 <varlistentry>
480 <term><option>--read-only</option></term>
481
482 <listitem><para>Mount the root file
483 system read-only for the
484 container.</para></listitem>
485 </varlistentry>
486
487 <varlistentry>
488 <term><option>--bind=</option></term>
489 <term><option>--bind-ro=</option></term>
490
491 <listitem><para>Bind mount a file or
492 directory from the host into the
493 container. Either takes a path
494 argument -- in which case the
495 specified path will be mounted from
496 the host to the same path in the
497 container --, or a colon-separated
498 pair of paths -- in which case the
499 first specified path is the source in
500 the host, and the second path is the
501 destination in the container. The
502 <option>--bind-ro=</option> option
503 creates read-only bind
504 mounts.</para></listitem>
505 </varlistentry>
506
507 <varlistentry>
508 <term><option>--tmpfs=</option></term>
509
510 <listitem><para>Mount a tmpfs file
511 system into the container. Takes a
512 single absolute path argument that
513 specifies where to mount the tmpfs
514 instance to (in which case the
515 directory access mode will be chosen
516 as 0755, owned by root/root), or
517 optionally a colon-separated pair of
518 path and mount option string, that is
519 used for mounting (in which case the
520 kernel default for access mode and
521 owner will be chosen, unless otherwise
522 specified). This option is
523 particularly useful for mounting
524 directories such as
525 <filename>/var</filename> as tmpfs, to
526 allow state-less systems, in
527 particular when combined with
528 <option>--read-only</option>.</para></listitem>
529 </varlistentry>
530
531 <varlistentry>
532 <term><option>--setenv=</option></term>
533
534 <listitem><para>Specifies an
535 environment variable assignment to
536 pass to the init process in the
537 container, in the format
538 <literal>NAME=VALUE</literal>. This
539 may be used to override the default
540 variables or to set additional
541 variables. This parameter may be used
542 more than once.</para></listitem>
543 </varlistentry>
544
545 <varlistentry>
546 <term><option>--share-system</option></term>
547
548 <listitem><para>Allows the container
549 to share certain system facilities
550 with the host. More specifically, this
551 turns off PID namespacing, UTS
552 namespacing and IPC namespacing, and
553 thus allows the guest to see and
554 interact more easily with processes
555 outside of the container. Note that
556 using this option makes it impossible
557 to start up a full Operating System in
558 the container, as an init system
559 cannot operate in this mode. It is
560 only useful to run specific programs
561 or applications this way, without
562 involving an init system in the
563 container. This option implies
564 <option>--register=no</option>. This
565 option may not be combined with
566 <option>--boot</option>.</para></listitem>
567 </varlistentry>
568
569 <varlistentry>
570 <term><option>--register=</option></term>
571
572 <listitem><para>Controls whether the
573 container is registered with
574 <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes
575 a boolean argument, defaults to
576 <literal>yes</literal>. This option
577 should be enabled when the container
578 runs a full Operating System (more
579 specifically: an init system), and is
580 useful to ensure that the container is
581 accessible via
582 <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
583 and shown by tools such as
584 <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If
585 the container does not run an init
586 system, it is recommended to set this
587 option to <literal>no</literal>. Note
588 that <option>--share-system</option>
589 implies
590 <option>--register=no</option>.
591 </para></listitem>
592 </varlistentry>
593
594 <varlistentry>
595 <term><option>--keep-unit</option></term>
596
597 <listitem><para>Instead of creating a
598 transient scope unit to run the
599 container in, simply register the
600 service or scope unit
601 <command>systemd-nspawn</command> has
602 been invoked in with
603 <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>. This
604 has no effect if
605 <option>--register=no</option> is
606 used. This switch should be used if
607 <command>systemd-nspawn</command> is
608 invoked from within a service unit,
609 and the service unit's sole purpose
610 is to run a single
611 <command>systemd-nspawn</command>
612 container. This option is not
613 available if run from a user
614 session.</para></listitem>
615 </varlistentry>
616
617 <varlistentry>
618 <term><option>--personality=</option></term>
619
620 <listitem><para>Control the
621 architecture ("personality") reported
622 by
623 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
624 in the container. Currently, only
625 <literal>x86</literal> and
626 <literal>x86-64</literal> are
627 supported. This is useful when running
628 a 32-bit container on a 64-bit
629 host. If this setting is not used,
630 the personality reported in the
631 container is the same as the one
632 reported on the
633 host.</para></listitem>
634 </varlistentry>
635
636 <varlistentry>
637 <term><option>-q</option></term>
638 <term><option>--quiet</option></term>
639
640 <listitem><para>Turns off any status
641 output by the tool itself. When this
642 switch is used, the only output
643 from nspawn will be the console output
644 of the container OS itself.</para></listitem>
645 </varlistentry>
646
647 <xi:include href="standard-options.xml" xpointer="help" />
648 <xi:include href="standard-options.xml" xpointer="version" />
649 </variablelist>
650
651 </refsect1>
652
653 <refsect1>
654 <title>Example 1</title>
655
656 <programlisting># yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal
657 # systemd-nspawn -bD /srv/mycontainer</programlisting>
658
659 <para>This installs a minimal Fedora distribution into
660 the directory <filename noindex='true'>/srv/mycontainer/</filename> and
661 then boots an OS in a namespace container in
662 it.</para>
663 </refsect1>
664
665 <refsect1>
666 <title>Example 2</title>
667
668 <programlisting># debootstrap --arch=amd64 unstable ~/debian-tree/
669 # systemd-nspawn -D ~/debian-tree/</programlisting>
670
671 <para>This installs a minimal Debian unstable
672 distribution into the directory
673 <filename>~/debian-tree/</filename> and then spawns a
674 shell in a namespace container in it.</para>
675 </refsect1>
676
677 <refsect1>
678 <title>Example 3</title>
679
680 <programlisting># pacstrap -c -d ~/arch-tree/ base
681 # systemd-nspawn -bD ~/arch-tree/</programlisting>
682
683 <para>This installs a mimimal Arch Linux distribution into
684 the directory <filename>~/arch-tree/</filename> and then
685 boots an OS in a namespace container in it.</para>
686 </refsect1>
687
688 <refsect1>
689 <title>Example 4</title>
690
691 <programlisting># mv ~/arch-tree /var/lib/container/arch
692 # systemctl enable systemd-nspawn@arch.service
693 # systemctl start systemd-nspawn@arch.service</programlisting>
694
695 <para>This makes the Arch Linux container part of the
696 <filename>multi-user.target</filename> on the host.
697 </para>
698 </refsect1>
699
700 <refsect1>
701 <title>Example 5</title>
702
703 <programlisting># btrfs subvolume snapshot / /.tmp
704 # systemd-nspawn --private-network -D /.tmp -b</programlisting>
705
706 <para>This runs a copy of the host system in a
707 btrfs snapshot.</para>
708 </refsect1>
709
710 <refsect1>
711 <title>Example 6</title>
712
713 <programlisting># chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container
714 # systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh</programlisting>
715
716 <para>This runs a container with SELinux sandbox security contexts.</para>
717 </refsect1>
718
719 <refsect1>
720 <title>Exit status</title>
721
722 <para>The exit code of the program executed in the
723 container is returned.</para>
724 </refsect1>
725
726 <refsect1>
727 <title>See Also</title>
728 <para>
729 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
730 <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
731 <citerefentry><refentrytitle>yum</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
732 <citerefentry><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
733 <citerefentry><refentrytitle>pacman</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
734 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
735 <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
736 </para>
737 </refsect1>
738
739 </refentry>