From 543e6bd4c2853e2551bbc9c715797a41c0f4b607 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Fri, 22 Mar 2019 13:10:39 +0100 Subject: [PATCH 1/3] man: update description of initrd in bootup(7) Mention that initramfs is used, not initrd, even though we still call it that. Also add links and clarify who loads the initramfs. --- man/bootup.xml | 37 ++++++++++++++++++++++--------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/man/bootup.xml b/man/bootup.xml index 386af9e4de..9468a61319 100644 --- a/man/bootup.xml +++ b/man/bootup.xml @@ -23,22 +23,29 @@ Description - A number of different components are involved in the system - boot. Immediately after power-up, the system BIOS will do minimal - hardware initialization, and hand control over to a boot loader - stored on a persistent storage device. This boot loader will then - invoke an OS kernel from disk (or the network). In the Linux case, - this kernel (optionally) extracts and executes an initial RAM disk - image (initrd), such as generated by + A number of different components are involved in the boot of a Linux system. Immediately after + power-up, the system firmware will do minimal hardware initialization, and hand control over to a boot + loader (e.g. + systemd-boot7 or + GRUB) stored on a persistent storage device. This + boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types + of firmware, this firmware may also load the kernel directly. + + The kernel (optionally) mounts an in-memory file system, often generated by dracut8, - which looks for the root file system (possibly using - systemd1 - for this). After the root file system is found and mounted, the - initrd hands over control to the host's system manager (such as - systemd1) - stored on the OS image, which is then responsible for probing all - remaining hardware, mounting all necessary file systems and - spawning all configured services. + which looks for the root file system. Nowadays this is usually implemented as an initramfs — a compressed + archive which is extracted when the kernel boots up into a lightweight in-memory file system based on + tmpfs, but in the past normal file systems using an in-memory block device (ramdisk) were used, and the + name "initrd" is still used to describe both concepts. It's the boot loader or the firmware that loads + both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file + system. systemd1 may + be used to manage services in the initrd, similarly to the real system. + + After the root file system is found and mounted, the initrd hands over control to the host's system + manager (such as + systemd1) stored in + the root file system, which is then responsible for probing all remaining hardware, mounting all + necessary file systems and spawning all configured services. On shutdown, the system manager stops all services, unmounts all file systems (detaching the storage technologies backing From 3aaae27a75dd2f3795dadce9a6566326751e0d0c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Fri, 22 Mar 2019 13:23:02 +0100 Subject: [PATCH 2/3] man: clarify that ExecStop= is always called Fixes #11744. --- man/systemd.service.xml | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index c61e0f0296..b9a3266dfd 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -473,14 +473,18 @@ start-up failed, for example because any of the commands specified in ExecStart=, ExecStartPre= or ExecStartPost= failed (and weren't prefixed with -, see above) or timed out. Use ExecStopPost= to invoke commands when a - service failed to start up correctly and is shut down again. Also note that, service restart requests are - implemented as stop operations followed by start operations. This means that ExecStop= and - ExecStopPost= are executed during a service restart operation. + service failed to start up correctly and is shut down again. Also note that the stop operation is always + performed if the service started successfully, even if the processes in the service terminated on their + own or were killed. The stop commands must be prepared to deal with that case. $MAINPID + will be unset if systemd knows that the main process exited by the time the stop commands are called. - It is recommended to use this setting for commands that communicate with the service requesting clean - termination. When the commands specified with this option are executed it should be assumed that the service is - still fully up and is able to react correctly to all commands. For post-mortem clean-up steps use - ExecStopPost= instead. + Service restart requests are implemented as stop operations followed by start operations. This + means that ExecStop= and ExecStopPost= are executed during a + service restart operation. + + It is recommended to use this setting for commands that communicate with the service requesting + clean termination. For post-mortem clean-up steps use ExecStopPost= instead. + From fd9baae8c42c2c9b4a71382335ab710c3ddcdfba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Fri, 22 Mar 2019 16:26:05 +0100 Subject: [PATCH 3/3] NEWS: add missing word --- NEWS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index eefe5fef5c..4e89134286 100644 --- a/NEWS +++ b/NEWS @@ -7,8 +7,8 @@ CHANGES WITH 242 in spe: similar interfaces that do not have other identifying information, the interface name is used as the basis for persistent seed for MAC and IPv4LL addresses. The way that devices that were handled - previously is not changed, and this change is about covering devices - then previously by the "persistent" policy. + previously is not changed, and this change is about covering more + devices then previously by the "persistent" policy. MACAddressPolicy=random may be used to force randomized MACs and IPv4LL addresses for a device if desired.