From 5f73eab2634374022e6aad71e0419afc0fd7cb21 Mon Sep 17 00:00:00 2001 From: cksrb63 Date: Sun, 4 Oct 2026 19:19:47 +0900 Subject: [PATCH] docs: fix stale links (cherry picked from commit 26bde2b760ade0f73d3fbe90d12a492c1a5348ba) --- docs/CONTROL_GROUP_INTERFACE.md | 2 +- docs/FACTORY_RESET.md | 3 +-- docs/OPTIMIZATIONS.md | 2 +- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/CONTROL_GROUP_INTERFACE.md b/docs/CONTROL_GROUP_INTERFACE.md index 573e1a0e4d..1026f99161 100644 --- a/docs/CONTROL_GROUP_INTERFACE.md +++ b/docs/CONTROL_GROUP_INTERFACE.md @@ -26,7 +26,7 @@ That means explicitly, that: 1. The root control group may only be written to by systemd (PID 1). Services that create and manipulate control groups in the top level cgroup are in direct conflict with the kernel's requirement that each control group should have a single-writer only. 2. Services must set Delegate=yes for the units they intend to manage subcgroups of. If they create and manipulate cgroups outside of units that have Delegate=yes set, they violate the access contract for control groups. -For a more high-level background story, please have a look at this [Linux Foundation News Story](https://www.linuxfoundation.jp/blog/2013/08/all-about-the-linux-kernel-cgroups-redesign/). +For a more high-level background story, please have a look at this [Linux.com News Story](https://www.linux.com/news/all-about-linux-kernel-cgroups-redesign/). ### Why this all again? diff --git a/docs/FACTORY_RESET.md b/docs/FACTORY_RESET.md index bb0e3063b1..d8556957d9 100644 --- a/docs/FACTORY_RESET.md +++ b/docs/FACTORY_RESET.md @@ -41,8 +41,7 @@ Specifically, the following concepts are available: invalidating all prior keys associated with the security chip and generating a new seed key. -* The - [`systemd-factory-reset-reboot.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-factory-reset-reboot.service.html) +* The `systemd-factory-reset-reboot.service` unit automatically reboots the system as part of `factory-reset.target`. It is ordered after `systemd-tpm2-clear.service` and `systemd-factory-reset-request.service` in order to initiate the reboot that diff --git a/docs/OPTIMIZATIONS.md b/docs/OPTIMIZATIONS.md index 83a3838a50..676abe0c1d 100644 --- a/docs/OPTIMIZATIONS.md +++ b/docs/OPTIMIZATIONS.md @@ -9,7 +9,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later _So you are working on a Linux distribution or appliance and need very fast boot-ups?_ -systemd can already offer boot times of < 1s for the Core OS (userspace only, i.e. only the bits controlled by systemd) and < 2s for a complete up-to-date desktop environments on simpler (but modern, i.e. SSDs) laptops if configured properly (examples: [http://git.fenrus.org/tmp/bootchart-20120512-1036.svg](http://git.fenrus.org/tmp/bootchart-20120512-1036.svg)). +systemd can already offer boot times of < 1s for the Core OS (userspace only, i.e. only the bits controlled by systemd) and < 2s for a complete up-to-date desktop environments on simpler (but modern, i.e. SSDs) laptops if configured properly. In this page we want to suggest a couple of ideas how to achieve that, and if the resulting boot times do not suffice where we believe room for improvements are that we'd like to see implemented sooner or later.