tree-wide: also settle on "initrd" instead of "initial RAM disk"

With this the concept is now called the same way everywhere except where
historical info is relevant or where the other names are API.

docs/CREDENTIALS.md

@@ -282,8 +282,8 @@ services where they are ultimately consumed.
    EFI System Partition, which are then picked up by `systemd-stub` and passed
    to the kernel and ultimately userspace where systemd receives them. This is
    useful to implement secure parameterization of vendor-built and signed
-   initial RAM disks, as userspace can place credentials next to these EFI
-   kernels, and be sure they can be accessed securely from initrd context.
+   initrds, as userspace can place credentials next to these EFI kernels, and
+   be sure they can be accessed securely from initrd context.
 
 Credentials passed to the system may be enumerated/displayed via `systemd-creds
 --system`. They may also be propagated down to services, via the

docs/INITRD_INTERFACE.md

@@ -8,15 +8,16 @@ SPDX-License-Identifier: LGPL-2.1-or-later
 
 # The initrd Interface of systemd
 
-The Linux initrd mechanism (short for "initial RAM disk") refers to a small
-file system archive that is unpacked by the kernel and contains the first
-userspace code that runs. It typically finds and transitions into the actual
-root file system to use. systemd supports both initrd and initrd-less boots. If
-an initrd is used, it is a good idea to pass a few bits of runtime information
-from the initrd to systemd in order to avoid duplicate work and to provide
-performance data to the administrator. In this page we attempt to roughly
-describe the interfaces that exist between the initrd and systemd. These
-interfaces are currently used by dracut and the ArchLinux initrds.
+The Linux initrd mechanism (short for "initial RAM disk", also known as
+"initramfs") refers to a small file system archive that is unpacked by the
+kernel and contains the first userspace code that runs. It typically finds and
+transitions into the actual root file system to use. systemd supports both
+initrd and initrd-less boots. If an initrd is used, it is a good idea to pass a
+few bits of runtime information from the initrd to systemd in order to avoid
+duplicate work and to provide performance data to the administrator. In this
+page we attempt to roughly describe the interfaces that exist between the
+initrd and systemd. These interfaces are currently used by dracut and the
+ArchLinux initrds.
 
 * The initrd should mount `/run/` as a tmpfs and pass it pre-mounted when
   jumping into the main system when executing systemd. The mount options should
@@ -57,10 +58,10 @@ It's all already implemented there!
 It is also possible and recommended to implement the initrd itself based on
 systemd. Here are a few terse notes:
 
-* Provide `/etc/initrd-release` in the initrd image. The idea is that it follows
-  the same format as the usual `/etc/os-release` but describes the initial RAM
-  disk implementation rather than the OS. systemd uses the existence of this
-  file as a flag whether to run in initial RAM disk mode, or not.
+* Provide `/etc/initrd-release` in the initrd image. The idea is that it
+  follows the same format as the usual `/etc/os-release` but describes the
+  initrd implementation rather than the OS. systemd uses the existence of this
+  file as a flag whether to run in initrd mode, or not.
 
 * When run in initrd mode, systemd and its components will read a couple of
   additional command line arguments, which are generally prefixed with `rd.`

docs/RANDOM_SEEDS.md

@@ -102,9 +102,9 @@ random bytes will either be delayed, will fail or result in a noisy kernel log
 message (see above).
 
 Various other components run during early boot that require random bytes. For
-example, initial RAM disks nowadays communicate with encrypted networks or
-access encrypted storage which might need random numbers. systemd itself
-requires random numbers as well, including for the following uses:
+example, initrds nowadays communicate with encrypted networks or access
+encrypted storage which might need random numbers. systemd itself requires
+random numbers as well, including for the following uses:
 
 * systemd assigns 'invocation' UUIDs to all services it invokes that uniquely
   identify each invocation. This is useful retain a global handle on a specific
@@ -174,9 +174,9 @@ boot, in order to ensure the entropy pool is filled up quickly.
    be enabled by setting the `$SYSTEMD_RANDOM_SEED_CREDIT` environment variable
    for the service to `1` (or even `force`, see man page). Note however, that
    this service typically runs relatively late during early boot: long after
-   the initial RAM disk (`initrd`) completed, and after the `/var/` file system
-   became writable. This is usually too late for many applications, it is hence
-   not advised to rely exclusively on this functionality to seed the kernel's
+   the initrd completed, and after the `/var/` file system became
+   writable. This is usually too late for many applications, it is hence not
+   advised to rely exclusively on this functionality to seed the kernel's
    entropy pool. Also note that this service synchronously waits until the
    kernel's entropy pool is initialized before completing start-up. It may thus
    be used by other services as synchronization point to order against, if they

docs/ROOT_STORAGE_DAEMONS.md

@@ -22,16 +22,16 @@ is not.
 ## A Bit of Background
 
 When complex storage technologies are used as backing for the root file system
-this needs to be set up by the initial RAM file system (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 fs)
-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 initrd' job is to
-detach/unmount the root fs, 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.
+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 fs) 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 initrd' job is to detach/unmount
+the root fs, 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

docs/UIDS-GIDS.md

@@ -73,7 +73,7 @@ Note that systemd requires that system users and groups are resolvable without
 networking available — a requirement that is not made for regular users. This
 means regular users may be stored in remote LDAP or NIS databases, but system
 users may not (except when there's a consistent local cache kept, that is
-available during earliest boot, including in the initial RAM disk).
+available during earliest boot, including in the initrd).
 
 ## Special `systemd` GIDs