fatal: Unhandled composefs setting: null

[mtalexan]

As of #3483, the composefs key is now mandatory in the image.yaml, and it must be set to composefs: false to retain the previous behavior. Not having the key finds the key "set" to null, which is an unsupported value, and results in the following error during build:

[...snip...]
Committing 28systemd-resolved-fallback_dns: /srv/src/config/overlay.d/28systemd-resolved-fallback_dns ... fe3816ec7f1fff635f471f26d21665b040be3c13572e30b42b59754ec898915a
Committing cosa-image-json: /srv/tmp/override/imagejson ... 8d747fe0544979ba75f72416f84a8b3d3792978740ce14577bbab6135cda6d8f
fatal: Unhandled composefs setting: null

It appears that no version of the fedora-coreos-config image-base.yaml (image.yaml does nothing but include it) actually has this now mandatory key.

I only discovered this issue when trying to use a newer version of the coreos-assembler on an older snapshot I had of the config repo, but now I don't see how any of the tests have been passing.

---

Is there a gap in the testing that's hiding a configuration issue in fedora-coreos-config now, or am I missing how fedora-coreos-config is avoiding it?

[mtalexan]

I'm running the quay.io/coreos-assembler/coreos-assembler:latest from 2023.09.11 (digest: 2d1ee8a77d31) when I see this error. I'm executing it on a config that works fine when run with the quay.io/coreos-assembler/coreos-assembler:latest from 2023.05.04-ish (digest: bdab4a8c6099).

I can see in the new 2023.09.11 image that the /usr/lib/coreos-assembler/image-default.yaml includes composefs: false, but it's still producing the error when run.
If I just re-run the identical build command right after getting this fatal error, it also gets past that exact point without even a complaint.

Is the expectation that the image-default.yaml supplies the necessary composefs: false if it's not set in the configuration's image.yaml, and there's just some bug with how it gets loaded?

[cgwalters]

Is the expectation that the image-default.yaml supplies the necessary composefs: false if it's not set in the configuration's image.yaml, and there's just some bug with how it gets loaded?

Yes.

[mtalexan]

Is the expectation that the image-default.yaml supplies the necessary composefs: false if it's not set in the configuration's image.yaml, and there's just some bug with how it gets loaded?

Yes.

Thanks for confirming. It's tough to know what's intended when there's so little documentation. Hopefully this will help when someone else runs into this same problem.

---

I tracked my specific problem down, and filed a separate Bug Issue for it: #3616

tl;dr When setting a prior build (i.e. one you buildfetch) the image.yaml/json defined in the current build is overwritten by the fetched build's image.yaml/json right before it gets used on the next build run after the buildfetch.
If that fetched build's image.yaml/json was from before the new composefs requirement was added, it won't comply with requirements, causing a failure during its use.