Repository navigation
Conversation
MkfsCall already honours customOpts in buildOptions, on both the linux and the fat branch, but nothing could ever set them: formatPartition hardcoded an empty slice and schema.Partition had no field to read one from. So a layout stage could choose the filesystem and its label and nothing else, and every mkfs flag beyond -L / -n was out of reach. That is a real gap, not a theoretical one. Kairos has to create ext4 filesystems with -O ^metadata_csum_seed, because an older e2fsprogs cannot mount a filesystem that carries that feature. Go code in the kairos monorepo does it through its own partitioner, but partitions created by a yip layout stage cannot, so the two paths disagree about what an ext4 filesystem looks like. Add mkfs_options to schema.Partition, carry it into the internal Partition the format pass works on, and hand it to MkfsCall as the custom options it was already prepared to append. Position is the one the existing code chose: after the label flag, before the device, which is where mkfs wants its options. Nothing changes for a partition that does not set it: the field is omitempty and a nil slice leaves buildOptions on the path it takes today. Signed-off-by: Ettore Di Giacinto <mudler@kairos.io>
jimmykarily
pushed a commit
to kairos-io/AuroraBoot
that referenced
this pull request
Oct 26, 2026
The first-boot reset config of raw disk images creates COS_PERSISTENT with LinuxImgFs (ext2). That constant is meant for the active/passive/ recovery image files; partitions use LinuxFs (ext4), as kairos-agent install does. On ext2 the persistent data (k3s/etcd, containerd, kubelet) has no journal and no extents, which makes unpacking images slow, stalls etcd fsync and leaves the filesystem inconsistent after a crash. COS_STATE stays ext2 for now. GRUB reads it on every boot, and yip's layout mkfs cannot pass -O ^metadata_csum_seed yet, so an image with e2fsprogs 1.47+ and a GRUB older than 2.12 without the backport would fail to boot (kairos-io/kairos#5476, mudler/yip#347). Signed-off-by: Kai Ehrhardt <ehrhardt.kai@gmail.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs: kairos-io/kairos#5476
Summary
MkfsCallalready appendscustomOptsinbuildOptions, on both the linux and the fat branch, but nothing could set them:formatPartitionhardcodedcustomOpts: []string{}andschema.Partitionhad no field to read one from. A layout stage could pick the filesystem and its label, and no othermkfsflag was reachable.This adds
mkfs_optionstoschema.Partition, carries it into the internalPartitionthe format pass uses, and hands it toMkfsCall. Position is the one the existing code already chose: after the label flag, before the device.The case that prompted it: Kairos creates ext4 filesystems with
-O ^metadata_csum_seed, because an oldere2fsprogscannot mount a filesystem carrying that feature. Go code in the kairos monorepo passes it through its own partitioner, but a partition created by a yiplayout:stage cannot, so the two paths produce different ext4 filesystems. The two call sites areimmucore/internal/utils/partitions.go(thekairos.ram.create_partitionspath) and the/oem/01_reset.yamlstage.Nothing changes for a partition that does not set the field: it is
omitempty, and a nil slice leavesbuildOptionson the path it takes today.How it was tested
go test ./pkg/plugins/ ./pkg/schema/, with the mkfs tools shimmed ontoPATH(this box has none, andApplydoesexec.LookPathbefore running).pkg/plugins,layoutlabel: 37 passed / 0 failed, including three new specs that pin the rendered command line: the ext branch (mkfs.ext4 -L COS_OEM -O ^metadata_csum_seed <dev>), the fat branch (mkfs.fat -n COS_GRUB -F 32 <dev>), and a partition with nofsLabel, which pins the option position when the label flag is absent. The mock console fails on any unregistered command, so these assert the exact string.pkg/schema: 11 passed / 0 failed, including a new spec that loadsmkfs_optionsfrom YAML, so the user-facing key is pinned and not just the Go field.formatPartitionline reverted to[]string{}, all three layout specs fail and the rest still pass. The wiring is load-bearing.gofmtis clean on every file I touched.pkg/schema/schema_test.gois listed bygofmt -lboth here and onmaster(a space-indented comment at line 206 that predates this branch); I left it alone rather than mix a reformat into this diff.Not covered: a real
mkfsrun. The suite mocks the console, so this proves the argument vector, not whatmkfsdoes with it.