consider adding arch info to bootc status output

[dustymabe]

In Fedora CoreOS one step on our migration path to bootc is switching our existing systems to update from a OCI registry rather than OSTree. One nice thing about registry:tag endpoints is that (at least the way we've set it up) it's a manifest list that points to all the supported architectures.

Ultimately what this means is we lose the nice little side effect of knowing the machines architecture just from the status output.

For example before and after in the combined status output below:

core@localhost:~$ rpm-ostree status 
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Fri 2025-03-28 20:52:50 UTC)
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:testing
                   Digest: sha256:97cc8eaedf41c6f27d57c8dac0b740f91babe24b031bde447e0bec35acc60589
                  Version: 41.20250315.2.0 (2025-03-18T00:35:22Z)

  fedora:fedora/aarch64/coreos/testing
                  Version: 41.20250302.2.0 (2025-03-04T18:45:14Z)
                   Commit: a4a24122d3f48f6ee66b3f62482edf886e69206b50c67d100b88300dd64f7987
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1

So in the OCI deployment we don't get the nice aarch64 in the output.

Since bootc is the future I figured I'd start the discussion here about if we'd like to add something back here for that OR if we're happy without it in the status output. From that same system:

core@localhost:~$ sudo bootc status 
● Booted image: quay.io/fedora/fedora-coreos:testing
        Digest: sha256:97cc8eaedf41c6f27d57c8dac0b740f91babe24b031bde447e0bec35acc60589
       Version: 41.20250315.2.0 (2025-03-18 00:35:22 UTC)

  Rollback ostree
           Commit: a4a24122d3f48f6ee66b3f62482edf886e69206b50c67d100b88300dd64f7987

[cgwalters]

This is always identical to the output of running the arch binary right? How often do you log into a system and not know its hardware architecture?

Also a core principle for bootc is that we want to align to how container engines work where it makes sense, and podman/docker definitely don't show you this data in the default human-readable output like podman images etc.

That said, one thing I could imagine doing here is more rigorously tracking/recording the chain of manifest list -> manifest. I don't think podman/docker do this (the original manifest list including its digest is just fetched, parsed and discarded AFAIK) but why not do so? It's just a little bit more json, and at least in bootc status --verbose mode we could show the digest of the manifest list, which could make it easier to debug things. And in such a --verbose mode we could show the architecture too.

---

Anyways though I could imagine rendering it like this

$ sudo bootc status 
● Booted image: quay.io/fedora/fedora-coreos:testing
        Digest: sha256:97cc8eaedf41c6f27d57c8dac0b740f91babe24b031bde447e0bec35acc60589 (aarch64)
       Version: 41.20250315.2.0 (2025-03-18 00:35:22 UTC)

or so? The minor downside is it's slightly more mouse-navigation if one wants to copy-paste the sha digest, but eh. If someone wants to add this, fine by me...

But in the end it feels like this use case of "show me system status in a cool way" (beyond just what bootc owns) is the domain of other tools like https://github.com/dylanaraps/neofetch etc.

[cgwalters]

PR in #1239

[dustymabe]

PR in #1239

Nice. Thanks!

This is always identical to the output of running the arch binary right? How often do you log into a system and not know its hardware architecture?

Correct.. It's not a complicated problem to solve. Where I think this is valuable is less on the "I own the machine and I need to know the architecture" front, but more on the "people filing bug reports and making information really easy to consume" front. It helps the people trying to debug a problem. Having that little sliver there makes it just slightly easier to parse things and/or also make less assumptions when starting to debug.

[cgwalters]

more on the "people filing bug reports and making information really easy to consume" front.

Ah, OK. That makes sense but I think gets into the problem domain of other tools like https://github.com/sosreport/sos

(Though that one collects a lot by default, especially the full journal logs can sometimes leak a fair bit of information)

Also on this topic, sos is included in fedora-bootc, but not in FCOS...

Finally it's interesting to note here that the version+image from bootc status on its own is useful for inferring a fair bit of information (e.g. precise package/component versions) for users running generic+public base images like FCOS but is not at all useful in that way for people with custom images. Handling the latter case gets hard, especially if rechunking is used.