Merge branch 'main' into fix-shellcheck-warnings

# By CoreOS Bot (31) and others
# Via Dusty Mabe
* main: (71 commits)
  antora: update software versions ✨
  antora: update software versions ✨
  antora: update software versions ✨
  major-changes: Update some older release & dates
  major-changes: Add a section for disabled cgroups v1
  kernel-args: Remove deprecated cgroups v1 example
  Fix the format
  aws: launch and customize a new instance with remote Ignition file from a S3 bucket
  antora: update software versions ✨
  alternatives: update doc to use the `alternatives` commands
  antora: update software versions ✨
  composefs: remove the kdump known issue section
  antora: update software versions ✨
  Minor RPI doc fix
  antora: update software versions ✨
  antora: update software versions ✨
  antora: update software versions ✨
  antora: update software versions ✨
  gcp: fix zone
  fix gcloud command
  ...

# Conflicts:
#	modules/ROOT/pages/tutorial-updates.adoc

.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

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

modules/ROOT/nav.adoc

@@ -27,13 +27,15 @@
 ** 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]
 ** xref:hostname.adoc[Setting a Hostname]
 ** 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]

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
+----

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:

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

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

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.

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