From 59fe8d74b57f54d1d6b7da2b3fe5b82c18c48db1 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Wed, 4 Jun 2025 14:50:07 +0200 Subject: [PATCH] doc: mention 'exitrd' term --- docs/ROOT_STORAGE_DAEMONS.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/ROOT_STORAGE_DAEMONS.md b/docs/ROOT_STORAGE_DAEMONS.md index 41fc602772b..86b132bc047 100644 --- a/docs/ROOT_STORAGE_DAEMONS.md +++ b/docs/ROOT_STORAGE_DAEMONS.md @@ -26,12 +26,13 @@ this needs to be set up by the initrd, i.e. on Fedora by Dracut. In newer systemd versions tear-down of the root file system backing is also done by the initrd: after terminating all remaining running processes and unmounting all file systems it can (which means excluding the root file system) systemd will -jump back into the initrd code allowing it to unmount the final file systems -(and its storage backing) that could not be unmounted as long as the OS was -still running from the main root file system. The job of the initrd is to -detach/unmount the root file system, i.e. inverting the exact commands it used -to set them up in the first place. This is not only cleaner, but also allows -for the first time arbitrary complex stacks of storage technology. +jump back into the initrd code (this code shall hereby be called the *exitrd*) +allowing it to unmount the final file systems (and its storage backing) that +could not be unmounted as long as the OS was still running from the main root +file system. The job of the exitrd is to detach/unmount the root file system, +i.e. inverting the exact commands it used to set them up in the first +place. This is not only cleaner, but also allows for the first time arbitrary +complex stacks of storage technology. Previous attempts to handle root file system setups with complex storage as backing usually tried to maintain the root storage with program code stored on -- 2.47.3