CoreOS gets stuck booting forever after installation

Problem

Yesterday, one of my CoreOS systems refuses to boot after an update.
Deployment 0 won’t boot, while Deployment 1 works as normal

Details

Here’s a screenshot of the behavior from a virtual machine created following the general steps listed in the Replication section further down this post.

Here’s the output of rpm-ostree status and bootc status of the affected physical system

#rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2026-07-04 16:07:34 UTC)
Deployments:
  ostree-image-signed:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:40f8190851a49d9a02c89f91171ccc9ec59b9090c96d551b8aa36a7641744f79
                  Version: 44.20260607.3.1 (2026-06-22T00:27:36Z)
          LayeredPackages: avahi wsdd

● ostree-image-signed:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:075bf47207b42f01b0bdf9c9d6705ba6dc6a6e7e87bc0b474c87f0d444357752
                  Version: 44.20260523.3.1 (2026-06-08T22:00:22Z)
          LayeredPackages: avahi wsdd
#bootc status
● Booted ostree
           Commit: cef08b5add4e66dc5c9ffbb51d7136e638f3d9092f6a1342354bf5856d82e231
  Rollback ostree
           Commit: 97e25d137182b587b683da7550f1f605a0e97695306a893fd07a7de3827e3316

Replication

  1. Create the ignition file with the following content
    •  #test.yml
       variant: fcos
       version: 1.6.0
       
       passwd:
        users:
         - name: fedora # Password is same as username
           groups:
            - wheel # "wheel" adds this user to the admin group
           password_hash: $6$aK.HN1rvo86y1s.8$OZTkf3NVtIycyRsicLu1mOuxaeqIimMQLhuV2fq/6Cx9sROPxYe2tbyJ4fp7HcgkjojN.LpC1FsQaTUpp1zVf1
       
       boot_device:
        luks:
         tpm2: true
         discard: true
       storage:
        disks:
         - device: /dev/disk/by-id/coreos-boot-disk
           partitions:
            - label: root
              number: 4
              size_mib: 12000
              resize: true
            - label: var
              size_mib: 0
        luks:
         - device: /dev/disk/by-partlabel/root
           name: root
           wipe_volume: true
           options: ["--hash","sha512"]
         - device: /dev/disk/by-partlabel/var
           name: var
           wipe_volume: true
           clevis:
            tpm2: true
           discard: true
           options: ["--hash","sha512"]
        filesystems:
          - device: /dev/mapper/var
            path: /var
            format: btrfs
            wipe_filesystem: true
            with_mount_unit: true
      
  2. Run the code block below can be used to embed the ignition above into a CoreOS installer disk image to be used on a bare metal system or virtual machine.
    • sudo dnf install coreos-installer butane
      rm -f ./test.ign
      butane -o ./test.ign ./test.yml
      image=$(coreos-installer download -s stable -f iso 2> /dev/null)
      # Automatic boot device selection
      ##  `--dest-device` is set to /dev/vda for the first virtio drive connected to UEFI Secure Boot + TPM2 enabled QEMU virtual machine
      ### Warning: the drive specified by --dest-device will be wiped 
      coreos-installer iso customize --dest-device /dev/vda --dest-ignition ./test.ign -o ./fcos-test-headless.iso ${image}
      
  3. Install from the ISO made in the previous step and reboot.

Notes

I’ve tested both the stable and next streams and both get booting forever as shown in the image in the Problem section
Used the latest iso images provided by coreos-installer from CoreOS Stable and Next streams as listed below.

# Stable stream
fedora-coreos-44.20260607.3.1-live-iso.x86_64.iso
# Next stream
fedora-coreos-44.20260621.1.1-live-iso.x86_64.iso

I think you are hitting a bug in systemd that I hit, I also have a separate /var.
The bug is a regression and is being tracked here 2487442 – fail to boot when / and /var are encrypted

Does that match what you are seeing?

Thanks Barry, this is likely the issue. @kenryo Can you report that in Issues · coreos/fedora-coreos-tracker · GitHub and add a link to the Bugzilla so that we can track getting the fix in stable? Thanks

My other CoreOS server just went down after updating to 44.20260621.3.1 an hour ago with the same error
So yeah, I’ll make that github issue in a bit.