diff --git a/content/docs/latest/contribute/docs.md b/content/docs/latest/contribute/docs.md
index 0f8a0912..e6be29cf 100644
--- a/content/docs/latest/contribute/docs.md
+++ b/content/docs/latest/contribute/docs.md
@@ -212,7 +212,7 @@ which link will likewise have its label defined at the document's foot.
Using relative URLs where possible helps portability among multiple presentation targets, as they remain valid even as the site root moves. Absolute linking is obviously necessary for resources external to the document's repository and/or the docs.flatcar-linux.org domain.
-For example, there are two ways to refer to the [Flatcar quick start guide][quickstart]'s location. The preferred way is a relative link from the current file's path to the target, which from this document is `os/quickstart`. An absolute link to the complete URL is less flexible, and more verbose: `https://github.com/flatcar/flatcar-docs/blob/master/os/quickstart.md`.
+For example, there are two ways to refer to the [Flatcar quick start guide][quickstart]'s location. The preferred way is a relative link from the current file's path to the target, which from this document is `../../installing`. An absolute link to the complete URL is less flexible, and more verbose: `https://github.com/flatcar/flatcar-website/blob/master/content/docs/latest/installing/_index.md`.
#### Hyperlink deployment automation
@@ -248,7 +248,7 @@ Some file types are commonly identified with more than one file name extension.
[command-line-grammar]: #command-line-grammar
-[configuring-dns]: os/configuring-dns
+[configuring-dns]: ../../setup/customization/configuring-dns
[flatcar-docs]: https://docs.flatcar-linux.org/
[economist-hyphens]: http://www.economist.com/news/books-and-arts/21723088-hyphens-can-be-tricky-they-need-not-drive-you-crazy-hysteria-over-hyphens
[eos]: https://faculty.washington.edu/heagerty/Courses/b572/public/StrunkWhite.pdf "The Elements of Style"
@@ -256,7 +256,7 @@ Some file types are commonly identified with more than one file name extension.
[headings]: #headings
[hyperlink-considerations]: #hyperlink-considerations
[mdhome]: https://daringfireball.net/projects/markdown/syntax
-[quickstart]: os/quickstart "Relative link from here to CoreOS Quick Start"
+[quickstart]: ../../installing "Relative link from here to Flatcar Quick Start"
[rfc2606s3]: https://tools.ietf.org/html/rfc2606#section-3
[rfc5737]: https://tools.ietf.org/html/rfc5737
[style]: docs "CoreOS Documentation Style"
diff --git a/content/docs/latest/installing/cloud/gcp.md b/content/docs/latest/installing/cloud/gcp.md
index b8fb0d4c..ca6abb8a 100644
--- a/content/docs/latest/installing/cloud/gcp.md
+++ b/content/docs/latest/installing/cloud/gcp.md
@@ -93,7 +93,7 @@ The Dockerfile for the `quay.io/kinvolk/google-cloud-flatcar-image-upload` image
## Upgrade from CoreOS Container Linux
-You can also [upgrade from an existing CoreOS Container Linux system](./update-from-container-linux).
+You can also [upgrade from an existing CoreOS Container Linux system](../../migrating-from-coreos/update-from-container-linux).
## Butane Config
diff --git a/content/docs/latest/installing/cloud/vmware.md b/content/docs/latest/installing/cloud/vmware.md
index dd40b92d..cc33cd55 100644
--- a/content/docs/latest/installing/cloud/vmware.md
+++ b/content/docs/latest/installing/cloud/vmware.md
@@ -156,7 +156,7 @@ IP configuration specified via `guestinfo.interface.*` and `guestinfo.dns.*` var
### Templating with Butane Configs and setting up metadata
-On many cloud providers Ignition will run the [`coreos-metadata.service`](../../provisioning/ignition/metadata/#metadataconf) (which runs `afterburn`) to set up [node metadata](../../provisioning/config-transpiler/dynamic-data). This is not the case with VMware because the network setup is defined by you and nothing generic that `afterburn` would know about.
+On many cloud providers Ignition will run the [`coreos-metadata.service`](../../provisioning/ignition/dynamic-data) (which runs `afterburn`) to set up [node metadata](../../provisioning/cl-config/dynamic-data). This is not the case with VMware because the network setup is defined by you and nothing generic that `afterburn` would know about.
Here's a Butane configuration example to setup an `etcd` instance with a custom `coreos-metadata.service`:
diff --git a/content/docs/latest/migrating-from-coreos/update-from-container-linux.md b/content/docs/latest/migrating-from-coreos/update-from-container-linux.md
index 6a0a92ff..4a9c6229 100644
--- a/content/docs/latest/migrating-from-coreos/update-from-container-linux.md
+++ b/content/docs/latest/migrating-from-coreos/update-from-container-linux.md
@@ -37,7 +37,7 @@ $ chmod +x flatcar-update
$ sudo ./flatcar-update --to-version "$VER" --to-payload flatcar_production_update.gz --force-flatcar-key
```
-**Before you reboot, check that you migrated the variable names as written in [Migrating from CoreOS Container Linux](migrate-from-container-linux).**
+**Before you reboot, check that you migrated the variable names as written in [Migrating from CoreOS Container Linux][migrate-from-container-linux].**
## Going back to CoreOS Container Linux
diff --git a/content/docs/latest/provisioning/cl-config/examples.md b/content/docs/latest/provisioning/cl-config/examples.md
index fbd75e66..ccb9fa2a 100644
--- a/content/docs/latest/provisioning/cl-config/examples.md
+++ b/content/docs/latest/provisioning/cl-config/examples.md
@@ -211,4 +211,4 @@ This example configures the Container Linux instance to be a member of the beta
[spec]: ../config-transpiler/configuration
[dropins]: ../../setup/systemd/drop-in-units
[networkd]: ../../setup/customization/network-config-with-networkd
-[dynamic-data]: ../config-transpiler/dynamic-data
+[dynamic-data]: ../dynamic-data
diff --git a/content/docs/latest/provisioning/cl-config/from-cloud-config.md b/content/docs/latest/provisioning/cl-config/from-cloud-config.md
index 5b8578ca..38ae4d62 100644
--- a/content/docs/latest/provisioning/cl-config/from-cloud-config.md
+++ b/content/docs/latest/provisioning/cl-config/from-cloud-config.md
@@ -344,6 +344,6 @@ storage:
```
[provisioning]: _index.md
-[dynamic-data]: ../config-transpiler/dynamic-data
+[dynamic-data]: ../dynamic-data
[ct-config]: ../config-transpiler/configuration
[ignition]: ../ignition
diff --git a/content/docs/latest/provisioning/ignition/specification.md b/content/docs/latest/provisioning/ignition/specification.md
index e75a3e76..ba215af9 100644
--- a/content/docs/latest/provisioning/ignition/specification.md
+++ b/content/docs/latest/provisioning/ignition/specification.md
@@ -93,7 +93,7 @@ podman run -i --rm quay.io/coreos/butane:release --pretty --strict < config.yml
* **device** (string): the absolute path to the device. Devices are typically referenced by the `/dev/disk/by-*` symlinks.
* **format** (string): the filesystem format (ext4, btrfs, xfs, vfat, swap, or none).
* **_path_** (string): the mount-point of the filesystem while Ignition is running relative to where the root filesystem will be mounted. This is not necessarily the same as where it should be mounted in the real root, but it is encouraged to make it the same.
- * **_wipeFilesystem_** (boolean): whether or not to wipe the device before filesystem creation, see [the documentation on filesystems](ignition-fs-reuse) for more information. Defaults to false.
+ * **_wipeFilesystem_** (boolean): whether or not to wipe the device before filesystem creation, see [the documentation on filesystems][ignition-fs-reuse] for more information. Defaults to false.
* **_label_** (string): the label of the filesystem.
* **_uuid_** (string): the uuid of the filesystem.
* **_options_** (list of strings): any additional options to be passed to the format-specific mkfs utility.
@@ -159,7 +159,7 @@ podman run -i --rm quay.io/coreos/butane:release --pretty --strict < config.yml
* **_label_** (string): the label of the luks device.
* **_uuid_** (string): the uuid of the luks device.
* **_options_** (list of strings): any additional options to be passed to the cryptsetup utility.
- * **_wipeVolume_** (boolean): whether or not to wipe the device before volume creation, see [the documentation on filesystems](ignition-fs-reuse) for more information.
+ * **_wipeVolume_** (boolean): whether or not to wipe the device before volume creation, see [the documentation on filesystems][ignition-fs-reuse] for more information.
* **_clevis_** (object): describes the clevis configuration for the luks device.
* **_tang_** (list of objects): describes a tang server. Every server must have a unique `url`.
* **url** (string): url of the tang server.
@@ -255,7 +255,7 @@ Ignition v2 is not developed anymore but still supported (specification 2.3.0),
* **_mount_** (object): contains the set of mount and formatting options for the filesystem. A non-null entry indicates that the filesystem should be mounted before it is used by Ignition.
* **device** (string): the absolute path to the device. Devices are typically referenced by the `/dev/disk/by-*` symlinks.
* **format** (string): the filesystem format (ext4, btrfs, xfs, vfat, or swap).
- * **_wipeFilesystem_** (boolean): whether or not to wipe the device before filesystem creation, see [the documentation on filesystems](ignition-fs-reuse) for more information.
+ * **_wipeFilesystem_** (boolean): whether or not to wipe the device before filesystem creation, see [the documentation on filesystems][ignition-fs-reuse] for more information.
* **_label_** (string): the label of the filesystem.
* **_uuid_** (string): the uuid of the filesystem.
* **_options_** (list of strings): any additional options to be passed to the format-specific mkfs utility.
diff --git a/content/docs/latest/provisioning/sysext/_index.md b/content/docs/latest/provisioning/sysext/_index.md
index 5c5b4f0b..ff9febde 100644
--- a/content/docs/latest/provisioning/sysext/_index.md
+++ b/content/docs/latest/provisioning/sysext/_index.md
@@ -7,7 +7,7 @@ weight: 39
Flatcar Container Linux bundles various software components with fixed versions together into one release.
For users that require a particular version of a software component this means that the software needs to be supplied out of band and overwrite the built-in software copy.
In the past Torcx was introduced as a way to switch between Docker versions.
-Another approach we recommended was to [store binaries in `/opt/bin`](../container-runtimes/use-a-custom-docker-or-containerd-version/) and prefer them in the `PATH`.
+Another approach we recommended was to [store binaries in `/opt/bin`](../../container-runtimes/use-a-custom-docker-or-containerd-version/) and prefer them in the `PATH`.
The systemd project announced the portable services feature to address deploying custom services.
However, since it only covered the service itself without making the client binaries available on the user, it didn't really fit the use case fully.
diff --git a/content/docs/latest/setup/debug/reading-the-system-log.md b/content/docs/latest/setup/debug/reading-the-system-log.md
index 5220d6e0..a4327553 100644
--- a/content/docs/latest/setup/debug/reading-the-system-log.md
+++ b/content/docs/latest/setup/debug/reading-the-system-log.md
@@ -134,5 +134,5 @@ systemd:
## More information
-Getting Started with systemd
-Network Configuration with networkd
+Getting Started with systemd
+Network Configuration with networkd
diff --git a/content/docs/latest/setup/systemd/drop-in-units.md b/content/docs/latest/setup/systemd/drop-in-units.md
index 8c78f815..233f544b 100644
--- a/content/docs/latest/setup/systemd/drop-in-units.md
+++ b/content/docs/latest/setup/systemd/drop-in-units.md
@@ -157,7 +157,7 @@ For more examples using systemd customization, check out these documents:
* [Customizing Docker](../../container-runtimes/customizing-docker#using-a-dockercfg-file-for-authentication)
* [Customizing the SSH Daemon](../security/customizing-sshd#changing-the-sshd-port)
- * [Using Environment Variables in systemd Units](using-environment-variables-in-systemd-units)
+ * [Using Environment Variables in systemd Units](../environment-variables)
## More Information