# ADR 2 — Root filesystem Status: accepted ## Context `fedora-bootc` ships an empty `/usr/lib/bootc/install/`, so the root filesystem type is undecided. Every tool that installs the image needs it: `bootc-image-builder` fails with `missing required info: DefaultRootFs`. xfs was the first choice — it is what the CoreOS and RHEL lineage use for container hosts, it handles the many-small-files pattern of an overlay image store well, and it grows online. Building the image with xfs failed on the target host: ``` XFS (loop0p4): Superblock has unknown incompatible features (0xc0) enabled. XFS (loop0p4): Filesystem cannot be safely mounted by this kernel. ``` `xfsprogs` on Fedora 44 creates filesystems using features that kernels older than 6.10 refuse to mount. `bootc-image-builder` mounts the root filesystem on the *build host* to populate it, so the build fails there — Proxmox 8 runs Debian 12 with kernel 6.8. Note what this is not: the resulting disk would have booted correctly, since the VM runs a current Fedora kernel. The image simply could not be produced. ## Decision Declare `root-fs-type = "ext4"` in `/usr/lib/bootc/install/00-corium.toml`. The type is declared in the image rather than passed as `--rootfs` on the build command line, so the image stays self-describing and every installer agrees without being told. ## Consequences The image builds on any host with a kernel in service, which includes the homelab Proxmox and CI runners people actually have. ext4 grows online with `resize2fs`, so resizing a node's disk still works. For a Kubernetes node, the practical difference between ext4 and xfs does not justify restricting who can build the image.