Allow users to override OS matching to a specific OS version for manifest purposes

[hanthor]

If you rename the OS when building custom images it will cause bootc image builder to fail to build. Instead of adding dozens of manifests it would be better to add a flag to allow the user to specify that this if a Fedora 42-based image or CentOS or Alma, etc.

[mvo5]

Thanks for the issue report and sorry for the slow reply. The latest code in bib will honor the ID_LIKE field and also inverted the logic for searching for lorax scripts - is this helping? If not, do you have an example bootc container that we could look at maybe? Fwiw, I'm not against adding a --override option but I would like to understand the problem(space) a little bit better as these options are API and that is forever :)

[hanthor]

Still need to test this. Issues were with bazzite and a few other personal custom imaged people were using

[thomascoe]

Even with ID_LIKE="fedora" in my os-release, I still get an error running bib on a container with a custom ID or VERSION_ID. For example, changing to ID=custom gives me this error:

[-] Manifest generation step
Message: Generating manifest manifest-anaconda-iso.json
2025/09/05 14:18:38 error: cannot build manifest: cannot get manifest: could not find def file for distro custom-42

This code in the manifestForISO function calls LoadImageDef only using the OSRelease.ID and OSRelease.VersionID, which seems to search for a matching .yaml file in data/defs using these distro/version parameters. I don't think there is anything attempting a similar lookup using ID_LIKE. https://github.com/osbuild/bootc-image-builder/blob/77724c4d2536c3b0c87e196151eadca7215d3f15/bib/cmd/bootc-image-builder/image.go#L497

Should there be a second attempt at calling LoadImageDef using the ID_LIKE field instead if the first attempt fails? The logic might need to be more complicated than just passing in c.SourceInfo.OSRelease.IDLike instead of c.SourceInfo.OSRelease.ID since the ID_LIKE field can contain a space-delimited list of multiple OS ID's.

Also if a downstream OS deviates its VERSION_ID from the OS it is deriving from, that could still cause this to fail even if we were checking ID_LIKE here. There's no standard "VERSION_ID_LIKE" field in os-release.

[strugee]

FWIW, I worked around this like so:

$ sudo podman run --rm -it --privileged --pull=newer --security-opt label=type:unconfined_t -v ./output:/output -v /var/lib/containers/storage:/var/lib/containers/storage --entrypoint sh quay.io/centos-bootc/bootc-image-builder:latest -c "/usr/bin/ln -s /usr/share/bootc-image-builder/defs/fedora-40.yaml /usr/share/bootc-image-builder/defs/seaglav-42.yaml; exec /usr/bin/bootc-image-builder --type anaconda-iso --use-librepo=True --rootfs ext4 --verbose --log-level debug ghcr.io/seagl/av-linux:latest"

Notice that the entrypoint is overridden to be sh, and then we just symlink the right file into place before running the real binary. (seaglav is the ID of my custom image.)

Obviously, this is bad and hacky.