Plasma Discover invalid reference for OCI when installed using the iso about main HOT 22 CLOSED

RPM to test: https://koji.fedoraproject.org/koji/taskinfo?taskID=103914869 Direct link for x86_64: https://koji.fedoraproject.org/koji/taskinfo?taskID=103915041

While this should be safe to test, I've not double checked the instructions so make sure to have backups, etc.

Testing instructions:

• Make /usr temporarily writable using: rpm-ostree usroverlay
• Download the RPMs from the link above. You need:

plasma-discover
plasma-discover-flatpak
plasma-discover-libs
plasma-discover-notifier
plasma-discover-rpm-ostree

• Install the updated RPMs: rpm -Uvh ./*.rpm
• Try out Discover. Restart the notifier with /usr/libexec/DiscoverNotifier --replace

I can confirm that the plugin works for unsigned images as it should (updates are seen and can be installed), and that Discover can now be opened without any errors on signed images. However, it doesn't seem to be able to actually see any available ostree updates on signed images for whatever reason, both in Discover and by the notifier

from main.

RPM to test: https://koji.fedoraproject.org/koji/taskinfo?taskID=103914869
Direct link for x86_64: https://koji.fedoraproject.org/koji/taskinfo?taskID=103915041

While this should be safe to test, I've not double checked the instructions so make sure to have backups, etc.

Testing instructions:

• Make /usr temporarily writable using: rpm-ostree usroverlay
• Download the RPMs from the link above. You need:

plasma-discover
plasma-discover-flatpak
plasma-discover-libs
plasma-discover-notifier
plasma-discover-rpm-ostree

• Install the updated RPMs: rpm -Uvh ./*.rpm
• Try out Discover. Restart the notifier with /usr/libexec/DiscoverNotifier --replace

from main.

So to the best of my understanding, this is an issue with Discover's handling of the OCI image reference, based on a bit of digging looking at what happens in the ostree handling of these image references (https://github.com/ostreedev/ostree-rs-ext/blob/main/lib/src/container/mod.rs) and Discover's handling of them (https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/backends/RpmOstreeBackend/OstreeFormat.cpp#L38) - to be clear I don't really understand either codebase very much, this is just what I've been able to dig up 😅

The image reference is a somewhat nuanced format supporting a variety of use cases, but I'll focus here on what I understand of it with regards to referencing containers from OCI registries. For this case there's a handful of the possible formats. In these examples <oci image> could be something like e.g. ghcr.io/ublue-os/silverblue-main:38

• ostree-unverified-image:registry:<oci image>
• ostree-unverified-image:docker://<oci image>
• ostree-unverified-registry:<oci image>
  These three formats are all equivalent and specify that the image isn't signed and as such a signature shouldn't be required / verified.
• ostree-remote-image:<ostree remote>:registry:<oci image>
• ostree-remote-image:<ostree remote>:docker://<oci image>
• ostree-remote-registry:<ostree remote>:<oci image>
  These three formats are all equivalent and specify that the image should have an ostree commit that has been signed according to the configuration of <ostree remote>
• ostree-image-signed:registry:<oci image>
• ostree-image-signed:docker://<oci image>
  These two formats are both equivalent and specify that the image should have a signature as specified for the registry in /etc/containers/policy.json (maybe also ~/.config/containers/policy.json? not sure).

(This list is a subset of possibilities, instead of registry or docker:// you could have other things like oci-archive, though I don't fully understand all the implications, e.g. how signing would work in those cases)

Discover currently only supports the ostree-unverified-registry>:<oci image> format, as far as I can tell looking at things here: https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/backends/RpmOstreeBackend/OstreeFormat.cpp#L38

I suspect that one thing that may be contributing to the issue here is that it looks like the ostree code when converting from in memory representations of these image references to a string, it defaults to using docker:// and does not use the ...-registry shorthands, so if that code were to parse ostree-unverified-registry:ghcr.io/ublue-os/silverblue-main:38 and write it back out, you'd get ostree-unverified-image:docker://ghcr.io/ublue-os/silverblue-main:38 instead; my best guess is that this can happen at some point (maybe when the ublue iso installs things? I don't think I've had rpm-ostree status change this way on my on my system that I rebased to from the silverblue iso), and that would lead to exposing the fact that Discover doesn't work with that format currently.

from main.

This should be fixed upstream and will come to Fedora 39 soon: https://bodhi.fedoraproject.org/updates/FEDORA-2023-efc1e99aa8

from main.

Oh right just to have the link here too, I did also open a ticket with Discover to track the issue there https://invent.kde.org/plasma/discover/-/issues/24

from main.

I've started looking at a fix with https://invent.kde.org/plasma/discover/-/merge_requests/591.

Will make Discover RPMs with the patch soon to make it easier to test on uBlue systems.

from main.

We've turned off the backend for now so the app doesn't crash:

• #282

And then we'll slipstream in what you recommend, thanks for your work on this!

from main.

Hi, it looks like a typo on our side - could you try the iso linked here: https://github.com/ublue-os/isogenerator/actions/runs/4645693395

direct link: https://github.com/ublue-os/isogenerator/suites/12108817031/artifacts/638007897

from main.

Is this an issue with the iso or with discover after installation?

from main.

Oh nevermind I see it, should be ostree-unverified-registry

from main.

The newest release shouldn't have this issue

from main.

Seems to be working here now

from main.

I am having this exact issue on a freshly-installed Kinoite image.
Relevant line: rpm-ostree-backend: Invalid reference for OCI container ostree format: "ostree-unverified-image:docker://ghcr.io/ublue-os/kinoite-main:38"

from main.

Just had another one of these and it's kinoite-nvidia. I've searched the org repos for ostree-unverified-image to see if we're accidentally setting this somewhere but so far no luck, any one have any other ideas?

EDIT: herm says he's seen this on chat with other folks too.

from main.

mm is there problem with the actual container, as per the docs the uri from the message looks ok:

ostree-unverified-registry:quay.io/exampleos/custom:latest - this will pull from a remote registry, and no signature will be required. In practice, this is just a shorthand for ostree-unverified-image:docker://quay.io/exampleos/custom:latest.

from main.

I can replicate the crash on a fresh VM by installing Kinoite and then running discover after first boot.

from main.

Thanks for testing!
Can you run the notifier / Discover in a terminal and paste here the logs that start with "rpm-ostree" ?
Thanks!

from main.

Thanks for testing! Can you run the notifier / Discover in a terminal and paste here the logs that start with "rpm-ostree" ? Thanks!

No problem :). Happy to help. Here's a log from Discover:

https://paste.centos.org/view/1d2743c2

And here's a log from the notifier:

https://paste.centos.org/view/b8ee4dc8

from main.

We've now documented the ostree URL formats at https://coreos.github.io/rpm-ostree/container/#url-format-for-ostree-native-containers

from main.

I get a 404 on the pastes above now but from memory there was nothing jumping out so I'll have to setup an environment to reproduce that.

from main.

Oh no, you're right. I forgot CentOS' paste service removes them after a day. I can get new logs if you'd like. Having documentation for the correct URL format is awesome. Thank you for getting that in place

I get a 404 on the pastes above now but from memory there was nothing jumping out so I'll have to setup an environment to reproduce that.

from main.

This landed in F39 stable repos and the Kinoite images so this should be fixed in ublue now.

from main.