I got Bazzite installed on my old desktop and it was so painless I decided to try another container focused OS since my homelab machine is exclusively using containers. I didn’t intentionally plan to predominantly use containers, and figured this would be a fun experiment.

Since I’m experimenting on a spare machine (with a spinning disk!), I got Claude to inspect the current state and generate a butane config as a starting point.

Problem 1: tpm auto-unlock needs clevis

Claude generated this storage stanza:

storage:
  # LUKS root - clevis.tpm2 enables initrd unlock on every boot. Additional
  # PCR-bound enrollment via systemd-cryptenroll can be added post-install
  luks:
    - name: luks-root
      device: /dev/disk/by-partlabel/root
      wipe_volume: true
      clevis:
        tpm2: true

  filesystems:
    - path: /
      device: /dev/mapper/luks-root
      format: btrfs
      wipe_filesystem: true
      label: root
      with_mount_unit: true

Initially I wanted to use systemd-cryptenroll for uniformity with my other machines so I removed the clevis block from the luks block, but the boot process promptly failed with an error about being “unable to unlock the LUKS device”. Since the end goal was effectively the same (auto-unlock with TPM) I put the clevis stanza back in.

I could have put just a static LUKS key like I did with my kickstart config “changeme!”, but I decided to experiment with clevis since I never used it. When I first implemented LUKS TPM autounlocking Clevis was predominantly mentioned in the context of Clevis + Tang for network auto-unlock and I didn’t want that complexity so I used systemd-cryptenroll instead. It seems that Clevis on its own doesn’t actually need a service running so it’s kind of equivalent to systemd-cryptenroll?

Problem 2: useradd: cannot lock /etc/group

Claude generated this passwd stanza:

passwd:
  users:
    - name: root
      ssh_authorized_keys:
        - "ssh-ed25519 LOL-why-would-you-want-my-key noone@nowhere"

It looked fine, except the first boot process failed on changing users. I tried:

  • Changing the filesystem from btrfs to ext4
  • Replacing the root user from the butane config with core
    • likely a no-op because the message has files: ensureUsers: op(1), which to me indicates that it’s the first command run, before the specified user modifications happen
  • Downgrading to Version 43.20260331.3.1
    • Hit the same problem
  • Removing the passwd/users stanza entirely

Running systemctl start ignition-files.service from the emergency console did get me 2 different failure messages:

  • Can't create home directory /var/home; read-only partition, which disappeared the next time I started ignition-files, and
  • can't create file somewhere under /sysroot/var/home/core/ - I gave up at this point when the message didn’t change.

I suspect it has something to do with installing on a spinning disk with slower random IO, but that doesn’t really make sense because the changed files should be held in the file cache and reads would be consistent? Other people are reporting similar problems though from the comments there’s no conclusive fix yet.

Ultimately this error is what made me deem my experiment unsuccessful. No matter what I did this error kept on reappearing. If I wanted to spend more time I probably could have

Annoyance: Boot entries weren’t consistently updated

The very first install attempt created the entry as I expected:

Boot0002* Fedora CoreOS HD(2,GPT,9b9f8cb6-f2d2-426f-a296-462ff1b8b972,0x1000,0x3f800)/\EFI\FEDORA\SHIMX64.EFI
...
Boot000C* Fedora HD(2,GPT,9b9f8cb6-f2d2-426f-a296-462ff1b8b972,0x1000,0x3f800)/\EFI\FEDORA\SHIM.EFI0000424f

At some point this got corrupted into

Boot0002* Fedora CoreOS VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
...
Boot000C* Fedora HD(2,GPT,d314be6d-e858-4d8e-9f3a-97eee2ecbaa8,0x1000,0x3f800)/\EFI\Fedora\shim.efi0000424f

I don’t know where the UUID in entry C came from - it didn’t match any partition or show up in blkid, so I ended up deleting both the entries with efibootmgr -B and re-running coreos-installer. In a further inconsistency the installer didn’t create any entry this time so I copied someone’s command to add the CoreOS entry.

Boot0002* Fedora CoreOS HD(2,GPT,9b9f8cb6-f2d2-426f-a296-462ff1b8b972,0x1000,0x3f800)/\EFI\fedora\shimx64.efi

Conclusion

I probably won’t try CoreOS again until Fedora 45 comes out. The fact that the error messages are changing means there’s probably some case that is mostly handled. Because I get dropped to an emergency shell there’s not much tooling available on a separate physical system; I can’t even copy and paste the error message.

I’ll probably end up first trying CoreOS in a VM to see if it at least boots, though I suspect I wouldn’t be able to copy/paste.