From f254abcd72b6ca6c4567c245a7dbaf739d02dfc2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Mon, 3 Aug 2020 13:22:01 +0200 Subject: [PATCH 1/2] man: describe that changing Storage= does not move existing data Fixes #16384. --- man/journald.conf.xml | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/man/journald.conf.xml b/man/journald.conf.xml index bfd359a903..d792ef7220 100644 --- a/man/journald.conf.xml +++ b/man/journald.conf.xml @@ -67,12 +67,18 @@ persistent, data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk - is not writable. auto is similar to persistent but the - directory /var/log/journal is not created if needed, so that its existence - controls where log data goes. none 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 auto in the default journal namespace, - and persistent in all others. + is not writable. auto behaves like persistent if the + /var/log/journal directory exists, and volatile otherwise + (the existence of the directory controls the storage mode). none 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 auto in + the default journal namespace, and persistent in all others. + + Note that when this option is changed to volatile, existing persistent data + is not removed. In the other direction, + journalctl1 with + the option may be used to move volatile data to persistent storage. + From 3e2d2fbbdde0bc93e0177806cc851e5f5ae4a0a7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Mon, 3 Aug 2020 14:49:24 +0200 Subject: [PATCH 2/2] docs: reword intro in DISCOVERABLE PARTITIONS This specification is useful independently of UEFI, so avoid making assertions about UEFI. Also reword the intro to say what this is about in the very first sentence. Closes #16570. --- docs/DISCOVERABLE_PARTITIONS.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/DISCOVERABLE_PARTITIONS.md b/docs/DISCOVERABLE_PARTITIONS.md index f1537b8939..20f4206d08 100644 --- a/docs/DISCOVERABLE_PARTITIONS.md +++ b/docs/DISCOVERABLE_PARTITIONS.md @@ -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