docs: fix dead links

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,15 +248,15 @@ 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"
 [githubmd]: https://help.github.com/articles/github-flavored-markdown/
 [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"

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
 

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`:
 

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
 

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

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

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.

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.

content/docs/latest/setup/debug/reading-the-system-log.md

@@ -134,5 +134,5 @@ systemd:
 
 ## More information
 
-<a class="btn btn-default" href="getting-started-with-systemd">Getting Started with systemd</a>
-<a class="btn btn-default" href="network-config-with-networkd">Network Configuration with networkd</a>
+<a class="btn btn-default" href="../../systemd/getting-started">Getting Started with systemd</a>
+<a class="btn btn-default" href="../../customization/network-config-with-networkd">Network Configuration with networkd</a>

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