mirror of
https://github.com/systemd/systemd-stable.git
synced 2025-01-12 09:17:44 +03:00
Fix a few docs typos (#10907)
Found with [codespell](https://github.com/codespell-project/codespell)
This commit is contained in:
parent
1e268f423c
commit
b24546706e
@ -32,7 +32,7 @@ components:
|
|||||||
* The
|
* The
|
||||||
[`systemd-boot-check-no-failures.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-boot-check-no-failures.service.html)
|
[`systemd-boot-check-no-failures.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-boot-check-no-failures.service.html)
|
||||||
service is a simple health check tool that determines whether the boot
|
service is a simple health check tool that determines whether the boot
|
||||||
completed successfuly. When enabled it becomes an indirect dependency of
|
completed successfully. When enabled it becomes an indirect dependency of
|
||||||
`systemd-bless-boot.service` (by means of `boot-complete.target`, see
|
`systemd-bless-boot.service` (by means of `boot-complete.target`, see
|
||||||
below), ensuring that the boot will not be considered successful if there are
|
below), ensuring that the boot will not be considered successful if there are
|
||||||
any failed services.
|
any failed services.
|
||||||
@ -99,7 +99,7 @@ Here's an example walkthrough of how this all fits together.
|
|||||||
newest boot entry is now tried, i.e. the system automatically reverted back
|
newest boot entry is now tried, i.e. the system automatically reverted back
|
||||||
to an earlier version.
|
to an earlier version.
|
||||||
|
|
||||||
The above describes the walkthrough when the selected boot entry continously
|
The above describes the walkthrough when the selected boot entry continuously
|
||||||
fails. Let's have a look at an alternative ending to this walkthrough. In this
|
fails. Let's have a look at an alternative ending to this walkthrough. In this
|
||||||
scenario the first 4 steps are the same as above:
|
scenario the first 4 steps are the same as above:
|
||||||
|
|
||||||
|
@ -52,7 +52,7 @@ For systems where the firmware is able to read file systems directly, `$BOOT` mu
|
|||||||
This specification defines two types of boot loader entries. The first type is
|
This specification defines two types of boot loader entries. The first type is
|
||||||
text based, very simple and suitable for a variety of firmware, architecture
|
text based, very simple and suitable for a variety of firmware, architecture
|
||||||
and image types ("Type #1"). The second type is specific to EFI, but allows
|
and image types ("Type #1"). The second type is specific to EFI, but allows
|
||||||
single-file images that embedd all metadata in the kernel binary itself, which
|
single-file images that embed all metadata in the kernel binary itself, which
|
||||||
is useful to cryptographically sign them as one file for the purpose of
|
is useful to cryptographically sign them as one file for the purpose of
|
||||||
SecureBoot ("Type #2").
|
SecureBoot ("Type #2").
|
||||||
|
|
||||||
|
@ -122,7 +122,7 @@ thinking about them as orthogonal won't help you in the long run anyway.
|
|||||||
If you wonder how to detect which of these three modes is currently used, use
|
If you wonder how to detect which of these three modes is currently used, use
|
||||||
`statfs()` on `/sys/fs/cgroup/`. If it reports `CGROUP2_SUPER_MAGIC` in its
|
`statfs()` on `/sys/fs/cgroup/`. If it reports `CGROUP2_SUPER_MAGIC` in its
|
||||||
`.f_type` field, then you are in unified mode. If it reports `TMPFS_MAGIC` then
|
`.f_type` field, then you are in unified mode. If it reports `TMPFS_MAGIC` then
|
||||||
you are either in legacy or hybrid mode. To distuingish these two cases, run
|
you are either in legacy or hybrid mode. To distinguish these two cases, run
|
||||||
`statfs()` again on `/sys/fs/cgroup/unified/`. If that succeeds and reports
|
`statfs()` again on `/sys/fs/cgroup/unified/`. If that succeeds and reports
|
||||||
`CGROUP2_SUPER_MAGIC` you are in hybrid mode, otherwise not.
|
`CGROUP2_SUPER_MAGIC` you are in hybrid mode, otherwise not.
|
||||||
|
|
||||||
|
@ -394,7 +394,7 @@
|
|||||||
- To determine the length of a constant string `"foo"`, don't bother with
|
- To determine the length of a constant string `"foo"`, don't bother with
|
||||||
`sizeof("foo")-1`, please use `strlen()` instead (both gcc and clang optimize
|
`sizeof("foo")-1`, please use `strlen()` instead (both gcc and clang optimize
|
||||||
the call away for fixed strings). The only exception is when declaring an
|
the call away for fixed strings). The only exception is when declaring an
|
||||||
array. In that case use STRLEN, which evalutates to a static constant and
|
array. In that case use STRLEN, which evaluates to a static constant and
|
||||||
doesn't force the compiler to create a VLA.
|
doesn't force the compiler to create a VLA.
|
||||||
|
|
||||||
- If you want to concatenate two or more strings, consider using `strjoina()`
|
- If you want to concatenate two or more strings, consider using `strjoina()`
|
||||||
@ -457,7 +457,7 @@
|
|||||||
implement the public shared object we provide (sd-bus, sd-login, sd-id128,
|
implement the public shared object we provide (sd-bus, sd-login, sd-id128,
|
||||||
nss-systemd, nss-mymachines, nss-resolve, nss-myhostname, pam_systemd), must
|
nss-systemd, nss-mymachines, nss-resolve, nss-myhostname, pam_systemd), must
|
||||||
be located in `src/basic` (those objects are not allowed to link to
|
be located in `src/basic` (those objects are not allowed to link to
|
||||||
libsystemd-shared.so). Conversly, anything which is shared between multiple
|
libsystemd-shared.so). Conversely, anything which is shared between multiple
|
||||||
components and does not need to be in `src/basic/`, should be in
|
components and does not need to be in `src/basic/`, should be in
|
||||||
`src/shared/`.
|
`src/shared/`.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user