X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=man%2Fsystemd-nspawn.xml;h=aea50559f04f643e87ad6173390bc749f3a75663;hb=92daebc0d0268c35f416c1665e0da3d4be5dd69f;hp=d6687038af68467bc3adb42d210a71e889ca12bf;hpb=06c17c39a8345deef1ecff4dd5ef262f968c9be2;p=elogind.git
diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index d6687038a..aea50559f 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -70,7 +70,7 @@
systemd-nspawn may be used to
run a command or OS in a light-weight namespace
container. In many ways it is similar to
- chroot1,
+ chroot1,
but more powerful since it fully virtualizes the file
system hierarchy, as well as the process tree, the
various IPC subsystems and the host and domain
@@ -98,15 +98,15 @@
involved with boot and systems management.In contrast to
- chroot1Â systemd-nspawn
+ chroot1Â systemd-nspawn
may be used to boot full Linux-based operating systems
in a container.Use a tool like
- yum8,
- debootstrap8,
+ yum8,
+ debootstrap8,
or
- pacman8
+ pacman8
to set up an OS directory tree suitable as file system
hierarchy for systemd-nspawn
containers.
@@ -136,8 +136,9 @@
As a safety check
systemd-nspawn will verify the
- existence of /etc/os-release in
- the container tree before starting the container (see
+ existence of /usr/lib/os-release
+ or /etc/os-release in the
+ container tree before starting the container (see
os-release5). It
might be necessary to add this file to the container
tree manually if the OS of the container is too old to
@@ -392,7 +393,7 @@
additional capabilities to grant the
container. Takes a comma-separated
list of capability names, see
- capabilities7
+ capabilities7
for more information. Note that the
following capabilities will be granted
in any way: CAP_CHOWN,
@@ -580,7 +581,7 @@
accessible via
machinectl1
and shown by tools such as
- ps1. If
+ ps1. If
the container does not run an init
system, it is recommended to set this
option to no. Note
@@ -643,6 +644,49 @@
of the container OS itself.
+
+ =MODE
+
+ Boots the container in
+ volatile (ephemeral) mode. When no
+ mode parameter is passed or when mode
+ is specified as yes
+ full volatile mode is enabled. This
+ means the root directory is mounted as
+ mostly unpopulated
+ tmpfs instance, and
+ /usr from the OS
+ tree is mounted into it, read-only
+ (the system thus starts up with
+ read-only OS resources, but pristine
+ state and configuration, any changes
+ to the either are lost on
+ shutdown). When the mode parameter is
+ specified as state
+ the OS tree is mounted read-only, but
+ /var is mounted
+ as tmpfs instance
+ into it (the system thus starts up
+ with read-only OS resources and
+ configuration, but prestine state, any
+ changes to the latter are lost on
+ shutdown). When the mode parameter is
+ specified as no
+ (the default) the whole OS tree is made
+ available writable.
+
+ Note that setting this to
+ yes or
+ state will only
+ work correctly with operating systems
+ in the container that can boot up with
+ only /usr
+ mounted, and are able to populate
+ /var
+ automatically, as
+ needed.
+
+
@@ -726,10 +770,10 @@