picnoir/Systemd
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge pull request #16650 from keszybz/two-doc-updates

Browse source 
Two doc updates
This commit is contained in:
Anita Zhang 2020-08-04 18:05:38 -07:00 committed by GitHub
parent fea4ac42e3 3e2d2fbbdd
commit fe01daee67
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 21 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
docs/DISCOVERABLE_PARTITIONS.md
View file

@ -9,21 +9,21 @@ _TL;DR: Let's automatically discover, mount and enable the root partition,
`/home/`, `/srv/`, `/var/` and `/var/tmp/` and the swap partitions based on `/home/`, `/srv/`, `/var/` and `/var/tmp/` and the swap partitions based on
GUID Partition Tables (GPT)!_ GUID Partition Tables (GPT)!_
The GUID Partition Table (GPT) is mandatory on EFI systems. It allows This specification describes the use of GUID Partition Table (GPT) UUIDs to
identification of partition types with UUIDs. So far Linux has made little use enable automatic discovery of partitions and their intended mountpoints.
of this, and mostly just defined one UUID for file system/data partitions and Traditionally Linux has made little use of partition types, mostly just
another one for swap partitions. With this specification, we introduce defining one UUID for file system/data partitions and another one for swap
additional partition types to enable automatic discovery of partitions and partitions. With this specification, we introduce additional partition types
their intended mountpoint. This has many benefits: for specific uses. This has many benefits:
* OS installers can automatically discover and make sense of partitions of * OS installers can automatically discover and make sense of partitions of
existing Linux installations. existing Linux installations.
* The OS can discover and mount the necessary file systems with a non-existing * The OS can discover and mount the necessary file systems with a non-existent
or incomplete `/etc/fstab` file and without the `root=` kernel command line or incomplete `/etc/fstab` file and without the `root=` kernel command line
option. option.
* Container managers (such as nspawn and libvirt-lxc) can decode and set up * Container managers (such as nspawn and libvirt-lxc) can introspect and set up
file systems contained in GPT disk images automatically and mount them to the file systems contained in GPT disk images automatically and mount them to the
right places, thus allowing booting the same, identical images on bare-metal right places, thus allowing booting the same, identical images on bare metal
and in Linux containers. This enables true, natural portability of disk and in Linux containers. This enables true, natural portability of disk
images between physical machines and Linux containers. images between physical machines and Linux containers.
* As a help to administrators and users partition manager tools can show more * As a help to administrators and users partition manager tools can show more

18
man/journald.conf.xml
View file

@ -67,12 +67,18 @@
<literal>persistent</literal>, data will be stored preferably on disk, i.e. below the <literal>persistent</literal>, data will be stored preferably on disk, i.e. below the
<filename>/var/log/journal</filename> hierarchy (which is created if needed), with a fallback to <filename>/var/log/journal</filename> hierarchy (which is created if needed), with a fallback to
<filename>/run/log/journal</filename> (which is created if needed), during early boot and if the disk <filename>/run/log/journal</filename> (which is created if needed), during early boot and if the disk
is not writable. <literal>auto</literal> is similar to <literal>persistent</literal> but the is not writable. <literal>auto</literal> behaves like <literal>persistent</literal> if the
directory <filename>/var/log/journal</filename> is not created if needed, so that its existence <filename>/var/log/journal</filename> directory exists, and <literal>volatile</literal> otherwise
controls where log data goes. <literal>none</literal> turns off all storage, all log data received (the existence of the directory controls the storage mode). <literal>none</literal> turns off all
will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog storage, all log data received will be dropped (but forwarding to other targets, such as the console,
socket will still work however. Defaults to <literal>auto</literal> in the default journal namespace, the kernel log buffer, or a syslog socket will still work). Defaults to <literal>auto</literal> in
and <literal>persistent</literal> in all others.</para></listitem> the default journal namespace, and <literal>persistent</literal> in all others.</para>
<para>Note that when this option is changed to <literal>volatile</literal>, existing persistent data
is not removed. In the other direction,
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> with
the <option>--flush</option> option may be used to move volatile data to persistent storage.</para>
</listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>