diff options
author | Lennart Poettering <lennart@poettering.net> | 2022-09-23 15:10:06 +0200 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2022-09-23 15:12:18 +0200 |
commit | 55c041b4e4dffad936522674d739a0affc08bdf4 (patch) | |
tree | b0aef0c05053e157cd38b22008568014b000ca67 /docs/RANDOM_SEEDS.md | |
parent | 32e276708089110243682d8aaa3d58075b91f0d6 (diff) | |
download | systemd-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.md | 12 |
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 |