summaryrefslogtreecommitdiff
path: root/docs/RANDOM_SEEDS.md
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2022-09-23 15:10:06 +0200
committerLennart Poettering <lennart@poettering.net>2022-09-23 15:12:18 +0200
commit55c041b4e4dffad936522674d739a0affc08bdf4 (patch)
treeb0aef0c05053e157cd38b22008568014b000ca67 /docs/RANDOM_SEEDS.md
parent32e276708089110243682d8aaa3d58075b91f0d6 (diff)
downloadsystemd-55c041b4e4dffad936522674d739a0affc08bdf4.tar.gz
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.
Diffstat (limited to 'docs/RANDOM_SEEDS.md')
-rw-r--r--docs/RANDOM_SEEDS.md12
1 files changed, 6 insertions, 6 deletions
diff --git a/docs/RANDOM_SEEDS.md b/docs/RANDOM_SEEDS.md
index 9ac7d00b2e..3dc27f5552 100644
--- a/docs/RANDOM_SEEDS.md
+++ b/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