Install/aleph: use `target-imgref` reference

[jbtrystram]

When creating a coreOS disk image with osbuild I get the following .boot-aleph.json:

{
  "image": "/tmp/tmpb29j6pi3/image",
  "kernel": "6.18.12-200.fc43.x86_64",
  "selinux": "disabled",
  "timestamp": null,
  "version": "43.20260301.20.dev1"
}

Which isn't really helpful. I suppose that's due to the way osbuild copy the image around before passing it to bootc install.
However in the logs I see: Installing image: docker://ostree-image-signed:docker://quay.io/fedora/fedora-coreos:testing-devel, which seems to originate from :

bootc/crates/lib/src/install.rs

Line 1617 in 864b7f0

println!("Installing image: {:#}", &target_imgref);

But target-imgref is the image to fetch for subsequent updates. So is that print output really correct ?

Also, let's add the input image labels as it often contains useful info injected by the build system (e.g. konflux).

For reference, here is what the coreOS aleph looks like now :

{
    "container-image": {
        "image-digest": "sha256:bb0e7c76a263f1308892f984e7ebfaa785ebf1f2ae2954188b8c58222512b872",
        "image-labels": {
            "com.coreos.inputhash": "fe9883169714c593d98058606e886b9747710ed15ab1b9cdbd7fa538fb435b3c",
            "com.coreos.osname": "fedora-coreos",
            "com.coreos.stream": "testing-devel",
            "containers.bootc": "1",
            "io.buildah.version": "1.42.2",
            "org.opencontainers.image.description": "Fedora CoreOS testing-devel",
            "org.opencontainers.image.revision": "233fe18749c7d2749581e4307c4cac60967acde4",
            "org.opencontainers.image.source": "git@github.com:jbtrystram/fedora-coreos-config.git",
            "org.opencontainers.image.title": "Fedora CoreOS testing-devel",
            "org.opencontainers.image.version": "43.20260301.20.dev0",
            "ostree.bootable": "1",
            "ostree.commit": "b89ba7137667d369dd5ff646141e3bfd8aa645a4bae6103d8d7cbb031aa5a2e0",
            "ostree.final-diffid": "sha256:12787d84fa137cd5649a9005efe98ec9d05ea46245fdc50aecb7dd007f2035b1"
        },
        "image-name": "docker://quay.io/fedora/fedora-coreos:testing-devel"
    },
    "osbuild-version": "174",
    "ostree-commit": "b89ba7137667d369dd5ff646141e3bfd8aa645a4bae6103d8d7cbb031aa5a2e0",
    "ref": "ostree-image-signed:docker://quay.io/fedora/fedora-coreos:testing-devel",
    "version": "43.20260301.20.dev0"
}

I am not saying bootc should do exactly this, simply suggesting improvements. Feel free to assign that to me I will look into it

[cgwalters]

Which isn't really helpful. I suppose that's due to the way osbuild copy the image around before passing it to bootc install.

Yes, a very painful problem...a lot of prior discussions about that, most recently IIRC in bootc-dev/bcvk#73

For now I guess we should include both source and target image refs?

Also we have some "detect osbuild" code right now and so we could probably do that and say a source in /tmp is something we just omit for now.

Also, let's add the input image labels as it often contains useful info injected by the build system (e.g. konflux).

Given a digested container image one can hopefully find all that other metadata?

The aleph I think had a decent rationale when it was introduced, but a general problem is especially when one talks about things like factory resets and such it starts to become less meaningful.

I was kind of toying with dropping it, or at least making that an option.

I don't personally have a strong opinion on this, if you do and want to make it more like the existing CoreOS one that's OK by me. But do we need to do that?

[jbtrystram]

For now I guess we should include both source and target image refs?

Also we have some "detect osbuild" code right now and so we could probably do that and say a source in /tmp is something we just omit for now.

Yeah, that sounds like a good short-term fix.

Given a digested container image one can hopefully find all that other metadata?

That's only true if that container still exists at the original location to be inspected.

I don't personally have a strong opinion on this, if you do and want to make it more like the existing CoreOS one that's OK by me. But do we need to do that?

I don't either. I've heard it's useful when debugging old systems.
Since I've been working on coreOS i think I've seen it used once in a barrier script. Let me do some more research and thinking

[jbtrystram]

I went ahead and wrote a small PR to fix this.
I guess down the line we can make the aleph optional behind an install config knob.