From: Yu Watanabe Date: Thu, 27 Feb 2025 04:32:01 +0000 (+0900) Subject: docs: fix typo X-Git-Tag: v258-rc1~1237 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=cf4b70aac4a58760bb0288ebe15ae6ed2292bbac;p=thirdparty%2Fsystemd.git docs: fix typo Follow-ups for d5de14899641395893425b36fdb0e95929647b38. --- diff --git a/docs/ROOTFS_DISCOVERY.md b/docs/ROOTFS_DISCOVERY.md index e7651be11d1..8de8031874a 100644 --- a/docs/ROOTFS_DISCOVERY.md +++ b/docs/ROOTFS_DISCOVERY.md @@ -174,7 +174,7 @@ In more complex setups it is possible to specify in more detail where to find each of these resources: 1. Firmware typically provides a basic boot menu which may be used to choose - between various releavant boot loaders/entrypoints on multiple disks. This + between various relevant boot loaders/entrypoints on multiple disks. This is sometimes configurable from the firmware setup tool, as well as from userspace via tools such as [`bootctl`](https://www.freedesktop.org/software/systemd/man/latest/bootctl.html), @@ -234,7 +234,7 @@ local disk. This can happen at each of these three components: Similar to the disk-based boot scheme described in the previous section discovery of the boot source can take place fully automatically, with each -component taking the boot source choice of the preceeding component into +component taking the boot source choice of the preceding component into account: the boot loader can automatically download UKIs from the same source it itself was downloaded from. Moreover the `initrd` of the UKI can automatically downloads the `rootfs` from the same source it itself was @@ -244,7 +244,7 @@ Also, much like in the disk-based boot scheme it is also possible to specifically direct each of the components to a different place instead of the automatic derivation of URLs from the same source. On top of that it is of course possible to mix disk-based and network-based boot: for example place the -boot loader on the local disk, but use UKIs and `rootfs` from networked souces; +boot loader on the local disk, but use UKIs and `rootfs` from networked sources; or alternatively place both boot loader and UKIs on the local disk, and only the `rootfs` on a networked source. @@ -317,9 +317,9 @@ way. However, do note that this mechanism is only suitable if the hardware is known to be compatible with this mechanism, because the Secure Boot certificate list is also used to authenticate firmware extensions provided by certain extension boards of PCs (for example graphics cards). Or in other words: -replacing the certficate list with your own might result in unbootable and even -bricked systems. Automatic enrolling of Secure Boot certficates is however a -really good option if the targeted harwdare is well known to be compatible with +replacing the certificate list with your own might result in unbootable and even +bricked systems. Automatic enrolling of Secure Boot certificates is however a +really good option if the targeted hardware is well known to be compatible with this, which is in particular the case in VMs. ### Measured Boot and TPMs