From: Zbigniew Jędrzejewski-Szmek Date: Thu, 15 Sep 2022 12:43:59 +0000 (+0100) Subject: man: "the initial RAM disk" → "the initrd" X-Git-Tag: v252-rc1~120^2~7 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b66a6e1a5838b874b789820c090dd6850cf10513;p=thirdparty%2Fsystemd.git man: "the initial RAM disk" → "the initrd" In many places we spelled out the phrase behind "initrd" in full, but this isn't terribly useful. In fact, no "RAM disk" is used, so emphasizing this is just confusing to the reader. Let's just say "initrd" everywhere, people understand what this refers to, and that it's in fact an initramfs image. Also, s/i.e./e.g./ where appropriate. Also, don't say "in RAM", when in fact it's virtual memory, whose pages may or may not be loaded in page frames in RAM, and we have no control over this. Also, add and other minor cleanups. --- diff --git a/man/bootctl.xml b/man/bootctl.xml index d7eea90a979..dfc56d61259 100644 --- a/man/bootctl.xml +++ b/man/bootctl.xml @@ -319,11 +319,11 @@ Controls creation and deletion of the Boot Loader Specification Type #1 entry - directory on the file system containing resources such as kernel images and initial RAM disk images - during and , respectively. The directory is named - after the entry token, as specified with parameter described below, - and is placed immediately below the $BOOT root directory (i.e. beneath the file - system returned by the option, see above). Defaults to + directory on the file system containing resources such as kernel and initrd images during + and , respectively. The directory is named after the + entry token, as specified with parameter described below, and is + placed immediately below the $BOOT root directory (i.e. beneath the file system + returned by the option, see above). Defaults to no. diff --git a/man/bootup.xml b/man/bootup.xml index 6c69c8a9bd9..62a34fe3d72 100644 --- a/man/bootup.xml +++ b/man/bootup.xml @@ -33,13 +33,13 @@ The kernel (optionally) mounts an in-memory file system, often generated by dracut8, - 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. + which looks for the root file system. Nowadays this is implemented as an "initramfs" — a compressed CPIO + archive that the kernel extracts into a tmpfs. 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 diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml index c648f7779e7..368783d6fee 100644 --- a/man/kernel-command-line.xml +++ b/man/kernel-command-line.xml @@ -27,8 +27,8 @@ Description - The kernel, the initial RAM disk (initrd) and basic userspace functionality may be configured at - boot via kernel command line arguments. In addition, various systemd tools look at the EFI variable + The kernel, the programs running in the initrd and in the host system may be configured at boot via + kernel command line arguments. In addition, various systemd tools look at the EFI variable SystemdOptions (if available). Both sources are combined, but the kernel command line has higher priority. Please note that the EFI variable is only used by systemd tools, and is ignored by the kernel and other user space tools, so it is not a replacement for the kernel @@ -40,8 +40,7 @@ and bootparam7. - For command line parameters understood by the initial RAM - disk, please see + For command line parameters understood by the initrd, see dracut.cmdline7, or the documentation of the specific initrd implementation of your installation. diff --git a/man/kernel-install.xml b/man/kernel-install.xml index f6a6c05126d..475dd325a52 100644 --- a/man/kernel-install.xml +++ b/man/kernel-install.xml @@ -18,7 +18,7 @@ kernel-install - Add and remove kernel and initramfs images to and from /boot + Add and remove kernel and initrd images to and from /boot @@ -34,10 +34,15 @@ Description - kernel-install is used to install and remove kernel and initramfs images to and - from the boot loader partition, referred to as $BOOT here. It will usually be one of - /boot/, /efi/, or /boot/efi/, see below. - + kernel-install is used to install and remove kernel and initrd images + + Nowadays actually CPIO archives used as an "initramfs", rather than "initrd". See + bootup7 for an + explanation. + + to and from the boot loader partition, referred to as $BOOT here. It will usually be + one of /boot/, /efi/, or /boot/efi/, see + below. kernel-install will run the executable files ("plugins") located in the directory /usr/lib/kernel/install.d/ and the local administration directory @@ -63,16 +68,16 @@ add KERNEL-VERSION KERNEL-IMAGE [INITRD-FILE ...] - This command expects a kernel version string and a path to a kernel image file as - arguments. Optionally, one or more initial RAM disk images may be specified as well (note that - plugins might generate additional ones). kernel-install calls the executable - files from /usr/lib/kernel/install.d/*.install and + This command expects a kernel version string and a path to a kernel image file as arguments. + Optionally, one or more initrd images may be specified as well (note that plugins might generate + additional ones). kernel-install calls the executable files from + /usr/lib/kernel/install.d/*.install and /etc/kernel/install.d/*.install (i.e. the plugins) with the following arguments: add KERNEL-VERSION $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...] - The third argument directly refers to the path where to place kernel images, initial RAM disk + The third argument directly refers to the path where to place kernel images, initrd images and other resources for Boot Loader Specification Type #1 entries (the "entry directory"). If other boot loader schemes are used the parameter may be ignored. The ENTRY-TOKEN string is diff --git a/man/org.freedesktop.systemd1.xml b/man/org.freedesktop.systemd1.xml index 919df52135a..945c24a3a76 100644 --- a/man/org.freedesktop.systemd1.xml +++ b/man/org.freedesktop.systemd1.xml @@ -1368,11 +1368,11 @@ node /org/freedesktop/systemd1 { for more information. SwitchRoot() may be used to transition to a new root directory. This is - intended to be used by initial RAM disks. The method takes two arguments: the new root directory (which - needs to be specified) and an init binary path (which may be left empty, in which case it is - automatically searched for). The state of the system manager will be serialized before the - transition. After the transition, the manager binary on the main system is invoked and replaces the old - PID 1. All state will then be deserialized. + intended to be used in the initrd, and also to transition from the host system into a shutdown initrd. + The method takes two arguments: the new root directory (which needs to be specified) and an init binary + path (which may be left empty, in which case it is automatically searched for). The state of the system + manager will be serialized before the transition. After the transition, the manager binary on the main + system is invoked and replaces the old PID 1. All state will then be deserialized. SetEnvironment() may be used to alter the environment block that is passed to all spawned processes. It takes a string array of environment variable assignments. Any previously set diff --git a/man/os-release.xml b/man/os-release.xml index 168c1675a94..7325f840b9c 100644 --- a/man/os-release.xml +++ b/man/os-release.xml @@ -442,11 +442,10 @@ Takes a space-separated list of one or more of the strings system, initrd and portable. This field is only supported in extension-release.d/ files and indicates what environments - the system extension is applicable to: i.e. to regular systems, to initial RAM filesystems - ("initrd") or to portable service images. If unspecified, SYSEXT_SCOPE=system - portable is implied, i.e. any system extension without this field is applicable to - regular systems and to portable service environments, but not to initrd - environments. + the system extension is applicable to: i.e. to regular systems, to initrds, or to portable service + images. If unspecified, SYSEXT_SCOPE=system portable is implied, i.e. any system + extension without this field is applicable to regular systems and to portable service environments, + but not to initrd environments. diff --git a/man/systemctl.xml b/man/systemctl.xml index 290d670fe5f..4f70cd0c639 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -1527,15 +1527,16 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err switch-root ROOT INIT - Switches to a different root directory and executes a new system manager process below it. This is - intended for usage in initial RAM disks ("initrd"), and will transition from the initrd's system manager - process (a.k.a. "init" process) to the main system manager process which is loaded from the actual host - volume. This call takes two arguments: the directory that is to become the new root directory, and the path - to the new system manager binary below it to execute as PID 1. If the latter is omitted or the empty - string, a systemd binary will automatically be searched for and used as init. If the system manager path is - omitted, equal to the empty string or identical to the path to the systemd binary, the state of the - initrd's system manager process is passed to the main system manager, which allows later introspection of - the state of the services involved in the initrd boot phase. + Switches to a different root directory and executes a new system manager process below it. + This is intended for use in the initrd, and will transition from the initrd's system manager + process (a.k.a. "init" process) to the main system manager process which is loaded from the + actual host root files system. This call takes two arguments: the directory that is to become the + new root directory, and the path to the new system manager binary below it to execute as PID 1. + If the latter is omitted or the empty string, a systemd binary will automatically be searched for + and used as init. If the system manager path is omitted, equal to the empty string or identical + to the path to the systemd binary, the state of the initrd's system manager process is passed to + the main system manager, which allows later introspection of the state of the services involved + in the initrd boot phase. diff --git a/man/systemd-boot.xml b/man/systemd-boot.xml index 7a2d3ec8264..0eee532f90a 100644 --- a/man/systemd-boot.xml +++ b/man/systemd-boot.xml @@ -444,7 +444,7 @@ stored in the EFI variable LoaderSystemToken (see below). During early OS boot the system manager reads this variable and passes it to the OS kernel's random pool, crediting the full entropy it contains. This is an efficient way to ensure the system starts up with a fully initialized - kernel random pool — as early as the initial RAM disk phase. systemd-boot reads + kernel random pool — as early as the initrd phase. systemd-boot reads the random seed from the ESP, combines it with the "system token", and both derives a new random seed to update in-place the seed stored in the ESP, and the random seed to pass to the OS from it via SHA256 hashing in counter mode. This ensures that different physical systems that boot the same diff --git a/man/systemd-creds.xml b/man/systemd-creds.xml index d9b30a7e96a..1e97e2609b1 100644 --- a/man/systemd-creds.xml +++ b/man/systemd-creds.xml @@ -129,11 +129,10 @@ Which of the three keys shall be used for encryption may be configured with the - switch. Depending on the use-case for the encrypted credential the key to - use may differ. For example, for credentials that shall be accessible from the initial RAM disk - (initrd) of the system encryption with the host key is not appropriate since access to the host key - is typically not available from the initrd. Thus, for such credentials only the TPM2 key should be - used. + switch. Depending on the use-case for the encrypted credential the key + to use may differ. For example, for credentials that shall be accessible from the initrd, encryption + with the host key is not appropriate, since access to the host key is typically not available from + the initrd. Thus, for such credentials only the TPM2 key should be used. Encrypted credentials are always encoded in Base64. diff --git a/man/systemd-cryptenroll.xml b/man/systemd-cryptenroll.xml index 889dd39b039..7e1431a5ffa 100644 --- a/man/systemd-cryptenroll.xml +++ b/man/systemd-cryptenroll.xml @@ -296,7 +296,7 @@ 9 - The Linux kernel measures all initial RAM file systems it receives into this PCR. + The Linux kernel measures all initrds it receives into this PCR. @@ -307,7 +307,7 @@ 11 - systemd-stub7 measures the ELF kernel image, embedded initrd and other payload of the PE image it is placed in into this PCR. Unlike PCR 4 (where the same data should be measured into), this PCR value should be easy to pre-calculate, as this only contains static parts of the PE binary. Use this PCR to bind TPM policies to a specific kernel image, possibly with an embedded initial RAM disk (initrd). + systemd-stub7 measures the ELF kernel image, embedded initrd and other payload of the PE image it is placed in into this PCR. Unlike PCR 4 (where the same data should be measured into), this PCR value should be easy to pre-calculate, as this only contains static parts of the PE binary. Use this PCR to bind TPM policies to a specific kernel image, possibly with an embedded initrd. diff --git a/man/systemd-cryptsetup-generator.xml b/man/systemd-cryptsetup-generator.xml index e5c193f6920..5ba024a866b 100644 --- a/man/systemd-cryptsetup-generator.xml +++ b/man/systemd-cryptsetup-generator.xml @@ -49,48 +49,40 @@ luks= rd.luks= - Takes a boolean argument. Defaults to - yes. If no, disables the - generator entirely. rd.luks= is honored - only by initial RAM disk (initrd) while - luks= is honored by both the main system - and the initrd. + Takes a boolean argument. Defaults to yes. If + no, disables the generator entirely. rd.luks= is honored only + in the initrd while luks= is honored by both the main system and in the initrd. + luks.crypttab= rd.luks.crypttab= - Takes a boolean argument. Defaults to - yes. If no, causes the - generator to ignore any devices configured in - /etc/crypttab - (luks.uuid= will still work however). - rd.luks.crypttab= is honored only by - initial RAM disk (initrd) while - luks.crypttab= is honored by both the main - system and the initrd. + Takes a boolean argument. Defaults to yes. If + no, causes the generator to ignore any devices configured in + /etc/crypttab (luks.uuid= will still work however). + rd.luks.crypttab= is honored only in initrd while + luks.crypttab= is honored by both the main system and the initrd. + luks.uuid= rd.luks.uuid= - Takes a LUKS superblock UUID as argument. This - will activate the specified device as part of the boot process - as if it was listed in /etc/crypttab. - This option may be specified more than once in order to set up - multiple devices. rd.luks.uuid= is honored - only by initial RAM disk (initrd) while - luks.uuid= is honored by both the main - system and the initrd. - If /etc/crypttab contains entries with the same UUID, - then the name, keyfile and options specified there will be - used. Otherwise, the device will have the name + Takes a LUKS superblock UUID as argument. This will activate the specified device as + part of the boot process as if it was listed in /etc/crypttab. This option may + be specified more than once in order to set up multiple devices. rd.luks.uuid= is + honored only in the initrd, while luks.uuid= is honored by both the main system + and the initrd. + + If /etc/crypttab contains entries with the same UUID, then the name, + keyfile and options specified there will be used. Otherwise, the device will have the name luks-UUID. - If /etc/crypttab exists, only those UUIDs - specified on the kernel command line - will be activated in the initrd or the real root. + + If /etc/crypttab exists, only those UUIDs specified on the kernel command + line will be activated in the initrd or the real root. @@ -108,9 +100,8 @@ This parameter is the analogue of the first crypttab 5 field volume-name. - rd.luks.name= is honored only by - initial RAM disk (initrd) while luks.name= - is honored by both the main system and the initrd. + rd.luks.name= is honored only in the initrd, while + luks.name= is honored by both the main system and the initrd. @@ -137,8 +128,8 @@ This parameter is the analogue of the second crypttab 5 field encrypted-device. - rd.luks.data= is honored only by initial RAM disk (initrd) while - luks.data= is honored by both the main system and the initrd. + rd.luks.data= is honored only in the initrd, while + luks.data= is honored by both the main system and in the initrd. @@ -173,12 +164,8 @@ This parameter is the analogue of the third crypttab 5 field key-file. - rd.luks.key= - is honored only by initial RAM disk - (initrd) while - luks.key= is - honored by both the main system and - the initrd. + rd.luks.key= is honored only in the initrd, while + luks.key= is honored by both the main system and in the initrd. diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml index 21c3ea94a70..b7908377a4f 100644 --- a/man/systemd-fstab-generator.xml +++ b/man/systemd-fstab-generator.xml @@ -70,13 +70,10 @@ fstab= rd.fstab= - Takes a boolean argument. Defaults to - yes. If no, causes the - generator to ignore any mounts or swap devices configured in - /etc/fstab. rd.fstab= - is honored only by the initial RAM disk (initrd) while - fstab= is honored by both the main system - and the initrd. + Takes a boolean argument. Defaults to yes. If + no, causes the generator to ignore any mounts or swap devices configured in + /etc/fstab. rd.fstab= is honored only in the initrd, while + fstab= is honored by both the main system and the initrd. @@ -194,12 +191,12 @@ If true the generator ensures systemd-volatile-root.service8 - is run as part of the initial RAM disk ("initrd"). This service changes the mount table before transitioning to - the host system, so that a volatile memory file system (tmpfs) is used as root directory, - with only /usr/ mounted into it from the configured root file system, in read-only - mode. This way the system operates in fully stateless mode, with all configuration and state reset at boot and - lost at shutdown, as /etc/ and /var/ will be served from the (initially - unpopulated) volatile memory file system. + is run in the initrd. This service changes the mount table before transitioning to the host system, + so that a volatile memory file system (tmpfs) is used as root directory, with only + /usr/ mounted into it from the configured root file system, in read-only mode. + This way the system operates in fully stateless mode, with all configuration and state reset at boot + and lost at shutdown, as /etc/ and /var/ will be served + from the (initially unpopulated) volatile memory file system. If set to the generator will leave the root directory mount point unaltered, however will mount a tmpfs file system to /var/. In this mode the normal diff --git a/man/systemd-modules-load.service.xml b/man/systemd-modules-load.service.xml index 0144650e870..691194866aa 100644 --- a/man/systemd-modules-load.service.xml +++ b/man/systemd-modules-load.service.xml @@ -52,10 +52,8 @@ modules_load= rd.modules_load= - Takes a comma-separated list of kernel modules - to statically load during early boot. The option prefixed with - rd. is read by the initial RAM disk - only. + Takes a comma-separated list of kernel modules to statically load during early boot. + The option prefixed with rd. is read in the initrd only. diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml index 5e8bc028066..16e2286ed08 100644 --- a/man/systemd-nspawn.xml +++ b/man/systemd-nspawn.xml @@ -443,9 +443,9 @@ in the container's file system namespace. This is for containers which have several bootable directories in them; for example, several - OSTree deployments. It emulates the behavior of - the boot loader and initial RAM disk which normally select which directory to mount as the root and start the - container's PID 1 in. + OSTree deployments. It emulates the + behavior of the boot loader and the initrd which normally select which directory to mount as the root + and start the container's PID 1 in. diff --git a/man/systemd-random-seed.service.xml b/man/systemd-random-seed.service.xml index 0a50b51e4d4..a1e31cd4609 100644 --- a/man/systemd-random-seed.service.xml +++ b/man/systemd-random-seed.service.xml @@ -33,14 +33,14 @@ into the kernel entropy pool during boot and saves it at shutdown. See random4 for details. By default, no entropy is credited when the random seed is written into the kernel entropy pool, - but this may be changed with $SYSTEMD_RANDOM_SEED_CREDIT, see below. On disk the random + but this may be changed with $SYSTEMD_RANDOM_SEED_CREDIT, see below. On disk the random seed is stored in /var/lib/systemd/random-seed. Note that this service runs relatively late during the early boot phase, i.e. generally after the - initial RAM disk (initrd) completed its work, and the /var/ file system has been - mounted writable. Many system services require entropy much earlier than this — this service is hence of - limited use for complex system. It is recommended to use a boot loader that can pass an initial random - seed to the kernel to ensure that entropy is available from earliest boot on, for example + initrd phase has finished and the /var/ file system has been mounted. Many system + services require entropy much earlier than this — this service is hence of limited use for complex + system. It is recommended to use a boot loader that can pass an initial random seed to the kernel to + ensure that entropy is available from earliest boot on, for example systemd-boot7, with its bootctl random-seed functionality. diff --git a/man/systemd-remount-fs.service.xml b/man/systemd-remount-fs.service.xml index be74307f9b9..266db884614 100644 --- a/man/systemd-remount-fs.service.xml +++ b/man/systemd-remount-fs.service.xml @@ -36,7 +36,7 @@ systemd-gpt-auto-generator8 is active) to the root file system, the /usr/ file system, and the kernel API file systems. This is required so that the mount options of these file systems — which are pre-mounted by the - kernel, the initial RAM disk, container environments or system manager code — are updated to those + kernel, the initrd, container environments or system manager code — are updated to those configured in /etc/fstab and the other sources. This service ignores normal file systems and only changes the root file system (i.e. /), /usr/, and the virtual kernel API file systems such as /proc/, /sys/ or diff --git a/man/systemd-repart.xml b/man/systemd-repart.xml index 475aeec2121..236058b74c3 100644 --- a/man/systemd-repart.xml +++ b/man/systemd-repart.xml @@ -43,14 +43,14 @@ If invoked with no arguments, it operates on the block device backing the root file system partition of the running OS, thus growing and adding partitions of the booted OS image itself. If --image= is used it will operate on the specified image file. When called in the - initrd it operates on the block device backing /sysroot/ instead, - i.e. on the block device the system will soon transition into. The - systemd-repart.service service is generally run at boot in the initial RAM disk, in - order to augment the partition table of the OS before its partitions are - mounted. systemd-repart (mostly) operates in a purely incremental mode: it only grows - existing and adds new partitions; it does not shrink, delete or move existing partitions. The service is - intended to be run on every boot, but when it detects that the partition table already matches the - installed repart.d/*.conf configuration files, it executes no operation. + initrd it operates on the block device backing /sysroot/ instead, i.e. on the block + device the system will soon transition into. The systemd-repart.service service is + generally run at boot in the initrd, in order to augment the partition table of the OS before its + partitions are mounted. systemd-repart (mostly) operates in a purely incremental mode: + it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions. + The service is intended to be run on every boot, but when it detects that the partition table already + matches the installed repart.d/*.conf configuration files, it executes no + operation. systemd-repart is intended to be used when deploying OS images, to automatically adjust them to the system they are running on, during first boot. This way the deployed image can be @@ -89,34 +89,34 @@ Taking the size constraints and weights declared in the configuration files into account, all partitions that shall be created are now allocated to the disk, taking up all free space, - always respecting the size and padding requests. Similar, existing partitions that are determined to - grow are grown. New partitions are always appended to the end of the existing partition table, taking - the first partition table slot whose index is greater than the indexes of all existing - partitions. Partition table slots are never reordered and thus partition numbers are ensured to remain - stable. Note that this allocation happens in RAM only, the partition table on disk is not updated - yet. + always respecting the size and padding requests. Similarly, existing partitions that should be grown + are grown. New partitions are always appended to the end of the partition table, taking the first + partition table slot whose index is greater than the indexes of all existing partitions. Partition + table slots are never reordered and thus partition numbers are ensured to remain stable. Note that this + allocation happens in memory only, the partition table on disk is not updated yet. All existing partitions for which configuration files exist and which currently have no GPT partition label set will be assigned a label, either explicitly configured in the configuration or - (if that's missing) derived automatically from the partition type. The same is done for all partitions - that are newly created. These assignments are done in RAM only, too, the disk is not updated - yet. + — if that's missing — derived automatically from the partition type. The same is done for all + partitions that are newly created. These assignments are done in memory only, too, the disk is not + updated yet. Similarly, all existing partitions for which configuration files exist and which currently have an all-zero identifying UUID will be assigned a new UUID. This UUID is cryptographically hashed from a common seed value together with the partition type UUID (and a counter in case multiple partitions of the same type are defined), see below. The same is done for all partitions that are - created anew. These assignments are done in RAM only, too, the disk is not updated - yet. + created anew. These assignments are done in memory only, too, the disk is not updated yet. + Similarly, if the disk's volume UUID is all zeroes it is also initialized, also - cryptographically hashed from the same common seed value. Also, in RAM only, too. + cryptographically hashed from the same common seed value. This is done in memory only too. + - The disk space assigned to new partitions (i.e. what was previously considered free - space but is no longer) is now erased. Specifically, all file system signatures are removed, and if the - device supports it the BLKDISCARD I/O control command is issued to inform the - hardware that the space is empty now. In addition any "padding" between partitions and at the end of - the device is similarly erased. + The disk space assigned to new partitions (i.e. what was previously free space) is now + erased. Specifically, all file system signatures are removed, and if the device supports it, the + BLKDISCARD I/O control command is issued to inform the hardware that the space is + now empty. In addition any "padding" between partitions and at the end of the device is similarly + erased. The new partition table is finally written to disk. The kernel is asked to reread the partition table. @@ -257,9 +257,9 @@ repart.d/*.conf files, for the machine ID file to use as seed and for the CopyFiles= and CopyBlocks= source files and directories. By default when invoked on the regular system this defaults to the host's root file system - /. If invoked from the initial RAM disk this defaults to - /sysroot/, so that the tool operates on the configuration and machine ID stored - in the root file system later transitioned into itself. + /. If invoked from the initrd this defaults to /sysroot/, + so that the tool operates on the configuration and machine ID stored in the root file system later + transitioned into itself. diff --git a/man/systemd-stub.xml b/man/systemd-stub.xml index f8c3eee3939..dacf0fa7a7b 100644 --- a/man/systemd-stub.xml +++ b/man/systemd-stub.xml @@ -57,8 +57,8 @@ os-release5 file of the OS the kernel belongs to, in the .osrel PE section. - The initial RAM disk (initrd) will be looked for in the .initrd PE - section. + The initrd will be loaded from the .initrd PE section. + A compiled binary DeviceTree will be looked for in the .dtb PE section. @@ -290,27 +290,27 @@ StubPcrKernelImage - The PCR register index the ELF kernel image/initial RAM disk image/boot - splash/devicetree database/embedded command line are measured into, formatted as decimal ASCII string - (i.e. 11). This variable is set if a measurement was successfully completed, and - remains unset otherwise. + The PCR register index the kernel image, initrd image, boot splash, devicetree + database, and the embedded command line are measured into, formatted as decimal ASCII string (e.g. + 11). This variable is set if a measurement was successfully completed, and remains + unset otherwise. StubPcrKernelParameters The PCR register index the kernel command line and credentials are measured into, - formatted as decimal ASCII string (i.e. 12). This variable is set if a measurement + formatted as decimal ASCII string (e.g. 12). This variable is set if a measurement was successfully completed, and remains unset otherwise. StubPcrInitRDSysExts - The PCR register index the systemd extensions for the initial RAM disk image, which - are picked up from the file system the kernel image is located on. Formatted as decimal ASCII string - (i.e. 13). This variable is set if a measurement was successfully completed, and - remains unset otherwise. + The PCR register index the systemd extensions for the initrd, which are picked up + from the file system the kernel image is located on. Formatted as decimal ASCII string (e.g. + 13). This variable is set if a measurement was successfully completed, and remains + unset otherwise.