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

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

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
GUID Partition Tables (GPT)!_
The GUID Partition Table (GPT) is mandatory on EFI systems. It allows
identification of partition types with UUIDs. So far Linux has made little use
of this, and mostly just defined one UUID for file system/data partitions and
another one for swap partitions. With this specification, we introduce
additional partition types to enable automatic discovery of partitions and
their intended mountpoint. This has many benefits:
This specification describes the use of GUID Partition Table (GPT) UUIDs to
enable automatic discovery of partitions and their intended mountpoints.
Traditionally Linux has made little use of partition types, mostly just
defining one UUID for file system/data partitions and another one for swap
partitions. With this specification, we introduce additional partition types
for specific uses. This has many benefits:
* OS installers can automatically discover and make sense of partitions of
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
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
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
images between physical machines and Linux containers.
* 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
<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
is not writable. <literal>auto</literal> is similar to <literal>persistent</literal> but the
directory <filename>/var/log/journal</filename> is not created if needed, so that its existence
controls where log data goes. <literal>none</literal> turns off all storage, all log data received
will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog
socket will still work however. Defaults to <literal>auto</literal> in the default journal namespace,
and <literal>persistent</literal> in all others.</para></listitem>
is not writable. <literal>auto</literal> behaves like <literal>persistent</literal> if the
<filename>/var/log/journal</filename> directory exists, and <literal>volatile</literal> otherwise
(the existence of the directory controls the storage mode). <literal>none</literal> turns off all
storage, all log data received will be dropped (but forwarding to other targets, such as the console,
the kernel log buffer, or a syslog socket will still work). Defaults to <literal>auto</literal> in
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>