main: Plasma Discover invalid reference for OCI when installed using the iso

What happened?

When using the iso to install ublue a rpm-ostree-backend error occurs mentioning invalid reference for OCI container ostree format.

Relevant log output

$ plasma-discover
rpm-ostree-backend: Invalid reference for OCI container ostree format: "ostree-unverified-image:docker://ghcr.io/ublue-os/kinoite-nvidia:38"
1pm-ostree-backend: Starting transaction to check for updates
rpm-ostree-backend: Error: Can not start a transaction for resource with an invalid format. Please file a bug.
org.kde.plasma.libdiscover: transaction not part of the model RpmOstreeTransaction(0x55a798d95d40)
KCrash: Application 'plasma-discover' crashing...
The Wayland connection experienced a fatal error: Bad file descriptor

About this issue

Original URL
State: closed
Created a year ago
Comments: 22 (11 by maintainers)

Commits related to this issue

docs: Document ostree native container URL format Fixes: https://github.com/ostreedev/ostree-rs-ext/issues/507 Documents: https://github.com/ostreedev/ostree-rs-ext/blob/main/lib/src/container/mod.rs... — committed to travier/rpm-ostree by travier a year ago
docs: Document ostree native container URL format Fixes: https://github.com/ostreedev/ostree-rs-ext/issues/507 Documents: https://github.com/ostreedev/ostree-rs-ext/blob/main/lib/src/container/mod.rs... — committed to coreos/rpm-ostree by travier a year ago
docs: Document ostree native container URL format Fixes: https://github.com/ostreedev/ostree-rs-ext/issues/507 Documents: https://github.com/ostreedev/ostree-rs-ext/blob/main/lib/src/container/mod.rs... — committed to lukewarmtemp/rpm-ostree by travier a year ago
rpm-ostree: Fix ostree container support Improve ostree URL parser for the container use case to support all URL format for container native ostree cases. Some operations wiill fail on non-remote tr... — committed to KDE/discover by travier 7 months ago
rpm-ostree: Fix ostree container support Improve ostree URL parser for the container use case to support all URL format for container native ostree cases. Some operations wiill fail on non-remote tr... — committed to KDE/discover by travier 7 months ago

Most upvoted comments

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

EyeCantCU on Jul 26, 2023

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

travier on Jul 25, 2023

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

travier on Dec 15, 2023

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.

Pythoner6 on May 19, 2023

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

https://github.com/ublue-os/main/pull/282

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

castrojo on Jul 25, 2023

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.

travier on Jul 25, 2023

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

Pythoner6 on May 19, 2023