diff --git a/.github/workflows/update-versions.yml b/.github/workflows/update-versions.yml
index a8811e38..0639e023 100644
--- a/.github/workflows/update-versions.yml
+++ b/.github/workflows/update-versions.yml
@@ -11,10 +11,11 @@ permissions:
 jobs:
   update-versions:
     name: Update versions
+    if: ${{ github.repository_owner == 'coreos' || github.event_name != 'schedule' }}
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
       - name: Update versions
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
@@ -28,7 +29,7 @@ jobs:
                   -m "Triggered by update-versions GitHub Action."
           fi
       - name: Open pull request
-        uses: peter-evans/create-pull-request@v4.2.3
+        uses: peter-evans/create-pull-request@v6
         with:
           token: ${{ secrets.COREOSBOT_RELENG_TOKEN }}
           branch: update-versions
diff --git a/antora.yml b/antora.yml
index 7680c16b..984af2b3 100644
--- a/antora.yml
+++ b/antora.yml
@@ -8,6 +8,7 @@ nav:
 - modules/ROOT/nav.adoc
 asciidoc:
   attributes:
-    stable-version: 39.20231119.3.0
-    ignition-version: 2.17.0
-    butane-version: 0.19.0
+    stable-version: 41.20241122.3.0
+    ignition-version: 2.20.0
+    butane-version: 0.23.0
+    butane-latest-stable-spec: 1.5.0
diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc
index f3f56899..11924f04 100644
--- a/modules/ROOT/nav.adoc
+++ b/modules/ROOT/nav.adoc
@@ -27,6 +27,7 @@
 ** xref:storage.adoc[Configuring Storage]
 ** xref:managing-files.adoc[Managing Files]
 ** xref:sysconfig-network-configuration.adoc[Network Configuration]
+** xref:sysconfig-enabling-wifi.adoc[Enabling Wi-Fi]
 ** xref:sysctl.adoc[Kernel Tuning]
 ** xref:running-containers.adoc[Running Containers]
 ** xref:authentication.adoc[Configuring Users and Groups]
@@ -34,6 +35,7 @@
 ** xref:proxy.adoc[Proxied Internet Access]
 ** xref:sysconfig-setting-keymap.adoc[Setting Keyboard Layout]
 ** xref:os-extensions.adoc[Adding OS extensions]
+** xref:docker-ce.adoc[Installing Docker CE]
 ** xref:customize-nic.adoc[How to Customize a NIC Name]
 ** xref:sysconfig-configure-swaponzram.adoc[Configuring SwapOnZRAM]
 ** xref:sysconfig-configure-wireguard.adoc[Configuring WireGuard]
@@ -43,6 +45,7 @@
 ** xref:time-zone.adoc[Configuring Time Zone]
 ** xref:grub-password.adoc[Setting a GRUB password]
 ** xref:audit.adoc[Managing the audit daemon]
+** xref:composefs.adoc[ComposeFS]
 * OS updates
 ** xref:update-streams.adoc[Update Streams]
 ** xref:auto-updates.adoc[Auto-Updates]
diff --git a/modules/ROOT/pages/alternatives.adoc b/modules/ROOT/pages/alternatives.adoc
index 3e01732c..36899fd7 100644
--- a/modules/ROOT/pages/alternatives.adoc
+++ b/modules/ROOT/pages/alternatives.adoc
@@ -4,10 +4,10 @@ Due to an https://github.com/fedora-sysv/chkconfig/issues/9[ongoing issue] in ho
 
 Instead, until this issue is resolved, you can set the symlinks directly in `/etc/alternatives`. For example, to use the legacy-based variants of the `iptables` commands:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   links:
     - path: /etc/alternatives/iptables
@@ -35,3 +35,45 @@ storage:
       overwrite: true
       hard: false
 ----
+
+== Using alternatives commands
+
+Starting with Fedora CoreOS based on Fedora 41, you can use `alternatives` commands to configure the default command.
+
+.Example Butane config using a systemd unit to configure the default iptables backend
+[source,yaml,subs="attributes"]
+----
+variant: fcos
+version: {butane-latest-stable-spec}
+systemd:
+  units:
+    - name: custom-iptables-default.service
+      enabled: true
+      contents: |
+        [Unit]
+        Description=Set the default backend for iptables 
+        [Service]
+        ExecStart=/usr/sbin/alternatives --set iptables /usr/sbin/iptables-legacy
+        RemainAfterExit=yes
+        [Install]
+        WantedBy=multi-user.target
+----
+
+NOTE: We don't recommend configuring the default iptables backend to `iptables-legacy`. This is just an example.
+
+You can also manually run the `alternatives` commands to configure the default command runtime.
+
+.Example to manually configure the default iptables backend
+[source,bash]
+----
+# Check the link info
+alternatives --display iptables
+iptables --version
+
+# Configure iptables to point to iptables-nft
+sudo alternatives --set iptables /usr/sbin/iptables-nft
+
+# Verify iptables version is iptables-nft
+alternatives --display iptables
+iptables --version
+----
\ No newline at end of file
diff --git a/modules/ROOT/pages/audit.adoc b/modules/ROOT/pages/audit.adoc
index fdcf6bb3..83887f4d 100644
--- a/modules/ROOT/pages/audit.adoc
+++ b/modules/ROOT/pages/audit.adoc
@@ -16,7 +16,7 @@ To stop and restart the audit daemon, you should use the following commands:
 [source,bash]
 ----
 $ sudo auditctl --signal stop
-$ sudo systemctl start  # Only if you want it started again
+$ sudo systemctl start auditd.service  # Only if you want it started again
 ----
 
 You may also use the following commands to reload the rules, rotate the logs, resume logging or dump the daemon state:
diff --git a/modules/ROOT/pages/authentication.adoc b/modules/ROOT/pages/authentication.adoc
index f32b8857..3fa42137 100644
--- a/modules/ROOT/pages/authentication.adoc
+++ b/modules/ROOT/pages/authentication.adoc
@@ -10,10 +10,10 @@ If you do not want to use Ignition to manage the default user's SSH key(s), you
 
 To create a new user (or users), add it to the `users` list of your Butane config. In the following example, the config creates two new usernames, but doesn't configure them to be especially useful.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: jlebon
@@ -26,10 +26,10 @@ You will typically want to configure SSH keys or a password, in order to be able
 
 To configure an SSH key for a local user, you can use a Butane config:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core
@@ -50,10 +50,10 @@ Depending on the configuration variant and version you use, you can use local fi
 of inlining them.
 The example from the xref:#_using_an_ssh_key[previous section] can thus be rewritten as follows:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core
@@ -97,10 +97,10 @@ To view and validate the effective configuration for sshd, two test modes (`-t`,
 
 Fedora CoreOS ships with no default passwords. You can use a Butane config to set a password for a local user. Building on the previous example, we can configure the `password_hash` for one or more users:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core
@@ -135,10 +135,10 @@ Fedora CoreOS comes with a few groups configured by default: `root`, `adm`, `whe
 
 When configuring users via Butane configs, we can specify groups that the user(s) should be a part of.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core
@@ -161,10 +161,10 @@ passwd:
 
 If a group does not exist, users should create them as part of the Butane config.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 passwd:
   groups:
     - name: engineering
@@ -195,10 +195,10 @@ passwd:
 
 The easiest way for users to be granted administrative privileges is to have them added to the `sudo` and `wheel` groups as part of the Butane config.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 passwd:
   groups:
     - name: engineering
@@ -231,10 +231,10 @@ passwd:
 
 To enable password authentication via SSH, add the following to your Butane config:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/ssh/sshd_config.d/20-enable-passwords.conf
diff --git a/modules/ROOT/pages/auto-updates.adoc b/modules/ROOT/pages/auto-updates.adoc
index 0902932d..c9fd6a10 100644
--- a/modules/ROOT/pages/auto-updates.adoc
+++ b/modules/ROOT/pages/auto-updates.adoc
@@ -1,6 +1,6 @@
 = Auto-Updates and Manual Rollbacks
 
-Fedora CoreOS provides atomic updates and rollbacks via https://ostree.readthedocs.io/en/latest/[OSTree] deployments.
+Fedora CoreOS provides atomic updates and rollbacks via https://ostreedev.github.io/ostree/[OSTree] deployments.
 
 By default, the OS performs continual auto-updates via two components:
 
@@ -17,10 +17,10 @@ In order to receive updates very early in the phased rollout cycle, a node can b
 This can be done during provisioning by using the xref:producing-ign.adoc[Butane] config snippet shown below:
 
 .Example: configuring Zincati rollout wariness
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/zincati/config.d/51-rollout-wariness.toml
@@ -46,10 +46,10 @@ A specific finalization strategy can be configured on each node.
 The xref:producing-ign.adoc[Butane] snippet below shows how to define two maintenance windows during weekend days, starting at 22:30 UTC and lasting one hour each:
 
 .Example: configuring Zincati updates strategy
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/zincati/config.d/55-updates-strategy.toml
diff --git a/modules/ROOT/pages/bare-metal.adoc b/modules/ROOT/pages/bare-metal.adoc
index 2405e757..15d479a7 100644
--- a/modules/ROOT/pages/bare-metal.adoc
+++ b/modules/ROOT/pages/bare-metal.adoc
@@ -36,7 +36,7 @@ sudo coreos-installer install /dev/sda \
     --ignition-url https://example.com/example.ign
 ----
 
-Once the installation is complete, you can simply `sudo reboot`. After rebooting, the first boot process begins. It is at this time that Ignition ingests the configuration file and provisions the system as specified.
+Once the installation is complete, you can reboot the system using `sudo reboot`. After rebooting, the first boot process begins. It is at this time that Ignition ingests the configuration file and provisions the system as specified.
 
 For more advanced ISO installs, including automation, see below. For more about the live ISO image, see the xref:live-reference.adoc[live image reference].
 
@@ -174,6 +174,76 @@ A useful approach is to script generating a per-machine `.iso`. If you have a ha
 
 Alternatively, instead of generating per-machine ISOs, you can have a `--pre-install` script run a privileged container which inspects the target system and writes an appropriate https://coreos.github.io/coreos-installer/customizing-install/#config-file-format[installer config] to `/etc/coreos/installer.d`.
 
+=== Installing on iSCSI
+
+To install CoreOS on an iSCSI boot device, follow the same
+steps as described above to get the live environnement, and add the iSCSI-related kernel arguments.
+
+
+- Mount the iSCSI target from the live environment:
+[source, bash]
+----
+sudo iscsiadm -m discovery -t st -p 10.0.0.1
+sudo iscsiadm -m node -T iqn.2023-10.coreos.target.vm:coreos -l
+----
+
+- Append the necessary kargs when running `coreos-installer`:
+
+.Installing to an iSCSI target with iBFT
+
+On a completely diskless machine, the iscsi target and initiator values can be passed through iBFT.
+These could be supplied with an iPXE boot script for example:
+
+[source, bash]
+---
+#!ipxe
+set initiator-iqn iqn.2023-11.coreos.diskless:testsetup
+sanboot iscsi:10.0.0.1::::iqn.2023-10.coreos.target.vm:coreos
+---
+
+[source, bash]
+---
+sudo coreos-installer install \
+    /dev/disk/by-path/ip-10.0.0.1\:3260-iscsi-iqn.2023-10.coreos.target.vm\:coreos-lun-0 \
+    --append-karg rd.iscsi.firmware=1 --append-karg ip=ibft \
+    --console ttyS0 \
+    --ignition-url https://example.com/example.ign
+---
+
+
+.Installing to an iSCSI target with manual configuration
+[source, bash]
+---
+sudo coreos-installer install \
+    /dev/disk/by-path/ip-10.0.0.1\:3260-iscsi-iqn.2023-10.coreos.target.vm\:coreos-lun-0 \
+    --append-karg rd.iscsi.initiator=iqn.2024-02.com.yourorg.name:lun0 \
+    --append-karg netroot=iscsi:iqn.2023-10.coreos.target.vm:coreos` \
+    --console ttyS0 \
+    --ignition-url https://example.com/example.ign
+---
+
+
+All this can also be set using `coreos-installer iso customize` or `coreos-installer pxe customize`. (See "Customizing installation" section above).
+
+For example using iBFT:
+
+[source,bash,subs="attributes"]
+----
+# Create customized.iso which:
+# - Automatically mounts iSCSI target using mount-iscsi.sh
+# - Provisions the installed system with config.ign
+# - Configures the installed system to use iBFT
+coreos-installer iso customize \
+    --pre-install mount-iscsi.sh \
+    --dest-device /dev/disk/by-path/ip-10.0.0.1\:3260-iscsi-iqn.2023-10.coreos.target.vm\:coreos-lun-0 \
+    --dest-ignition config.ign \
+    --dest-karg-append rd.iscsi.firmware=1 \
+    --dest-karg-append ip=ibft \
+    -o custom.iso fedora-coreos-{stable-version}-live.x86_64.iso
+----
+
+The  `--pre-install` flag is used to run a script with `iscsiadm` commands, `--dest-device` targets the mounted disk and then `--dest-karg-append` add the necessary kargs.
+
 == Reinstalling Fedora CoreOS
 
 You can use any of the methods described above to reinstall Fedora CoreOS on the same machine via the live environment.
diff --git a/modules/ROOT/pages/bootloader-updates.adoc b/modules/ROOT/pages/bootloader-updates.adoc
index af6ed6ee..6024d9ed 100644
--- a/modules/ROOT/pages/bootloader-updates.adoc
+++ b/modules/ROOT/pages/bootloader-updates.adoc
@@ -34,10 +34,10 @@ Updated: grub2-efi-x64-1:2.04-31.fc33.x86_64,shim-x64-15-8.x86_64
 ----
 
 .Example systemd unit to automate bootupd updates
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: custom-bootupd-auto.service
diff --git a/modules/ROOT/pages/composefs.adoc b/modules/ROOT/pages/composefs.adoc
new file mode 100644
index 00000000..8afe68f3
--- /dev/null
+++ b/modules/ROOT/pages/composefs.adoc
@@ -0,0 +1,44 @@
+= Composefs
+
+Fedora CoreOS introduced composefs enabled by default starting in Fedora 41. Composefs is an overlay filesystem where the data comes from the usual ostree deployement, and
+metadata are in the composefs file. The result is a truely read-only root (`/`) filesystem, increasing the system integrity and robustness,
+
+This is a first step towards a full verification of filesystem integrity, even at runtime.
+
+== What does it change ? 
+
+The main visible change will be that the root filesystem (/) is now small and full (a few MB, 100% used).
+
+== Known issues
+
+=== Top-level directories
+
+Another consequence is that it is now impossible to create top-level directories in `/`.
+A common use case for those top level directories is to use them as mount points.
+We recommend using sub directories in `/var` instead.
+Currently, the only way around that is to disable composefs as shown below.
+
+== Disable composefs
+
+Composefs can be disabled through a kernel argument: `ostree.prepare-root.composefs=0`.
+
+.Disabling composefs at provisionning
+[source,yaml,subs="attributes"]
+----
+variant: fcos
+version: {butane-latest-stable-spec}
+kernel_arguments:
+  should_exist:
+    - ostree.prepare-root.composefs=0
+----
+
+.Disabling composefs on a running FCOS system
+[source,bash]
+----
+$ sudo rpm-ostree kargs --append='ostree.prepare-root.composefs=0'
+----
+Note that a reboot is required for the change to take effect.
+
+== Links
+
+https://fedoraproject.org/wiki/Changes/ComposefsAtomicCoreOSIoT
diff --git a/modules/ROOT/pages/counting.adoc b/modules/ROOT/pages/counting.adoc
index 6a94c9c7..c498517a 100644
--- a/modules/ROOT/pages/counting.adoc
+++ b/modules/ROOT/pages/counting.adoc
@@ -15,10 +15,10 @@ $ sudo systemctl mask --now rpm-ostree-countme.timer
 
 You can use the following Butane config to disable counting during provisioning on first boot:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: rpm-ostree-countme.timer
diff --git a/modules/ROOT/pages/customize-nic.adoc b/modules/ROOT/pages/customize-nic.adoc
index 8434ecc4..c6d925d3 100644
--- a/modules/ROOT/pages/customize-nic.adoc
+++ b/modules/ROOT/pages/customize-nic.adoc
@@ -6,10 +6,10 @@ You can create a systemd https://www.freedesktop.org/software/systemd/man/system
 For example, to name NIC with the MAC address `12:34:56:78:9a:bc` to "infra", place a systemd link file at `/etc/systemd/network/25-infra.link` using the xref:producing-ign.adoc[Butane] config snippet shown below:
 
 .Example: Customize NIC via systemd Link File
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/systemd/network/25-infra.link
@@ -26,10 +26,10 @@ storage:
 Similarly, also through Ignition configs, to name NIC with the MAC address `12:34:56:78:9a:bc` to "infra", create a https://man7.org/linux/man-pages/man7/udev.7.html[udev rule] at `/etc/udev/rules.d/80-ifname.rules` using the xref:producing-ign.adoc[Butane] config snippet shown below:
 
 .Example: Customize NIC via Udev Rules
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/udev/rules.d/80-ifname.rules
diff --git a/modules/ROOT/pages/debugging-kernel-crashes.adoc b/modules/ROOT/pages/debugging-kernel-crashes.adoc
index 3dc2d055..d7fa503c 100644
--- a/modules/ROOT/pages/debugging-kernel-crashes.adoc
+++ b/modules/ROOT/pages/debugging-kernel-crashes.adoc
@@ -9,10 +9,10 @@ By default, the vmcore will be saved in `/var/crash`. It is also possible to wri
 
 == Configuring kdump via Ignition
 .Example kdump configuration
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 kernel_arguments:
   should_exist:
   - 'crashkernel=300M'
diff --git a/modules/ROOT/pages/docker-ce.adoc b/modules/ROOT/pages/docker-ce.adoc
new file mode 100644
index 00000000..a08b01cb
--- /dev/null
+++ b/modules/ROOT/pages/docker-ce.adoc
@@ -0,0 +1,60 @@
+= Installing Docker CE
+
+By default, Fedora CoreOS comes with out-of-the-box support for `docker` CLI (as provided via https://mobyproject.org/[Moby]).
+However, in some cases Docker Community Edition (CE) may be preferred for various reasons.
+This page explains how to replace the provided version with the latest from the upstream Docker sources.
+
+The recommended approach from the official https://docs.docker.com/engine/install/fedora/[Docker documentation] is to add the Docker repository to your system.
+You can then install and update Docker CE from this repository.
+
+
+== Installing Docker CE on first boot
+
+On provisioning, you can install Docker CE during the first boot of the system via ignition configuration.
+
+.Example Butane config for setting up Docker CE
+[source,yaml,subs="attributes"]
+----
+variant: fcos
+version: {butane-latest-stable-spec}
+systemd:
+  units:
+    # Install Docker CE
+    - name: rpm-ostree-install-docker-ce.service
+      enabled: true
+      contents: |
+        [Unit]
+        Description=Install Docker CE
+        Wants=network-online.target
+        After=network-online.target
+        Before=zincati.service
+        ConditionPathExists=!/var/lib/%N.stamp
+
+        [Service]
+        Type=oneshot
+        RemainAfterExit=yes
+        ExecStart=/usr/bin/curl --output-dir "/etc/yum.repos.d" --remote-name https://download.docker.com/linux/fedora/docker-ce.repo
+        ExecStart=/usr/bin/rpm-ostree override remove moby-engine containerd runc --install docker-ce
+        ExecStart=/usr/bin/touch /var/lib/%N.stamp
+        ExecStart=/usr/bin/systemctl --no-block reboot
+
+        [Install]
+        WantedBy=multi-user.target
+----
+
+
+== Installing Docker CE on a running system
+
+First, download and setup the Docker repository.
+Then you need to remove `moby-engine` and several other conflicting packages that ship by default in the Fedora CoreOS image, install the necessary Docker CE packages, and reboot the system.
+
+[source, bash]
+----
+curl --remote-name https://download.docker.com/linux/fedora/docker-ce.repo
+sudo install --owner 0 --group 0 --mode 644 docker-ce.repo /etc/yum.repos.d/docker-ce.repo
+sudo rpm-ostree override remove moby-engine containerd runc --install docker-ce --reboot
+----
+
+=== Upgrading Docker CE
+
+Docker CE should be upgraded automatically with each new release of Fedora CoreOS.
diff --git a/modules/ROOT/pages/emergency-shell.adoc b/modules/ROOT/pages/emergency-shell.adoc
index 67ac433c..3b0b3efe 100644
--- a/modules/ROOT/pages/emergency-shell.adoc
+++ b/modules/ROOT/pages/emergency-shell.adoc
@@ -34,10 +34,10 @@ This will configure both the GRUB bootloader and the kernel to use the specified
 If you are launching FCOS from an image (in a cloud or a virtual machine), you can use Ignition to configure the console at provisioning time.
 
 .Example: Enabling primary serial and secondary graphical console
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 kernel_arguments:
   should_exist:
     # Order is significant, so group both arguments into the same list entry.
diff --git a/modules/ROOT/pages/faq.adoc b/modules/ROOT/pages/faq.adoc
index 92eaea0e..8f12868d 100644
--- a/modules/ROOT/pages/faq.adoc
+++ b/modules/ROOT/pages/faq.adoc
@@ -140,10 +140,10 @@ To prevent making this mistake you can disable `docker` completely by
 masking the `docker.service` systemd unit.
 
 .Example Butane config for disabling docker.service
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: docker.service
@@ -211,10 +211,10 @@ We don't recommend it, but if you really want to use it you can just
 unmask and enable it:
 
 .Example Butane config for unmasking dnsmasq.service
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: dnsmasq.service
@@ -262,10 +262,10 @@ modifications dynamically. For example, for an SELinux boolean you can use the
 following systemd unit that executes on every boot:
 
 .Example Butane config for dynamically applying SELinux boolean
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: setsebool.service
@@ -310,3 +310,17 @@ xref:storage.adoc[Configuring Storage] page for examples.
 
 See the xref:faq.adoc#_why_is_the_dnsmasq_service_systemd_unit_masked[Why is the `dnsmasq.service` systemd unit masked]
 entry for an example config to unmask this unit.
+
+[#wifi-fw]
+== How do I keep dropped wireless firmware?
+
+Some Wi-Fi firmwares were split into subpackages in Fedora 39 and Fedora 40. Fedora CoresOS will keep them in until Fedora 41, but display a warning message in the console if `NetworkManager-wifi` is layered without any other Wi-Fi firmware packages layered.
+
+To request the Wi-Fi firmware stay installed even when Fedora CoreOS drops these packages please follow the xref:sysconfig-enabling-wifi.adoc#_on_an_existing_fedora_coreos_system[steps to perform Wi-Fi enablement on an existing system].
+
+Once the packages are requested you can now disable the warning so it won't be checked on subsequent boots.
+
+[source, text]
+----
+sudo systemctl disable coreos-check-wireless-firmwares.service
+----
diff --git a/modules/ROOT/pages/getting-started.adoc b/modules/ROOT/pages/getting-started.adoc
index e44d2eb3..e34570b2 100644
--- a/modules/ROOT/pages/getting-started.adoc
+++ b/modules/ROOT/pages/getting-started.adoc
@@ -8,7 +8,7 @@ There are three Fedora CoreOS (FCOS) update streams available: `stable`, `testin
 
 Each stream has a canonical URL representing its current state in JSON format, known as "stream metadata". For example, the stream metadata URL for `stable` is: https://builds.coreos.fedoraproject.org/streams/stable.json
 
-For automating Fedora CoreOS installations, it is expected that you will interact with stream metadata. While Fedora CoreOS does automatic in-place updates, it is generally a good practice to start provisioning new machines from the latest images.
+For automating Fedora CoreOS installations, it is expected that you will interact with stream metadata. While Fedora CoreOS does automatic in-place updates, it is generally recommended to start provisioning new machines from the latest images.
 
 For more information on using stream metadata, see xref:stream-metadata.adoc[Stream Metadata].
 For more about the available streams, see xref:update-streams.adoc[Update Streams].
diff --git a/modules/ROOT/pages/grub-password.adoc b/modules/ROOT/pages/grub-password.adoc
index 8e82357f..75e5e00a 100644
--- a/modules/ROOT/pages/grub-password.adoc
+++ b/modules/ROOT/pages/grub-password.adoc
@@ -20,10 +20,10 @@ NOTE: `grub2-mkpasswd-pbkdf2` tool is a component of the `grub2-tools-minimal` p
 
 With the password hash ready, you can now create the Butane config.
 
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 grub:
   users:
     - name: root
diff --git a/modules/ROOT/pages/hostname.adoc b/modules/ROOT/pages/hostname.adoc
index 9f11efac..3d66889d 100644
--- a/modules/ROOT/pages/hostname.adoc
+++ b/modules/ROOT/pages/hostname.adoc
@@ -2,10 +2,10 @@
 
 To set a custom hostname for your system, use the following Butane config to write to `/etc/hostname`:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/hostname
diff --git a/modules/ROOT/pages/kernel-args.adoc b/modules/ROOT/pages/kernel-args.adoc
index 97b50c9d..a6de4a83 100644
--- a/modules/ROOT/pages/kernel-args.adoc
+++ b/modules/ROOT/pages/kernel-args.adoc
@@ -4,27 +4,14 @@
 
 You can specify kernel arguments in a Butane config using the `kernel_arguments` section.
 
-=== Example: Staying on cgroups v1
-
-Starting from June 2021, cgroups v2 is the default on new installations of Fedora CoreOS. Here's an example `kernelArguments` section which adds the `systemd.unified_cgroup_hierarchy=0` kernel argument so that the machine keeps using cgroups v1:
-
-[source,yaml]
-----
-variant: fcos
-version: 1.4.0
-kernel_arguments:
-  should_exist:
-    - systemd.unified_cgroup_hierarchy=0
-----
-
 === Example: Disabling all CPU vulnerability mitigations
 
 Here's an example `kernelArguments` section which switches `mitigations=auto,nosmt` to `mitigations=off` to disable all CPU vulnerability mitigations:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 kernel_arguments:
   should_exist:
     - mitigations=off
diff --git a/modules/ROOT/pages/live-booting.adoc b/modules/ROOT/pages/live-booting.adoc
index 31bdc1d1..72f36986 100644
--- a/modules/ROOT/pages/live-booting.adoc
+++ b/modules/ROOT/pages/live-booting.adoc
@@ -91,7 +91,7 @@ boot
 
 By default, the Fedora CoreOS live environment does not store any state on disk, and is reprovisioned from scratch on every boot. However, you may choose to store some persistent state (such as container images) in a filesystem that persists across reboots. For example, here's a Butane config that configures a persistent `/var`:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
 version: 1.1.0
@@ -123,6 +123,6 @@ In particular, note the following guidelines:
 
 Since the traditional FCOS upgrade process requires a disk, the live environment is not able to auto-update in place. For this reason, Zincati is not running there.
 
-For PXE-booted systems, it is recommended that images referenced in the PXE configuration are regularly refreshed. Once infrastructure and configurations are updated, the live PXE instance simply needs to be rebooted in order to start running the new FCOS version.
+For PXE-booted systems, it is recommended that images referenced in the PXE configuration are regularly refreshed. Once infrastructure and configurations are updated, the live PXE instance only needs to be rebooted in order to start running the new FCOS version.
 
 For ISO-booted systems, the ISO image used to boot the live environment should be periodically refreshed, and the instance rebooted to update the running OS.
diff --git a/modules/ROOT/pages/major-changes.adoc b/modules/ROOT/pages/major-changes.adoc
index cca60bbd..807e1499 100644
--- a/modules/ROOT/pages/major-changes.adoc
+++ b/modules/ROOT/pages/major-changes.adoc
@@ -9,6 +9,69 @@ This list is in reverse chronological order to keep recent changes at the top.
 
 // To add a new change here, see the template at the end of the file.
 
+== cgroups v1 support disabled
+
+In systemd v256, cgroups v1 support was disabled.
+If you’ve opted out of the cgroups v2 migration in the past, your system will fail to boot after upgrading.
+You must update your kernel arguments before the update.
+
+.Update an existing system from cgroupsv1 to cgroupsv2 and immediately reboot
+
+[source,bash]
+----
+$ sudo rpm-ostree kargs --delete=systemd.unified_cgroup_hierarchy --reboot
+----
+
+=== Planning
+
+This change has been rolled out as part of the rebase to Fedora 41.
+
+|===
+|Update Stream |Targeted release date
+
+|`next` | 41.20240916.1.0 (Sep 16, 2024)
+|`testing`| 41.20241027.2.0 (Oct 28, 2024)
+|`stable`| 41.20241027.3.0 (Nov 08, 2024)
+|===
+
+=== Notes
+
+See: https://github.com/coreos/fedora-coreos-tracker/issues/1715#issuecomment-2331986149[fedora-coreos-tracker/issues#1715].
+
+Detailed description of the change, the impacts, how to test, what manual actions are needed, etc.
+
+== Podman v5.0
+
+The Podman container runtime will be upgraded from v4 to v5. This is a https://blog.podman.io/2024/03/podman-5-0-has-been-released/[major release] that removes support for CNI networking in favor of Netavark.
+
+See also the https://fedoraproject.org/wiki/Changes/Podman5[Fedora Change] and the https://github.com/coreos/fedora-coreos-tracker/issues/1629[tracking issue].
+
+=== Planning
+
+This change will be rolled out together with the rebase to Fedora 40.
+
+|===
+|Update Stream |Targeted release date
+
+|`next` | 40.20240322.1.0 (Mar 24, 2024)
+|`testing`| 40.20240416.2.0 (Apr 22, 2024)
+|`stable`| 40.20240416.3.1 (May 07, 2024)
+|===
+
+=== Notes
+
+The full release notes for Podman v5 are available https://github.com/containers/podman/releases/tag/v5.0.0[on GitHub] and the breaking changes are explained in https://blog.podman.io/2024/03/podman-5-0-breaking-changes-in-detail/[Podman 5.0 breaking changes in detail]. Here is a summary of how this will impact Fedora CoreOS nodes:
+
+- CNI networking support has been removed and Netavark is now the only supported option.
+
+- Pasta is now the default rootless networking backend.
+
+- In the (unlikely) case that you were using podman machine inside of Fedora CoreOS, you will have to delete and re-create your podman machine. See https://blog.podman.io/2024/03/migration-of-podman-4-to-podman-5-machines/[Migration of Podman 4 to Podman 5 machines] for more details.
+
+- Support for cgroups v1 is deprecated and will removed in a future version.
+
+- Rollbacks to a previous version with Podman v4.x will likely require manual action.
+
 == System console changing to platform-specific defaults
 
 The system console setup will be changed to get a better user experience by default.
@@ -59,7 +122,7 @@ See the xref:emergency-shell.adoc[Emergency console access] documentation page f
 
 == Podman v4.0
 
-The Podman container runtime will be upgraded from v3 to v4. This is a https://podman.io/releases/2022/02/22/podman-release-v4.0.0.html[major release] that introduces backward incompatible changes to configuration files and APIs.
+The Podman container runtime will be upgraded from v3 to v4. This is a https://podman.io/release/2022/02/22/podman-release-v4.0.0[major release] that introduces backward incompatible changes to configuration files and APIs.
 
 See also the https://fedoraproject.org/wiki/Changes/Podman4.0[Fedora Change] and the https://github.com/coreos/fedora-coreos-tracker/issues/1106[tracking issue].
 
@@ -138,10 +201,10 @@ $ sudo touch /etc/coreos/iptables-legacy.stamp
 
 For new nodes that get deployed between now and when the migration happens, you can create the `/etc/coreos/iptables-legacy.stamp` file using Ignition to ensure they don't get migrated. After the migration, you can bring up new nodes on the legacy backend by manually setting the symbolic links via Ignition. Below is a Butane config that does both of these:
 
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/coreos/iptables-legacy.stamp
diff --git a/modules/ROOT/pages/managing-files.adoc b/modules/ROOT/pages/managing-files.adoc
index eef5c381..3ddc67eb 100644
--- a/modules/ROOT/pages/managing-files.adoc
+++ b/modules/ROOT/pages/managing-files.adoc
@@ -6,10 +6,10 @@ This example creates a directory with the default mode (set to `0755`: readable
 and recurseable by all), and writable only by the owner (by default `root`).
 
 .Example to create a directory with default ownership and permissions
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   directories:
   - path: /opt/tools
@@ -21,10 +21,10 @@ in-line. It also sets the file mode to `0644` (readable by all, writable by the
 owner) and sets ownership to `dnsmasq:dnsmasq`.
 
 .Example to create a file with in-line content
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /var/helloworld
@@ -46,10 +46,10 @@ is `sha512-` followed by the 128 hex characters given by the sha512sum command.
 The resulting file is made readable and executable by all.
 
 .Example to create a files from a remote source
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /opt/tools/transmogrifier
@@ -67,10 +67,10 @@ This is useful to let local processes invoke a program without altering their
 PATH environment variable.
 
 .Example to create a symbolic link
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   links:
     - path: /usr/local/bin/transmogrifier
@@ -85,10 +85,10 @@ https://github.com/coreos/butane/issues/380[butane#380] for the tracking issue
 in Butane for a future better syntax for this case.
 
 .Example to create directories with specific ownership
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   directories:
     - path: /home/builder/.config
diff --git a/modules/ROOT/pages/migrate-ah.adoc b/modules/ROOT/pages/migrate-ah.adoc
index eb890160..501b4cb0 100644
--- a/modules/ROOT/pages/migrate-ah.adoc
+++ b/modules/ROOT/pages/migrate-ah.adoc
@@ -24,10 +24,10 @@ ssh_authorized_keys:
 This can be manually translated into a `passwd` node within the Butane config:
 
 .Example of users:
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core
diff --git a/modules/ROOT/pages/os-extensions.adoc b/modules/ROOT/pages/os-extensions.adoc
index 7e3605df..2843a323 100644
--- a/modules/ROOT/pages/os-extensions.adoc
+++ b/modules/ROOT/pages/os-extensions.adoc
@@ -7,7 +7,7 @@ However, in some cases it is necessary to add software to the base OS itself. Fo
 To do this, you can use https://coreos.github.io/rpm-ostree/[`rpm-ostree install`]. Consider these packages as "extensions": they extend the functionality of the base OS rather than e.g. providing runtimes for user applications. That said, there are no restrictions on which packages one can actually install. By default, packages are downloaded from the https://docs.fedoraproject.org/en-US/quick-docs/repositories/[Fedora repositories].
 
 To start the layering of a package, you need to write a systemd unit that executes the `rpm-ostree` command to install the wanted package(s).
-By default, with `rpm-ostree install`, changes are queued for the next boot. The `-A/--apply-live` option can be used to apply changes live *and* have them persist.
+Changes are applied to a new deployment and a reboot is necessary for those to take effect.
 
 == Example: Layering vim and setting it as the default editor
 
@@ -17,10 +17,10 @@ This example shows how to install the fully fledged `vim` text editor and how to
 
 NOTE: In the future, we will have a more Ignition-friendly method of doing this with stronger guarantees. See upstream issues https://github.com/coreos/butane/issues/81[butane#81] and https://github.com/coreos/fedora-coreos-tracker/issues/681[fedora-coreos-tracker#681] for more information.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     # Installing vim as a layered package with rpm-ostree
@@ -43,8 +43,9 @@ systemd:
         # if the package is already installed. This is useful if the package is
         # added to the root image in a future Fedora CoreOS release as it will
         # prevent the service from failing.
-        ExecStart=/usr/bin/rpm-ostree install --apply-live --allow-inactive vim
+        ExecStart=/usr/bin/rpm-ostree install -y --allow-inactive vim
         ExecStart=/bin/touch /var/lib/%N.stamp
+        ExecStart=/bin/systemctl --no-block reboot
 
         [Install]
         WantedBy=multi-user.target
diff --git a/modules/ROOT/pages/producing-ign.adoc b/modules/ROOT/pages/producing-ign.adoc
index ab0164c2..6a2cf72b 100644
--- a/modules/ROOT/pages/producing-ign.adoc
+++ b/modules/ROOT/pages/producing-ign.adoc
@@ -17,7 +17,7 @@ During the transpilation process, Butane verifies the syntax of the YAML file, w
 
 Once you have an Ignition (`.ign`) file, you can use it to boot an FCOS system in a VM or install it on bare metal.
 
-TIP: Try to plan your configuration with the full set of customization details before provisioning a Fedora CoreOS instance. But don't worry if you forgot something as you can simply fix the configuration and re-deploy the instance from a fresh image.
+TIP: Try to plan your configuration with the full set of customization details before provisioning a Fedora CoreOS instance. But don't worry if you forgot something as you can fix the configuration and re-deploy the instance from a fresh image.
 
 == Getting Butane
 
@@ -166,7 +166,7 @@ Invoke-RestMethod -Uri https://fedoraproject.org/fedora.gpg | gpg --import
 gpg --verify butane-x86_64-pc-windows-gnu.exe.asc
 ----
 
-== A simple example
+== Example
 
 Create a basic Ignition config that modifies the default Fedora CoreOS user `core` to allow this user to log in with an SSH key.
 
@@ -186,10 +186,10 @@ The SSH public key will be provisioned to the Fedora CoreOS machine (via Ignitio
 
 . Copy the following example into a text editor:
 +
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core
diff --git a/modules/ROOT/pages/provisioning-aws.adoc b/modules/ROOT/pages/provisioning-aws.adoc
index 370d396b..e13c5c3a 100644
--- a/modules/ROOT/pages/provisioning-aws.adoc
+++ b/modules/ROOT/pages/provisioning-aws.adoc
@@ -65,42 +65,107 @@ ssh core@<ip address>
 As user-data is limited to 16 KB, you may need to use an external source for your Ignition configuration.
 A common solution is to upload the config to a S3 bucket, as the following steps show:
 
-[source, bash]
 .Create a new s3 bucket
+[source, bash]
 ----
 NAME='instance1'
 aws s3 mb s3://$NAME-infra
 ----
 
-[source, bash]
 .Upload the Ignition file
+[source, bash]
 ----
 NAME='instance1'
 CONFIG='/path/to/config.ign' # path to your Ignition config
-aws s3 cp CONFIG s3://$NAME-infra/bootstrap.ign
+aws s3 cp $CONFIG s3://$NAME-infra/bootstrap.ign
 ----
 
 You can verify the file have been correctly uploaded:
-[source, bash]
+
 .List files in the bucket
+[source, bash]
 ----
 NAME='instance1'
 aws s3 ls s3://$NAME-infra/
 ----
 
 Then create a minimal Ignition config as follows:
-[source,yaml]
+
 .Retrieving a remote Ignition file from a s3 bucket
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 ignition:
   config:
     replace:
       source: s3://instance1-infra/bootstrap.ign
 ----
 
-Then you can launch the instance using the same command as xref:#_customized_example[], passing the minimal configuration you just created.
+.Format the remote Ignition file to json format
+[source, bash]
+----
+butane -p config.bu -o config.ign
+----
+
+You need to create a role that includes `s3:GetObject` permission, and attach it to the instance profile. See https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html#roles-creatingrole-service-cli[role creation document] for more information.
+
+.Create the instance profile
+[source,bash]
+----
+cat <<EOF >trustpolicyforec2.json
+{
+  "Version": "2012-10-17",
+  "Statement": {
+    "Effect": "Allow",
+    "Principal": {"Service": "ec2.amazonaws.com"},
+    "Action": "sts:AssumeRole"
+  }
+}
+EOF
+
+# Create the role and attach the trust policy that allows EC2 to assume this role.
+ROLE_NAME="my-role"
+aws iam create-role --role-name ${ROLE_NAME} --assume-role-policy-document file://trustpolicyforec2.json
+
+# Attach the AWS managed policy named AmazonS3ReadOnlyAccess to the role
+aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess --role-name ${ROLE_NAME}
+
+# Create the instance profile required by EC2 to contain the role
+PROFILE="my-instance-profile"
+aws iam create-instance-profile --instance-profile-name ${PROFILE}
+
+# Finally, add the role to the instance profile
+aws iam add-role-to-instance-profile --instance-profile-name ${PROFILE} --role-name ${ROLE_NAME}
+----
+
+To launch the instance, need to attach the created profile. From the command-line, use `--iam-instance-profile`.
+
+.Launching and customizing a new instance with remote Ignition file from a S3 bucket
+[source,bash]
+----
+NAME='instance1'
+SSHKEY='my-key'          # the name of your SSH key: `aws ec2 describe-key-pairs`
+IMAGE='ami-xxx'          # the AMI ID found on the download page
+DISK='20'                # the size of the hard disk
+REGION='us-east-1'       # the target region
+TYPE='m5.large'          # the instance type
+SUBNET='subnet-xxx'      # the subnet: `aws ec2 describe-subnets`
+SECURITY_GROUPS='sg-xxx' # the security group `aws ec2 describe-security-groups`
+USERDATA='/path/to/config.ign' # path to your Ignition config
+PROFILE='xxx-profile'    # the name of an IAM instance profile `aws iam list-instance-profiles`
+aws ec2 run-instances                     \
+    --region $REGION                      \
+    --image-id $IMAGE                     \
+    --instance-type $TYPE                 \
+    --key-name $SSHKEY                    \
+    --subnet-id $SUBNET                   \
+    --security-group-ids $SECURITY_GROUPS \
+    --user-data "file://${USERDATA}"      \
+    --iam-instance-profile Name=${PROFILE}     \
+    --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=${NAME}}]" \
+    --block-device-mappings "VirtualName=/dev/xvda,DeviceName=/dev/xvda,Ebs={VolumeSize=${DISK}}"
+----
 
 Once the first boot is completed, make sure to delete the configuration as it may contain sensitive data.
 See xref:#_configuration_cleanup[].
@@ -111,16 +176,17 @@ If you need to have secrets in your Ignition configuration you should store it i
 Once the instance has completed the first boot, clear the S3 bucket as any process or container running on the instance could access it.
 See the https://coreos.github.io/ignition/operator-notes/#secrets[Ignition documentation] for more advice on secret management.
 
-[source,bash]
 .Deleting the Ignition configuration from the s3 bucket
+[source,bash]
 ----
 NAME='instance1'
-aws s3 rm CONFIG s3://$NAME-infra/bootstrap.ign
+aws s3 rm s3://$NAME-infra/bootstrap.ign
 ----
 
 Optionnally, you can delete the whole bucket:
-[source,bash]
+
 .Deleting the s3 bucket
+[source,bash]
 ----
 NAME='instance1'
 aws s3 rb s3://$NAME-infra
diff --git a/modules/ROOT/pages/provisioning-gcp.adoc b/modules/ROOT/pages/provisioning-gcp.adoc
index 96d31322..bbdb311c 100644
--- a/modules/ROOT/pages/provisioning-gcp.adoc
+++ b/modules/ROOT/pages/provisioning-gcp.adoc
@@ -30,7 +30,8 @@ You can inspect the current state of an image family as follows:
 [source, bash]
 ----
 STREAM='stable'
-gcloud compute images describe-from-family --project "fedora-coreos-cloud" "fedora-coreos-${STREAM}"
+gcloud compute images describe-from-family \
+    --project "fedora-coreos-cloud" "fedora-coreos-${STREAM}"
 ----
 
 == Launching a VM instance
@@ -45,8 +46,12 @@ NOTE: Currently, we don't support logging in using SSH through the GCP web conso
 [source, bash]
 ----
 STREAM='stable'
-VM_NAME='fcos-node01'
-gcloud compute instances create --image-project "fedora-coreos-cloud" --image-family "fedora-coreos-${STREAM}" "${VM_NAME}"
+NAME='fcos-node01'
+ZONE='us-central1-a'
+gcloud compute instances create              \
+    --image-project "fedora-coreos-cloud"    \
+    --image-family "fedora-coreos-${STREAM}" \
+    --zone "${ZONE}" "${NAME}"
 ----
 
 TIP: You can find out the instance's assigned IP by running `gcloud compute instances list`
@@ -68,9 +73,14 @@ From the command-line, use `--metadata-from-file`:
 [source, bash]
 ----
 STREAM='stable'
-VM_NAME='fcos-node01'
+NAME='fcos-node01'
+ZONE='us-central1-a'
 CONFIG='example.ign'
-gcloud compute instances create --metadata-from-file "user-data=${CONFIG}" --image-project "fedora-coreos-cloud" --image-family "fedora-coreos-${STREAM}" "${VM_NAME}"
+gcloud compute instances create                \
+    --image-project "fedora-coreos-cloud"      \
+    --image-family "fedora-coreos-${STREAM}"   \
+    --metadata-from-file "user-data=${CONFIG}" \
+    --zone "${ZONE} "${NAME}"
 ----
 
 NOTE: By design, https://cloud.google.com/compute/docs/startupscript[startup scripts] are not supported on FCOS. Instead, it is recommended to encode any startup logic as systemd service units in the Ignition configuration.
diff --git a/modules/ROOT/pages/provisioning-raspberry-pi4.adoc b/modules/ROOT/pages/provisioning-raspberry-pi4.adoc
index 985c78ec..797028a6 100644
--- a/modules/ROOT/pages/provisioning-raspberry-pi4.adoc
+++ b/modules/ROOT/pages/provisioning-raspberry-pi4.adoc
@@ -9,7 +9,7 @@ U-Boot is the way the Raspberry Pi 4 has traditionally been booted. The https://
 
 == Updating EEPROM on Raspberry Pi 4
 
-The Raspberry Pi 4 uses an EEPROM to boot the system. The EEPROM/Firmware in the past https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md#2021-10-04---add-support-for-gpt-fat16-and-increase-usb-timeouts---beta[had problems reading a FAT16 EFI partition], which https://github.com/coreos/fedora-coreos-tracker/issues/993[FCOS uses]. For the best experience getting FCOS to run on the RPi4 please update the EEPROM to the latest version. To check if you have the latest version you can go to the https://github.com/raspberrypi/rpi-eeprom/releases[raspberrypi/rpi-eeprom releases page] and make sure the version reported by your Raspberry Pi on boot is from around the same date as the last release.
+The Raspberry Pi 4 uses an EEPROM to boot the system. The EEPROM/Firmware in the past https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2711/release-notes.md#2021-10-04---add-support-for-gpt-fat16-and-increase-usb-timeouts---beta[had problems reading a FAT16 EFI partition], which https://github.com/coreos/fedora-coreos-tracker/issues/993[FCOS uses]. For the best experience getting FCOS to run on the RPi4 please update the EEPROM to the latest version. To check if you have the latest version you can go to the https://github.com/raspberrypi/rpi-eeprom/releases[raspberrypi/rpi-eeprom releases page] and make sure the version reported by your Raspberry Pi on boot is from around the same date as the last release.
 
 The https://www.raspberrypi.org/documentation/computers/raspberry-pi.html#updating-the-bootloader[Raspberry Pi Documentation] recommends using the Raspberry Pi Imager for creating a boot disk that can be used to update the EEPROM. If you're on a flavor of Fedora Linux the Raspberry Pi Imager is packaged up and available in the repositories. You can install it with:
 
@@ -70,7 +70,7 @@ Now mount the ESP partition and copy the files over:
 
 [source, bash]
 ----
-FCOSEFIPARTITION=$(lsblk $FCOSDISK -J -oLABEL,PATH  | jq -r '.blockdevices[] | select(.label == "EFI-SYSTEM")'.path)
+FCOSEFIPARTITION=$(lsblk $FCOSDISK -J -oLABEL,PATH  | jq -r '.blockdevices[] | select(.label == "EFI-SYSTEM").path')
 mkdir /tmp/FCOSEFIpart
 sudo mount $FCOSEFIPARTITION /tmp/FCOSEFIpart
 sudo rsync -avh --ignore-existing /tmp/RPi4boot/boot/efi/ /tmp/FCOSEFIpart/
diff --git a/modules/ROOT/pages/provisioning-virtualbox.adoc b/modules/ROOT/pages/provisioning-virtualbox.adoc
index 8b7ae2ae..e14d484b 100644
--- a/modules/ROOT/pages/provisioning-virtualbox.adoc
+++ b/modules/ROOT/pages/provisioning-virtualbox.adoc
@@ -68,10 +68,10 @@ If your Ignition config is larger than this limit, you can host the config on an
 . Upload your Ignition config to an HTTPS server.
 . xref:remote-ign.adoc[Create a Butane pointer config] that specifies the URL of your full Ignition config:
 +
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 ignition:
   config:
     replace:
diff --git a/modules/ROOT/pages/provisioning-vmware.adoc b/modules/ROOT/pages/provisioning-vmware.adoc
index 0dcc8a0c..91f006d9 100644
--- a/modules/ROOT/pages/provisioning-vmware.adoc
+++ b/modules/ROOT/pages/provisioning-vmware.adoc
@@ -52,7 +52,7 @@ CONFIG_ENCODED=$(gzip -9c example.ign | base64 -w0 -)
 
 If your generated Ignition configuration is still too large, you will encounter an `Argument list too long` error or similar. The solution to that problem depends on whether you are working with vSphere or Workstation/Fusion.
 
-For vSphere the solution is simple because instead of inlining the configuration file within your shell, `govc` allows you to specify a path to a local file instead with the https://github.com/vmware/govmomi/blob/main/govc/USAGE.md#vmchange[`vm.change`]-command and will handle reading and writing it internally, circumventing any shell limitations.
+For vSphere, instead of inlining the configuration file within your shell, `govc` allows you to specify a path to a local file with the https://github.com/vmware/govmomi/blob/main/govc/USAGE.md#vmchange[`vm.change`]-command and will handle reading and writing it internally, circumventing any shell limitations.
 
 [source, bash]
 ----
@@ -110,9 +110,40 @@ ssh core@<ip address>
 
 This section shows how to use vSphere facilities to configure and run VMs from the command-line. Similar steps can be performed via the graphical UI too.
 
-=== Importing the OVA
+TIP: While the examples below use `govc session.login` to authenticate, you can also use environment variables to provide credentials. Check the https://github.com/vmware/govmomi/tree/main/govc#usage[official documentation] for details.
+
+=== Setting up a new VM
 
-The downloaded OVA has to be first imported into vSphere library:
+You can now deploy a new VM, starting from the OVA and the encoded Ignition configuration:
+
+[source, bash]
+----
+FCOS_OVA='./ova-templates/fedora-coreos-31.20200210.3.0-vmware.x86_64.ova'
+VM_NAME='fcos-node01'
+govc session.login -u 'user:password@host'
+govc import.ova -name ${VM_NAME} ${FCOS_OVA}
+govc vm.change -vm "${VM_NAME}" -e "guestinfo.ignition.config.data.encoding=${CONFIG_ENCODING}"
+govc vm.change -vm "${VM_NAME}" -e "guestinfo.ignition.config.data=${CONFIG_ENCODED}"
+----
+
+A new `fcos-node01` VM is now available for booting. Its hardware configuration can be further customized at this point, and then powered-up:
+
+[source, bash]
+----
+govc vm.info -e "${VM_NAME}"
+govc vm.power -on "${VM_NAME}"
+----
+
+If you set up an xref:authentication.adoc[SSH key] for the default `core` user, you can SSH into the VM and explore the OS:
+
+[source, bash]
+----
+ssh core@<ip address>
+----
+
+=== Using the OVA from the vSphere library
+
+In case you want to spawn multiple, different VMs based on the same base image you can import it into the vSphere library for easy reuse:
 
 [source, bash]
 ----
@@ -124,9 +155,7 @@ govc library.create "${LIBRARY}"
 govc library.import -n "${TEMPLATE_NAME}" "${LIBRARY}" "${FCOS_OVA}"
 ----
 
-=== Setting up a new VM
-
-You can now deploy a new VM, starting from the template in the library and the encoded Ignition configuration:
+Creating a new instance can now be done using the `govc library.deploy` command:
 
 [source, bash]
 ----
@@ -136,7 +165,7 @@ govc vm.change -vm "${VM_NAME}" -e "guestinfo.ignition.config.data.encoding=${CO
 govc vm.change -vm "${VM_NAME}" -e "guestinfo.ignition.config.data=${CONFIG_ENCODED}"
 ----
 
-Note: If the vcenter has multiple datacenters and datastores, you must specify them explicitly:
+Note: If the vCenter has multiple datacenters and datastores, you must specify them explicitly:
 [source, bash]
 ----
 # Get resource pool using `$ govc find / -type ResourcePool`
@@ -145,21 +174,6 @@ DATASTORE="datastore-129"
 govc library.deploy -pool=${RESOURCE_POOL} -ds=${DATASTORE} "${LIBRARY}/${TEMPLATE_NAME}" "${VM_NAME}"
 ----
 
-A new `fcos-node01` VM is now available for booting. Its hardware configuration can be further customized at this point, and then powered-up:
-
-[source, bash]
-----
-govc vm.info -e "${VM_NAME}"
-govc vm.power -on "${VM_NAME}"
-----
-
-If you set up an xref:authentication.adoc[SSH key] for the default `core` user, you can SSH into the VM and explore the OS:
-
-[source, bash]
-----
-ssh core@<ip address>
-----
-
 === First-boot networking and Ignition
 
 Ignition supports referencing remote content in configuration and fetching it at provisioning time.
@@ -194,7 +208,7 @@ For further information on first-boot networking, see https://coreos.github.io/a
 
 You may encounter problems with your Ignition configuration that require access to the system log which appears during first-boot. To make a copy of the system log you can attach a serial device to the VM before booting. vSphere as well as Workstation and Fusion allow this and will save the output to a file of your choice.
 
-To attach a serial device simply modify the hardware settings of the powered off VM and add a `Serial Port`. Select the destination and name of the file to be created. Afterwards power on the VM. When encountering an error, check the file you initially specified - it should contain a copy of the system log.
+To attach a serial device, modify the hardware settings of the powered off VM and add a `Serial Port`. Select the destination and name of the file to be created. Afterwards power on the VM. When encountering an error, check the file you initially specified - it should contain a copy of the system log.
 
 The serial device can also be added to the VM via `govc` as described in the https://github.com/vmware/govmomi/blob/master/govc/USAGE.md#deviceserialconnect[official usage documentation]:
 
@@ -221,12 +235,13 @@ that may not be compatible with older, unsupported VMware products.
 However, you can modify the image's OVF metadata to specify an older
 virtual hardware version.
 
-The VMware OVA is simply a tarball that contains the files `disk.vmdk` and
+The VMware OVA is a tarball that contains the files `disk.vmdk` and
 `coreos.ovf`. In order to edit the metadata used by FCOS as a guest VM, you
 should untar the OVA artifact, edit the OVF file, then create a new OVA file.
 
-The example commands below change the OVF hardware version from the preconfigured
-value to hardware version `13`. (Note: the defaults in the OVF are subject to change.)
+The example commands below change the OVF hardware version from the preconfigured value to hardware version `13`.
+
+NOTE: The defaults in the OVF are subject to change.
 
 [source,bash,subs="attributes"]
 ----
diff --git a/modules/ROOT/pages/proxy.adoc b/modules/ROOT/pages/proxy.adoc
index 24cd6ae5..8c4cf38b 100644
--- a/modules/ROOT/pages/proxy.adoc
+++ b/modules/ROOT/pages/proxy.adoc
@@ -6,12 +6,12 @@ This is best done by defining a single file with required environment variables
 
 == Defining common proxy environment variables
 
-This common file has to be subsequently referenced explicitly by each service that requires internet access thereby encouraging least privilege best practices.
+This common file has to be subsequently referenced explicitly by each service that requires internet access.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/example-proxy.env
@@ -32,10 +32,10 @@ https://github.com/coreos/zincati[Zincati] polls for OS updates, and https://git
 
 TIP: You may be able to use local file references to systemd units instead of inlining them. See xref:tutorial-services.adoc#_using_butanes__files_dir_parameter_to_embed_files[Using butane's `--files-dir` Parameter to Embed Files] for more information.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: rpm-ostreed.service
@@ -62,10 +62,10 @@ systemd:
 
 If using docker then the `docker.service` drop-in is sufficient. If running Kubernetes with containerd (and no docker) then the `containerd.service` drop-in may be necessary.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: docker.service
@@ -88,10 +88,10 @@ systemd:
 
 Podman has no daemon and so configuration is for each individual service scheduled, and can be done as part of the full systemd unit definition.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: example-svc.service
diff --git a/modules/ROOT/pages/remote-ign.adoc b/modules/ROOT/pages/remote-ign.adoc
index 88bee015..852de896 100644
--- a/modules/ROOT/pages/remote-ign.adoc
+++ b/modules/ROOT/pages/remote-ign.adoc
@@ -7,10 +7,10 @@ The complete list of supported protocols and related options for remote Ignition
 The following examples show how to retrieve an Ignition file from a remote source. They are both set to replace the current configuration with a remote Ignition file.
 
 .Retrieving a remote Ignition file via HTTPS
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 ignition:
   config:
     replace:
@@ -18,10 +18,10 @@ ignition:
 ----
 
 .Retrieving a remote Ignition file via HTTPS with a custom certificate authority
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 ignition:
   config:
     replace:
@@ -37,10 +37,10 @@ NOTE: The certificate authorities listed here are not automatically added to the
 In some cases, if you need to merge a local configuration and one or several remote ones, you can use the `merge` rather than `replace` in a Butane config.
 
 .Retrieving a remote Ignition file via HTTPS and merging it with the current config
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 ignition:
   config:
     merge:
@@ -57,10 +57,10 @@ Retrieving remote Ignition files via plain HTTP is also possible as shown below.
 WARNING: Retrieving a remote Ignition config via HTTP exposes the contents of the config to anyone monitoring network traffic. When using HTTP, it is advisable to use the verification option to ensure the contents haven't been tampered with.
 
 .Retrieving a remote Ignition file via HTTP
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 ignition:
   config:
     replace:
@@ -72,10 +72,10 @@ ignition:
 If you need to retrieve a remote Ignition file but have no direct access to the remote host, you can specify a proxy for plain HTTP and/or HTTPS. You can also specify hosts that should be excluded from proxying.
 
 .Retrieving a remote Ignition file via a proxy
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 ignition:
   config:
     merge:
diff --git a/modules/ROOT/pages/running-containers.adoc b/modules/ROOT/pages/running-containers.adoc
index 051cc518..2da87221 100644
--- a/modules/ROOT/pages/running-containers.adoc
+++ b/modules/ROOT/pages/running-containers.adoc
@@ -9,10 +9,10 @@ The following Butane config snippet configures the systemd `hello.service` to ru
 TIP: You may be able to use local file references to systemd units instead of inlining them. See xref:tutorial-services.adoc#_using_butanes__files_dir_parameter_to_embed_files[Using butane's `--files-dir` Parameter to Embed Files] for more information.
 
 .Example for running busybox using systemd and podman
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: hello.service
@@ -38,10 +38,10 @@ systemd:
 
 https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html[Podman Quadlet] is functionality included in podman that allows starting containers via systemd using a systemd generator. The example below is the same `hello.service` that was previously shown but deployed via the Podman Quadlet functionality.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/containers/systemd/hello.container
@@ -66,10 +66,10 @@ storage:
 https://etcd.io[etcd] is not shipped as part of Fedora CoreOS. To use it, run it as a container, as shown below.
 
 .Butane config for setting up single node etcd
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: etcd-member.service
diff --git a/modules/ROOT/pages/storage.adoc b/modules/ROOT/pages/storage.adoc
index 22f0261b..34159005 100644
--- a/modules/ROOT/pages/storage.adoc
+++ b/modules/ROOT/pages/storage.adoc
@@ -17,19 +17,19 @@ Many of the examples below will reference a block device, such as `/dev/vda`. Th
 
 If your disk configuration is simple and uses the same disk the OS was booted from then the `/dev/disk/by-id/coreos-boot-disk` link can be used to conveniently refer to that device. This link is only available during provisioning for the purpose of making it easy to refer to the same disk the OS was booted from.
 
-In cases where you need to access other disks, the simplest thing to do is to boot a single machine with an Ignition configuration that just gives you SSH access, and inspect the block devices via e.g. the `lsblk` command.
+If you need to access other disks, you can boot a single machine with an Ignition configuration with only SSH access, and then inspect the block devices via e.g. the `lsblk` command.
 
-For physical hardware, a good best practice is to reference devices via the `/dev/disk/by-id/` or `/dev/disk/by-path` links.
+For physical hardware, it is recommended to reference devices via the `/dev/disk/by-id/` or `/dev/disk/by-path` links.
 
 == Setting up separate /var mounts
 
 Here's an example Butane config to set up `/var` on a separate partition on the same primary disk:
 
 .Adding a /var partition to the primary disk
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   disks:
   - # The link to the block device the OS was booted from.
@@ -61,10 +61,10 @@ storage:
 You can of course mount only a subset of `/var` into a separate partition. For example, to mount `/var/lib/containers`:
 
 .Adding a /var/lib/containers partition to the primary disk
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   disks:
   - device: /dev/disk/by-id/coreos-boot-disk
@@ -87,10 +87,10 @@ storage:
 Alternatively, you can also mount storage from a separate disk. For example, here we mount `/var/log` from a partition on `/dev/vdb`:
 
 .Adding /var/log from a secondary disk
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   disks:
   - device: /dev/vdb
@@ -110,10 +110,10 @@ storage:
 .Defining a disk with multiple partitions
 In this example, we wipe the disk and create two new partitions.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   disks:
     -
@@ -148,10 +148,10 @@ NOTE: You must have at least 4 GiB of RAM for root reprovisioning to work.
 Here's an example of moving from xfs to ext4, but reusing the same partition on the primary disk:
 
 .Changing the root filesystem to ext4
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   filesystems:
     - device: /dev/disk/by-partlabel/root
@@ -163,10 +163,10 @@ storage:
 Similarly to the previous section, you can also move the root filesystem entirely. Here, we're moving root to a RAID0 device:
 
 .Moving the root filesystem to RAID0
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   raid:
     - name: myroot
@@ -186,10 +186,10 @@ NOTE: You don't need the `path` or `with_mount_unit` keys; FCOS knows that the r
 If you want to replicate the boot disk across multiple drives for resiliency to drive failure, you need to mirror all the default partitions (root, boot, EFI System Partition, and bootloader code). There is special Butane config syntax for this:
 
 .Mirroring the boot disk onto two drives
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 boot_device:
   mirror:
     devices:
@@ -202,10 +202,10 @@ boot_device:
 This example demonstrates the process of creating the filesystem by defining and labeling the partitions, combining them into a RAID array, and formatting that array as ext4.
 
 .Defining a filesystem on a RAID storage device
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   disks:
   # This defines two partitions, each on its own disk. The disks are
@@ -248,10 +248,10 @@ storage:
 
 Here is an example to configure a LUKS device at `/var/lib/data`.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   luks:
     - name: data
@@ -273,10 +273,10 @@ NOTE: You must have at least 4 GiB of RAM for root reprovisioning to work.
 There is simplified Butane config syntax for configuring root filesystem encryption and pinning. Here is an example of using it to create a TPM2-pinned encrypted root filesystem:
 
 .Encrypting the root filesystem with a TPM2 Clevis pin
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 boot_device:
   luks:
     tpm2: true
@@ -285,10 +285,10 @@ boot_device:
 This is equivalent to the following expanded config:
 
 .Encrypting the root filesystem with a TPM2 Clevis pin without using boot_device
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   luks:
     - name: root
@@ -311,10 +311,10 @@ This next example binds the root filesystem encryption to PCR 7 which correspond
 NOTE: Binding for PCR 8 (UEFI Boot Component used to track commands and kernel command line) is not supported as the kernel command line changes with every OS update.
 
 .Encrypting the root filesystem with a TPM2 Clevis pin bound to PCR 7
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   luks:
     - name: root
@@ -346,10 +346,10 @@ $ sudo clevis luks list -d /dev/disk/by-partlabel/root
 Here is an example of the simplified config syntax with Tang:
 
 .Encrypting the root filesystem with a Tang Clevis pin
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 boot_device:
   luks:
     tang:
@@ -364,10 +364,10 @@ NOTE: For more information about setting up a Tang server, see https://github.co
 You can configure both Tang and TPM2 pinning (including multiple Tang servers for redundancy). By default, only the TPM2 device or a single Tang server is needed to unlock the root filesystem. This can be changed using the `threshold` key:
 
 .Encrypting the root filesystem with both TPM2 and Tang pins
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 boot_device:
   luks:
     tang:
@@ -384,13 +384,13 @@ boot_device:
 If you use Ignition to reconfigure or move the root partition, that partition is not automatically grown on first boot (see related discussions in https://github.com/coreos/fedora-coreos-tracker/issues/570[this issue]). In the case of moving the root partition to a new disk (or multiple disks), you should set the desired partition size using the `size_mib` field. If reconfiguring the root filesystem in place, as in the LUKS example above, you can resize the existing partition using the `resize` field:
 
 .Resizing the root partition to its maximum size
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   disks:
-    - device: /dev/vda
+    - device: /dev/disk/by-id/coreos-boot-disk
       partitions:
         - label: root
           number: 4
@@ -415,10 +415,10 @@ storage:
 This example creates a swap partition spanning all of the `sdb` device, creates a swap area on it, and creates a systemd swap unit so the swap area is enabled on boot.
 
 .Configuring a swap partition on a second disk
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   disks:
     - device: /dev/sdb
@@ -441,7 +441,7 @@ Fedora CoreOS systems can be configured to mount network filesystems such as NFS
 
 .Creating a systemd unit to mount an NFS filesystem on boot.
 NOTE: The `.mount` file must be named based on the path (e.g. `/var/mnt/data` = `var-mnt-data.mount`)
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
 version: 1.3.0
@@ -463,7 +463,7 @@ systemd:
 ----
 
 .Creating a systemd unit to mount an NFS filesystem when users access the mount point (automount)
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
 version: 1.3.0
@@ -501,10 +501,10 @@ systemd:
 This example configures a mirrored boot disk with a TPM2-encrypted root filesystem, overrides the sizes of the automatically-generated root partition replicas, and adds an encrypted mirrored `/var` partition which consumes the remainder of the disks.
 
 .Encrypted mirrored boot disk with separate /var
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 boot_device:
   luks:
     tpm2: true
@@ -519,14 +519,14 @@ storage:
         # Override size of root partition on first disk, via the label
         # generated for boot_device.mirror
         - label: root-1
-          size_mib: 8192
+          size_mib: 10240
         # Add a new partition filling the remainder of the disk
         - label: var-1
     - device: /dev/sdb
       partitions:
         # Similarly for second disk
         - label: root-2
-          size_mib: 8192
+          size_mib: 10240
         - label: var-2
   raid:
     - name: md-var
diff --git a/modules/ROOT/pages/sysconfig-configure-swaponzram.adoc b/modules/ROOT/pages/sysconfig-configure-swaponzram.adoc
index 0f26fae2..4cabeeec 100644
--- a/modules/ROOT/pages/sysconfig-configure-swaponzram.adoc
+++ b/modules/ROOT/pages/sysconfig-configure-swaponzram.adoc
@@ -4,10 +4,10 @@ In Fedora 33 some editions https://www.fedoraproject.org/wiki/Releases/33/Change
 
 The documentation for the config file format lives in the https://github.com/systemd/zram-generator/blob/main/man/zram-generator.conf.md[upstream documentation] along with a comprehensive https://github.com/systemd/zram-generator/blob/main/zram-generator.conf.example[example]. The most basic form of a configuration file that will set up a `zram0` device for swap is:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/systemd/zram-generator.conf
diff --git a/modules/ROOT/pages/sysconfig-configure-wireguard.adoc b/modules/ROOT/pages/sysconfig-configure-wireguard.adoc
index 41527674..7be8d8e1 100644
--- a/modules/ROOT/pages/sysconfig-configure-wireguard.adoc
+++ b/modules/ROOT/pages/sysconfig-configure-wireguard.adoc
@@ -53,10 +53,10 @@ NOTE: The `wg genpsk` command generates a PresharedKey that can only be used onc
 You can now configure your Ignition config to create the `wg0` configuration file:
 
 .Example FCOS WireGuard configuration
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/wireguard/wg0.conf
@@ -203,10 +203,10 @@ peer: <fcos_public_key>
 If you plan on forwarding all of your client's traffic through the FCOS instance you will need to enable IP Forwarding and you need to set and set some PostUp and PostDown directives:
 
 .Example FCOS WireGuard configuration with IP forwarding
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/sysctl.d/90-ipv4-ip-forward.conf
diff --git a/modules/ROOT/pages/sysconfig-enabling-wifi.adoc b/modules/ROOT/pages/sysconfig-enabling-wifi.adoc
new file mode 100644
index 00000000..404015ef
--- /dev/null
+++ b/modules/ROOT/pages/sysconfig-enabling-wifi.adoc
@@ -0,0 +1,123 @@
+= Enabling Wi-Fi
+
+The primary use for Fedora CoreOS has been driving server hardware in individual datacenters or cloud environments, which have high speed wired networking without the need for Wi-Fi enablement. Since there are many different types of wireless cards, link:https://github.com/coreos/fedora-coreos-tracker/issues/862[adding Wi-Fi enablement to Fedora CoreOS by default] would require many large firmware binaries to be installed for a non-standard use, which isn't ideal.
+
+On the other hand, Fedora CoreOS is versatile enough to run on smaller devices in IoT applications or in home labs where Wi-Fi may be required. In these cases it is easy enough to add a layer with the needed tools and firmware.
+
+== Adding Wi-Fi tools and firmware
+
+Typically enabling Wi-Fi on Fedora CoreOS involves adding the `NetworkManager-wifi` package along with the firmware package that corresponds to the wireless card in your system. Here is a list of some of the wireless firmware packages in Fedora:
+
+.Wi-Fi firmware packages in Fedora
+[source, text]
+----
+atheros-firmware - Firmware for Qualcomm Atheros WiFi/Bluetooth adapters
+b43-fwcutter - Firmware extraction tool for Broadcom wireless driver
+b43-openfwwf - Open firmware for some Broadcom 43xx series WLAN chips
+brcmfmac-firmware - Firmware for Broadcom/Cypress brcmfmac WiFi/Bluetooth adapters
+iwlegacy-firmware - Firmware for Intel(R) Wireless WiFi Link 3945(A)BG and 4965AGN adapters
+iwlwifi-dvm-firmware - DVM Firmware for Intel(R) Wireless WiFi adapters
+iwlwifi-mvm-firmware - MVM Firmware for Intel(R) Wireless WiFi adapters
+libertas-firmware - Firmware for Marvell Libertas SD/USB WiFi Network Adapters
+mt7xxx-firmware - Firmware for Mediatek 7600/7900 series WiFi/Bluetooth adapters
+nxpwireless-firmware - Firmware for NXP WiFi/Bluetooth/UWB adapters
+realtek-firmware - Firmware for Realtek WiFi/Bluetooth adapters
+tiwilink-firmware - Firmware for Texas Instruments WiFi/Bluetooth adapters
+atmel-firmware - Firmware for Atmel at76c50x wireless network chips
+zd1211-firmware - Firmware for wireless devices based on zd1211 chipset
+----
+
+For example, if a system has a Qualcomm wireless card then adding the `NetworkManager-wifi` and `atheros-firmware` packages would sufficiently enable the system for connecting to Wi-Fi. You can try to inspect your wireless card to determine what driver you need by running `lspci` (provided by the `pciutils` package) xref:debugging-with-toolbox.adoc[inside a Toolbx container].
+
+
+== When installing Fedora CoreOS
+
+For new systems the packages can be added using the xref:os-extensions.adoc[Adding OS Extensions] workflow. A NetworkManager configuration for the Wi-Fi connection will also need to be added so the system knows which wireless network to connect to. For more information on network configuration in Fedora CoreOS see xref:sysconfig-network-configuration.adoc[Network Configuration].
+
+An example Butane config that combines the extension and network configuration is shown below.
+
+.Butane config for Wi-Fi enablement
+[source,yaml,subs="attributes"]
+----
+variant: fcos
+version: {butane-latest-stable-spec}
+systemd:
+  units:
+    # Enable Wi-Fi in NetworkManager for an Intel wireless card
+    - name: rpm-ostree-install-wifi.service
+      enabled: true
+      contents: |
+        [Unit]
+        Description=Enable Wi-Fi
+        Wants=network-online.target
+        After=network-online.target
+        Before=zincati.service
+        ConditionPathExists=!/var/lib/%N.stamp
+        [Service]
+        Type=oneshot
+        RemainAfterExit=yes
+        ExecStart=/usr/bin/rpm-ostree install -y --allow-inactive NetworkManager-wifi iwlwifi-dvm-firmware
+        ExecStart=/bin/touch /var/lib/%N.stamp
+        ExecStart=/bin/systemctl --no-block reboot
+        [Install]
+        WantedBy=multi-user.target
+storage:
+  files:
+    - path: /etc/NetworkManager/system-connections/wifi-guest.nmconnection
+      mode: 0600
+      contents:
+        inline: |
+          [connection]
+          id=wifi-guest
+          type=wifi
+          autoconnect=true
+          [wifi]
+          cloned-mac-address=permanent
+          mode=infrastructure
+          ssid=guest
+          mac-address=ab:cd:01:02:03:04
+          [wifi-security]
+          auth-alg=open
+          key-mgmt=wpa-psk
+          psk=PASSWORD
+          [ipv4]
+          method=auto
+----
+
+NOTE: When installing a system and adding Wi-Fi enablement in this way the system will need to be on a wired network for the initial install since it will need to use the network to retrieve the Wi-Fi enabling packages.
+
+
+== On an existing Fedora CoreOS system
+
+If you have a system up already and want to add Wi-Fi capabilities (i.e. if you want to move it to a location without wired access) you can request the required packages.
+
+.Request NetworkManager-wifi and a specific Wi-Fi firmware
+[source, text]
+----
+$ sudo rpm-ostree install -y --allow-inactive \
+    NetworkManager-wifi iwlwifi-dvm-firmware
+----
+
+If you don't know what firmware to request you can request all the wireless firmware available in Fedora. Please note this approach is sub-optimal as it will add many unneeded packages on your system.
+
+.Request NetworkManager-wifi and all available Wi-Fi firmware
+----
+$ sudo rpm-ostree install -y --allow-inactive \
+    NetworkManager-wifi  \
+    atheros-firmware     \
+    b43-fwcutter         \
+    b43-openfwwf         \
+    brcmfmac-firmware    \
+    iwlegacy-firmware    \
+    iwlwifi-dvm-firmware \
+    iwlwifi-mvm-firmware \
+    libertas-firmware    \
+    mt7xxx-firmware      \
+    nxpwireless-firmware \
+    realtek-firmware     \
+    tiwilink-firmware    \
+    atmel-firmware       \
+    zd1211-firmware
+----
+
+Then reboot the system.
diff --git a/modules/ROOT/pages/sysconfig-network-configuration.adoc b/modules/ROOT/pages/sysconfig-network-configuration.adoc
index c0416539..e3996b9e 100644
--- a/modules/ROOT/pages/sysconfig-network-configuration.adoc
+++ b/modules/ROOT/pages/sysconfig-network-configuration.adoc
@@ -105,10 +105,10 @@ Any configuration provided via Ignition will be considered at a higher priority
 
 An example https://docs.fedoraproject.org/en-US/fedora-coreos/producing-ign/[Butane] config for the same static networking example that we showed above is:
 
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/ens2.nmconnection
@@ -247,10 +247,10 @@ ip=10.10.10.10::10.10.10.1:255.255.255.0:myhostname:ens2:none:8.8.8.8
 ==== Butane config
 
 .Template
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/${interface}.nmconnection
@@ -271,10 +271,10 @@ storage:
 ----
 
 .Rendered
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/ens2.nmconnection
@@ -317,10 +317,10 @@ bond=bond0:ens2,ens3:mode=active-backup,miimon=100
 ==== Butane config
 
 .Template
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/${bondname}.nmconnection
@@ -364,10 +364,10 @@ storage:
 ----
 
 .Rendered
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/bond0.nmconnection
@@ -432,10 +432,10 @@ bridge=br0:ens2,ens3
 ==== Butane config
 
 .Template
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/${bridgename}.nmconnection
@@ -476,10 +476,10 @@ storage:
 ----
 
 .Rendered
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/br0.nmconnection
@@ -541,10 +541,10 @@ team=team0:ens2,ens3
 ==== Butane config
 
 .Template
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/${teamname}.nmconnection
@@ -588,10 +588,10 @@ storage:
 ----
 
 .Rendered
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/team0.nmconnection
@@ -656,10 +656,10 @@ vlan=ens2.100:ens2
 ==== Butane config
 
 .Template
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/${interface}.${vlanid}.nmconnection
@@ -701,10 +701,10 @@ storage:
 ----
 
 .Rendered
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/ens2.100.nmconnection
@@ -768,10 +768,10 @@ vlan=bond0.100:bond0
 ==== Butane config
 
 .Template
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/${bondname}.${vlanid}.nmconnection
@@ -830,10 +830,10 @@ storage:
 ----
 
 .Rendered
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/system-connections/bond0.100.nmconnection
@@ -897,10 +897,10 @@ By default, FCOS will attempt to autoconfigure (DHCP/SLAAC) on every interface w
 
 
 .Disable NetworkManager autoconfiguration of ethernet devices
-[source, yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/NetworkManager/conf.d/noauto.conf
diff --git a/modules/ROOT/pages/sysconfig-setting-keymap.adoc b/modules/ROOT/pages/sysconfig-setting-keymap.adoc
index da8c0c52..1506f553 100644
--- a/modules/ROOT/pages/sysconfig-setting-keymap.adoc
+++ b/modules/ROOT/pages/sysconfig-setting-keymap.adoc
@@ -2,10 +2,10 @@
 
 To set your system keyboard layout (keymap), use the following Butane config to write to `/etc/vconsole.conf`:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/vconsole.conf
diff --git a/modules/ROOT/pages/sysctl.adoc b/modules/ROOT/pages/sysctl.adoc
index 8a11be88..3aca5c99 100644
--- a/modules/ROOT/pages/sysctl.adoc
+++ b/modules/ROOT/pages/sysctl.adoc
@@ -8,10 +8,10 @@ Persistent settings should be written under `/etc/sysctl.d/` during provisioning
 As an example, the xref:producing-ign.adoc[Butane] snippet below shows how to disable _SysRq_ keys:
 
 .Example: configuring kernel tunable to disable SysRq keys
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /etc/sysctl.d/90-sysrq.conf
diff --git a/modules/ROOT/pages/time-zone.adoc b/modules/ROOT/pages/time-zone.adoc
index adb1b5d6..2702ccfb 100644
--- a/modules/ROOT/pages/time-zone.adoc
+++ b/modules/ROOT/pages/time-zone.adoc
@@ -44,10 +44,10 @@ It is recommended that you set the same time zone across all your machines in th
 
 For example, you can set the time zone to `America/New_York` by using a Butane config like the following:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.4.0
+version: {butane-latest-stable-spec}
 storage:
   links:
     - path: /etc/localtime
diff --git a/modules/ROOT/pages/tutorial-autologin.adoc b/modules/ROOT/pages/tutorial-autologin.adoc
index 385af45f..8736c0dc 100644
--- a/modules/ROOT/pages/tutorial-autologin.adoc
+++ b/modules/ROOT/pages/tutorial-autologin.adoc
@@ -6,11 +6,11 @@ NOTE: Make sure that you have completed the steps described in the xref:tutorial
 
 Fedora CoreOS does not have a separate install disk. Instead, every instance starts from a generic disk image which is customized on first boot via https://github.com/coreos/ignition[Ignition].
 
-Ignition config files are written in JSON but are typically not user-friendly. Configurations are thus written in a simpler format, the Butane config, that is then converted into an Ignition config. The tool responsible for converting Butane configs into Ignition configs is naturally called Butane.
+Ignition config files are written in JSON but are typically not user-friendly. Configurations are thus written in a simpler format, the Butane config, that is then converted into an Ignition config. The tool responsible for converting Butane configs into Ignition configs is called Butane.
 
 == First Ignition config via Butane
 
-Let's create a very simple Butane config that will perform the following actions:
+Let's create a small Butane config that will perform the following actions:
 
 * Add a systemd dropin to override the default `serial-getty@ttyS0.service`.
     * The override will make the service automatically log the `core` user in to the serial console of the booted machine.
@@ -19,10 +19,10 @@ Let's create a very simple Butane config that will perform the following actions
 
 We can create a config file named `autologin.bu` now as:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: serial-getty@ttyS0.service
diff --git a/modules/ROOT/pages/tutorial-containers.adoc b/modules/ROOT/pages/tutorial-containers.adoc
index 770d1e21..7643b424 100644
--- a/modules/ROOT/pages/tutorial-containers.adoc
+++ b/modules/ROOT/pages/tutorial-containers.adoc
@@ -1,6 +1,6 @@
 = Setting up SSH access and starting containers at boot
 
-NOTE: Make sure that you have completed the steps described in the xref:tutorial-setup.adoc[initial setup page] before starting this tutorial.
+NOTE: Complete all the steps described in the xref:tutorial-setup.adoc[initial setup page] before starting this tutorial. Make sure you have create file `ssh-key.pub` following the instructions provided in the https://docs.fedoraproject.org/en-US/fedora-coreos/tutorial-setup/#_ssh_public_key[prerequisites] for the tutorial. We will use this key in the Butane configuration file that we are about to write.
 
 In this tutorial, we will set up SSH access and start a container at boot. Fedora CoreOS is focused on running applications/services in containers thus we recommend trying to run containers and avoid modifying the host directly. Running containers and keeping a pristine host layer makes automatic updates more reliable and allows for separation of concerns with the Fedora CoreOS team responsible for the OS and end-user operators/sysadmins responsible for the applications.
 
@@ -17,10 +17,10 @@ As usual, we will set up console autologin, a hostname, systemd pager configurat
 Similarly to what we did in the second provisioning scenario, we will write the following Butane config in a file called `containers.bu`:
 
 .Example with automatic serial console login, SSH key, and multiple systemd units
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core
diff --git a/modules/ROOT/pages/tutorial-services.adoc b/modules/ROOT/pages/tutorial-services.adoc
index 1c09148f..28b28474 100644
--- a/modules/ROOT/pages/tutorial-services.adoc
+++ b/modules/ROOT/pages/tutorial-services.adoc
@@ -9,7 +9,7 @@ In this tutorial, we will run a script on the first boot via a systemd service.
 
 == Writing the script
 
-Let's write a simple script that uses https://icanhazip.com/[icanhazip.com] to create an issue file to display as a prelogin message on the console and store it in `public-ipv4.sh`.
+Let's write a small script that uses https://icanhazip.com/[icanhazip.com] to create an issue file to display as a prelogin message on the console and store it in `public-ipv4.sh`.
 
 [source,bash]
 ----
@@ -52,10 +52,10 @@ EOF
 
 We can now create a Butane config that will include the script and systemd unit file contents by picking up the local `public-ipv4.sh` and `issuegen-public-ipv4.service` files using local file references. The final Butane config, stored in `services.bu`, will be:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 systemd:
   units:
     - name: serial-getty@ttyS0.service
diff --git a/modules/ROOT/pages/tutorial-updates.adoc b/modules/ROOT/pages/tutorial-updates.adoc
index a25b7b83..515984e6 100644
--- a/modules/ROOT/pages/tutorial-updates.adoc
+++ b/modules/ROOT/pages/tutorial-updates.adoc
@@ -10,7 +10,7 @@ One of the defining features of Fedora CoreOS is automatic updates. To see them
 
 [source,bash]
 ----
-RELEASE=$(curl https://builds.coreos.fedoraproject.org/prod/streams/stable/releases.json | jq -r .releases[-2].version)
+RELEASE=$(curl https://builds.coreos.fedoraproject.org/prod/streams/stable/releases.json | jq -r '.releases[-2].version')
 curl -O https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/${RELEASE}/x86_64/fedora-coreos-${RELEASE}-qemu.x86_64.qcow2.xz
 curl -O https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/${RELEASE}/x86_64/fedora-coreos-${RELEASE}-qemu.x86_64.qcow2.xz.sig
 ----
@@ -48,10 +48,10 @@ We will create a Butane config that will:
 
 Let's write this Butane config to a file called `updates.bu`:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core
diff --git a/modules/ROOT/pages/tutorial-user-systemd-unit-on-boot.adoc b/modules/ROOT/pages/tutorial-user-systemd-unit-on-boot.adoc
index 2e0e9964..dde4b4e4 100644
--- a/modules/ROOT/pages/tutorial-user-systemd-unit-on-boot.adoc
+++ b/modules/ROOT/pages/tutorial-user-systemd-unit-on-boot.adoc
@@ -1,6 +1,6 @@
 = Launching a user-level systemd unit on boot
 
-NOTE: Make sure that you have completed the steps described in the xref:tutorial-setup.adoc[initial setup page] before starting this tutorial.
+NOTE: Complete all the steps described in the xref:tutorial-setup.adoc[initial setup page] before starting this tutorial. Make sure you have create file `ssh-key.pub` following the instructions provided in the https://docs.fedoraproject.org/en-US/fedora-coreos/tutorial-setup/#_ssh_public_key[prerequisites] for the tutorial. We will use this key in the Butane configuration file that we are about to write.
 
 In this tutorial, we will set up a user level systemd unit for an unprivileged user. There are times when it's helpful to launch a user-level https://www.freedesktop.org/software/systemd/man/systemd.unit.html[systemd unit] without having to log in. For example, you may wish to launch a container that provides a network service or run an HPC job. For this setup, we will add the following to a Butane config:
 
@@ -11,10 +11,10 @@ In this tutorial, we will set up a user level systemd unit for an unprivileged u
 
 In this example, we will launch a systemd service for the user `sleeper`. First, let's create a user:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: sleeper
@@ -22,10 +22,10 @@ passwd:
 
 This will also create the home directory for the `sleeper` user. Then we can add the systemd unit:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /home/sleeper/.config/systemd/user/linger-example.service
@@ -44,10 +44,10 @@ storage:
 
 System services can be directly enabled in Butane configs but user level services have to be manually enabled for now:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 storage:
   directories:
     - path: /home/sleeper/.config/systemd/user/default.target.wants
@@ -68,10 +68,10 @@ storage:
 
 We set up lingering for the systemd user level instance so that it gets started directly on boot and stays running:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 storage:
   files:
     - path: /var/lib/systemd/linger/sleeper
@@ -80,10 +80,10 @@ storage:
 
 As the following directories do not exist yet, we will have to create them to tell Ignition to set the right ownership and permissions:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 storage:
   directories:
     - path: /home/sleeper/.config
@@ -116,10 +116,10 @@ storage:
 
 The final Butane config, stored in `user.bu`, will be:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
 variant: fcos
-version: 1.5.0
+version: {butane-latest-stable-spec}
 passwd:
   users:
     - name: core