# ADR 2 — Root filesystem Status: accepted ## Context `fedora-bootc` ships an empty `/usr/lib/bootc/install/`, so it does not set the type of the root filesystem. Every tool that installs the image needs this type. Without it, `bootc-image-builder` fails with `missing required info: DefaultRootFs`. xfs was the first choice, for three reasons: - The CoreOS and RHEL lineage use it for container hosts. - It works well with the many small files of an overlay image store. - It grows online. The build of 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 with features that kernels older than 6.10 refuse to mount. `bootc-image-builder` mounts the root filesystem on the *build host* to populate it. Thus the build fails there, because Proxmox 8 runs Debian 12 with kernel 6.8. This problem did not affect the disk itself. The disk would have booted correctly, because the VM runs a current Fedora kernel. The problem was that we could not produce the image. ## Decision Declare `root-fs-type = "ext4"` in `/usr/lib/bootc/install/00-corium.toml`. The image declares the type. The build command line does not pass it as `--rootfs`. Thus the image describes itself, and every installer agrees on the type without extra input. ## Consequences The image builds on any host with a kernel that is still in service. This includes the homelab Proxmox and the CI runners that people actually have. ext4 grows online with `resize2fs`, so you can still resize the disk of a node. For a Kubernetes node, the practical difference between ext4 and xfs is small. It is not a good reason to limit who can build the image.