From 96d26d24764f8d37cd675973745ffbbf165dffcd Mon Sep 17 00:00:00 2001 From: Samuel Karp Date: Wed, 14 Oct 2026 23:34:30 +0000 Subject: [PATCH] docs: fix broken documentation links Exclude the core/runtime/v2/README.md symlink in the links workflow so lychee does not fail resolving relative links from the symlink path. docs/runtime-v2.md is already validated directly. Update broken, moved, and rate-limited links across markdown documents: - Replace moved Kubernetes cgroup driver and GCP registry docs. - Replace retired RHEL 6 devmapper docs with kernel.org reference. - Point NSSM, CRIU, and Ansible references to GitHub repositories. - Fix relative paths in remote-snapshotter.md and root-relative paths. Assisted-by: Antigravity Signed-off-by: Samuel Karp --- .github/workflows/links.yml | 3 ++- BUILDING.md | 4 ++-- contrib/ansible/README.md | 4 ++-- docs/containerd-2.0.md | 2 +- docs/cri/config.md | 2 +- docs/cri/crictl.md | 2 +- docs/cri/registry.md | 2 +- docs/features.md | 2 +- docs/getting-started.md | 6 +++--- docs/snapshotters/devmapper.md | 2 +- docs/snapshotters/remote-snapshotter.md | 4 ++-- 11 files changed, 17 insertions(+), 16 deletions(-) diff --git a/.github/workflows/links.yml b/.github/workflows/links.yml index 2ca7e79a16..774e6f9582 100644 --- a/.github/workflows/links.yml +++ b/.github/workflows/links.yml @@ -26,7 +26,8 @@ jobs: with: # Fail action on broken links fail: true - args: --exclude-path vendor --exclude-path releases --timeout 30 --no-progress './**/*.md' + # Exclude core/runtime/v2/README.md symlink, already checked in docs/runtime-v2.md + args: --exclude-path vendor --exclude-path releases --exclude-path core/runtime/v2/README.md --timeout 30 --no-progress './**/*.md' format: markdown # Write GitHub job summary jobSummary: true diff --git a/BUILDING.md b/BUILDING.md index ae36969890..c628150ece 100644 --- a/BUILDING.md +++ b/BUILDING.md @@ -61,7 +61,7 @@ Runc is the default container runtime used by `containerd` and is required to run containerd. While it is okay to download a `runc` binary and install that on the system, sometimes it is necessary to build runc directly when working with container runtime development. Make sure to follow the guidelines for versioning -in [RUNC.md](/docs/RUNC.md) for the best results. +in [RUNC.md](docs/RUNC.md) for the best results. > *Note*: Runc only supports Linux @@ -128,7 +128,7 @@ to use `go mod` command to modify the dependencies. After modifition, you should and `go mod vendor` to ensure the `go.mod`, `go.sum` files and `vendor` directory are up to date. Changes to these files should become a single commit for a PR which relies on vendored updates. -Please refer to [RUNC.md](/docs/RUNC.md) for the currently supported version of `runc` that is used by containerd. +Please refer to [RUNC.md](docs/RUNC.md) for the currently supported version of `runc` that is used by containerd. > *Note*: On macOS, the containerd daemon can be built and run natively. However, as stated above, runc only supports linux. diff --git a/contrib/ansible/README.md b/contrib/ansible/README.md index 24af109eb6..5fa5fc3214 100644 --- a/contrib/ansible/README.md +++ b/contrib/ansible/README.md @@ -8,7 +8,7 @@ This document provides the steps to bring up a Kubernetes cluster using ansible - **Ansible**: 2.4+ ## Step 0: -- Install Ansible on the host where you will provision the cluster. This host may be one of the nodes you plan to include in your cluster. Installation instructions for Ansible are found [here](http://docs.ansible.com/ansible/latest/intro_installation.html). +- Install Ansible on the host where you will provision the cluster. This host may be one of the nodes you plan to include in your cluster. Installation instructions for Ansible are found in the [Ansible documentation](https://github.com/ansible/ansible#use-ansible). - Create a hosts file and include the IP addresses of the hosts that need to be provisioned by Ansible. ```console $ cat hosts @@ -29,7 +29,7 @@ A typical cloud login might have a username and private key file, in which case ```console ansible-playbook -i hosts -u --private-key cri-containerd.yaml ``` -For more options ansible config file (/etc/ansible/ansible.cfg) can be used to set defaults. Please refer to [Ansible options](http://docs.ansible.com/ansible/latest/intro_configuration.html) for advanced ansible configurations. +For more options ansible config file (/etc/ansible/ansible.cfg) can be used to set defaults. Please refer to the [Ansible documentation](https://github.com/ansible/ansible-documentation) for advanced ansible configurations. At the end of this step, you will have the required software installed in the hosts to bringup a kubernetes cluster. ```console diff --git a/docs/containerd-2.0.md b/docs/containerd-2.0.md index 9ee9f06cc2..f29148c9e3 100644 --- a/docs/containerd-2.0.md +++ b/docs/containerd-2.0.md @@ -113,7 +113,7 @@ The following syscalls (`io_uring_enter`, `io_uring_register`, and `io_uring_set Additional context: -- +- [#9048](https://github.com/containerd/containerd/issues/9048) ### `LimitNOFILE` configuration has been removed diff --git a/docs/cri/config.md b/docs/cri/config.md index 3a206263f4..3ba0381eb1 100644 --- a/docs/cri/config.md +++ b/docs/cri/config.md @@ -49,7 +49,7 @@ apiVersion: kubelet.config.k8s.io/v1beta1 cgroupDriver: "systemd" ``` -kubeadm users should also see [the kubeadm documentation](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). +kubeadm users should also see [the kubeadm documentation](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configuring-a-cgroup-driver). > Note: Kubernetes v1.28 supports automatic detection of the cgroup driver as > an alpha feature. With the `KubeletCgroupDriverFromCRI` kubelet feature gate diff --git a/docs/cri/crictl.md b/docs/cri/crictl.md index 64c77d020a..3a3376f7e8 100644 --- a/docs/cri/crictl.md +++ b/docs/cri/crictl.md @@ -12,7 +12,7 @@ or `crictl` please make sure the issue has not already been submitted. If you have not already installed crictl please install the version compatible with the `cri` plugin you are using. If you are a user, your deployment should have installed crictl for you. If not, get it from your release tarball. -If you are a developer the current version of crictl is specified [here](/script/setup/critools-version). +If you are a developer the current version of crictl is specified [here](../../script/setup/critools-version). A helper command has been included to install the dependencies at the right version: ```console $ make install-deps diff --git a/docs/cri/registry.md b/docs/cri/registry.md index 3357d6f2b9..8017534b98 100644 --- a/docs/cri/registry.md +++ b/docs/cri/registry.md @@ -70,7 +70,7 @@ After modifying this config, you need to restart the `containerd` service. If you don't already have Google Container Registry (GCR) set up then you need to do the following steps: * Create a Google Cloud Platform (GCP) account and project if not already created (see [GCP getting started](https://cloud.google.com/gcp/getting-started)) -* Enable GCR for your project (see [Quickstart for Container Registry](https://cloud.google.com/container-registry/docs/quickstart)) +* Enable GCR for your project (see [Set up repositories with gcr.io domain support](https://cloud.google.com/artifact-registry/docs/transition/setup-gcr-repo)) * For authentication to GCR: Create [service account and JSON key](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key) * The JSON key file needs to be downloaded to your system from the GCP console * For access to the GCR storage: Add service account to the GCR storage bucket with storage admin access rights (see [Granting permissions](https://cloud.google.com/container-registry/docs/access-control#grant-bucket)) diff --git a/docs/features.md b/docs/features.md index 75de81d914..ec214c7001 100644 --- a/docs/features.md +++ b/docs/features.md @@ -120,7 +120,7 @@ status, err := task.Wait(context) ## Checkpoint and Restore -If you have [criu](https://criu.org/Main_Page) installed on your machine you can checkpoint and restore containers and their tasks. This allows you to clone and/or live migrate containers to other machines. +If you have [criu](https://github.com/checkpoint-restore/criu) installed on your machine you can checkpoint and restore containers and their tasks. This allows you to clone and/or live migrate containers to other machines. ```go // checkpoint the task then push it to a registry diff --git a/docs/getting-started.md b/docs/getting-started.md index a6afc403e1..065f9344b0 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -103,7 +103,7 @@ The `containerd.io` package contains runc too, but does not contain CNI plugins. ### Option 3: From source -To install containerd and its dependencies from the source, see [`BUILDING.md`](/BUILDING.md). +To install containerd and its dependencies from the source, see [`BUILDING.md`](../BUILDING.md). ## Installing containerd on Windows @@ -143,7 +143,7 @@ Start-Service containerd > **Tip for Running `containerd` Service on Windows:** > > `containerd` logs are not persisted when we start it as a service -using Windows Service Manager. [`nssm`](https://nssm.cc) can be used to +using Windows Service Manager. [`nssm`](https://github.com/kirillkovalenko/nssm) can be used to configure logs to go into a cyclic buffer: > ```powershell > nssm.exe install containerd @@ -198,7 +198,7 @@ For non-managed environments, see the following Kubernetes documentations: ## Customizing containerd containerd uses a configuration file located in `/etc/containerd/config.toml` for specifying daemon level options. -A sample configuration file can be found [here](/docs/man/containerd-config.toml.5.md). +A sample configuration file can be found [here](man/containerd-config.toml.5.md). The default configuration can be generated via `containerd config default > /etc/containerd/config.toml`. diff --git a/docs/snapshotters/devmapper.md b/docs/snapshotters/devmapper.md index 7bf8bffec9..9302d8a1fe 100644 --- a/docs/snapshotters/devmapper.md +++ b/docs/snapshotters/devmapper.md @@ -195,7 +195,7 @@ See also [Configure direct-lvm mode for production](https://docs.docker.com/stor For more information on Device-mapper, thin provisioning, etc., you can refer to the following resources: -* https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/device_mapper +* https://docs.kernel.org/admin-guide/device-mapper/index.html * https://en.wikipedia.org/wiki/Device_mapper * https://docs.docker.com/storage/storagedriver/device-mapper-driver/ * https://www.kernel.org/doc/Documentation/device-mapper/thin-provisioning.txt diff --git a/docs/snapshotters/remote-snapshotter.md b/docs/snapshotters/remote-snapshotter.md index cf33632a6b..9c12f624c3 100644 --- a/docs/snapshotters/remote-snapshotter.md +++ b/docs/snapshotters/remote-snapshotter.md @@ -12,7 +12,7 @@ This enables containerd to lazily pull images from standard-compliant registries ## The containerd client API The containerd client's `Pull` API with unpacking-mode allows the underlying snapshotter to query for remote snapshots before fetching content. -Remote snapshotter needs to be plugged into containerd in [the same ways as normal snapshotters](/docs/PLUGINS.md). +Remote snapshotter needs to be plugged into containerd in [the same ways as normal snapshotters](../PLUGINS.md). ```go import ( @@ -87,7 +87,7 @@ if _, err := client.Pull(ctx, ref, The containerd client queries remote snapshots to the underlying remote snapshotter using snapshotter APIs. This section describes the high-level overview of how snapshotter APIs are used for remote snapshots functionality, with some piece of pseudo-codes that describe the simplified logic implemented in the containerd client. -For more details, see [`unpacker.go`](../core/unpack/unpacker.go) that implements this logic. +For more details, see [`unpacker.go`](../../core/unpack/unpacker.go) that implements this logic. During image pull, the containerd client calls `Prepare` API with the label `containerd.io/snapshot.ref`. This is a containerd-defined label which contains ChainID that targets a committed snapshot that the client is trying to prepare.