I gues this can help too:

> rpm-ostree status -bv
State: idle
AutomaticUpdates: disabled
BootedDeployment:
● fedora:fedora/36/x86_64/silverblue
                   Version: 36.20220516.0 (2022-05-16T00:43:32Z)
                BaseCommit: e4dbe1f50a6f5fb0be04b7979c66da0fedf3b9e1d1ea8bec30684f46935cc229
                            ├─ repo-0 (2022-05-04T21:16:11Z)
                            ├─ repo-1 (2022-05-16T00:16:44Z)
                            └─ repo-2 (2022-05-16T00:18:39Z)
                    Commit: e072c47e02f70a20b7dbefe009d3466c7e42602ff0561f05eb30de82d07a7c43
                            ├─ fedora-cisco-openh264 (2022-04-07T16:52:38Z)
                            ├─ fedora-modular (2022-05-04T21:12:01Z)
                            ├─ updates-modular (2022-05-16T00:18:23Z)
                            ├─ updates (2022-05-16T01:00:22Z)
                            ├─ fedora (2022-05-04T21:16:11Z)
                            ├─ rpmfusion-free-updates (2022-05-13T10:06:59Z)
                            ├─ rpmfusion-free (2022-05-04T04:48:11Z)
                            ├─ rpmfusion-nonfree-updates (2022-05-13T10:33:29Z)
                            ├─ rpmfusion-nonfree (2022-05-04T05:11:55Z)
                            ├─ rpmfusion-nonfree-steam (2022-02-13T17:48:12Z)
                            ├─ gitlab.com_paulcarroty_vscodium_repo (2022-05-16T01:01:38Z)
                            └─ updates-archive (2022-05-16T01:26:27Z)
                    Staged: no
                 StateRoot: fedora
              GPGSignature: 1 signature
                            Signature made lun 16 may 2022 01:43:39 using RSA key ID 999F7CBF38AB71F4
                            Good signature from "Fedora <fedora-36-primary@fedoraproject.org>"
           LayeredPackages: codium direnv faac fdk-aac ffmpeg fish git-subrepo gnome-boxes
                            gnome-tweaks gstreamer1-libav gstreamer1-plugin-openh264
                            gstreamer1-plugins-bad-free-extras
                            gstreamer1-plugins-bad-free-fluidsynth
                            gstreamer1-plugins-bad-free-wildmidi
                            gstreamer1-plugins-bad-free-zbar
                            gstreamer1-plugins-bad-freeworld gstreamer1-plugins-entrans
                            gstreamer1-plugins-fc gstreamer1-plugins-good-extras
                            gstreamer1-plugins-ugly gtk-v4l hunspell-es langpacks-es
                            libreoffice ltunify nautilus-python openssh-askpass openssl
                            pipewire-codec-aptx podman-docker pre-commit realtime-setup
                            steam totem v4l-utils VirtualBox
             LocalPackages: nix-multi-user-2.8.0-1.x86_64 rpmfusion-free-release-36-1.noarch
                            rpmfusion-nonfree-release-36-1.noarch xow-0.4-1.fc32.x86_64

This looks similar to the issue I described in https://bugzilla.redhat.com/show_bug.cgi?id=2083715#c30

Check your gitlab.com_paulcarroty_vscodium_repo repo in /etc/yum.repos.d/. The default instructions for setting that up say to set `repo_gpgcheck=1`, which will cause the exact  error you're seeing. Change that to `repo_gpgcheck=0`.

Then refresh the metadata:

```
rpm-ostree cleanup --repomd
rpm-ostree refresh-md
rm -rf ~/.cache/gnome-software
```

And re-run `gnome-software`.

If it still doesn't work, `grep "repo_gpgcheck=1" /etc/yum.repos.d/*` and see if any other repos have repo_gpgcheck enabled and, if so, disable those.

Ahm indeed that unlocked the situation. Thanks!

Isn't that lowering security? Is this a fix or just a workaround?

Disabling the gpg signature check of the repodata seems like a step down security-wise, yes, but none of the Fedora repos (Silverblue and Workstation) have it enabled by default.

I suspect this is just a workaround for a bug in or limitation of librepo or libdnf, based on the logs I posted in 2083715.

Let's move this to the libdnf, it's failing there while trying to do something crucial with an unprivileged user.

Gnome Software uses packagekit, which should be a privileged process. But I'm not familiar with any Silverblue-specific setup which is probably going to be quite particular. I'd first check whether dnf really runs under an unprivileged user (and why), and then also the cachedir and persistdir with which dnf is configured.

(In reply to Lukáš Hrázký from comment #6)
> Gnome Software uses packagekit, which should be a privileged process. But
> I'm not familiar with any Silverblue-specific setup which is probably going
> to be quite particular. I'd first check whether dnf really runs under an
> unprivileged user (and why), and then also the cachedir and persistdir with
> which dnf is configured.

You are right the GNOME Software uses PackageKit, but not on the Silverblue. The Silverblue uses rpm-ostree in combination with direct libdnf calls.

The https://bugzilla.redhat.com/show_bug.cgi?id=2083715#c5 contains a little test program, which extracts what the gnome-software does when getting list of configured repos. It can reproduce the problem from that bug, specifically the `dnf_context_setup_sack_with_flags (context, state, DNF_CONTEXT_SETUP_SACK_FLAG_SKIP_RPMDB, &error)` can fail when it tries to refresh the cache, because the process is running as a regular user (that bug is about fighting on the cache data version, where the rpm-ostree used too old bundled libdnf).

This particular error (failed write into /var/run/...) is possibly caused by a different libdnf function.

The only thing the GNOME Software can do about this is to not call functions, which can regenerate the cache, or (as those functions are required for some things) it should use flags to avoid the cache re-create, but you can argue, in the light of the bug #2083715, that the cache refresh is required to work with accurate data, which I agree with.

As I understand this problem, and I can be wrong, the rpm-ostree (with root privileges) tries to refresh repo information, but it fails due to some issue with the repo. Then there comes the gnome-software (as a regular user), only wanting to read the data, but the libdnf recognizes data/cache mismatch, wants to refresh the cache first, but it fails on the permissions. The rpm-ostree call cannot fix it, because the repo is broken, but the libdnf call, made from the gnome-software, doesn't know that and tries the same as the rpm-ostree, just failing on privileges, thus a bit sooner than the rpm-ostree.

When running `grep "repo_gpgcheck=1" /etc/yum.repos.d/*` as in #c2 to identify potentially-problematic additional repos, my installation of Silverblue 36 returned:

```
/etc/yum.repos.d/fedora-cisco-openh264.repo:repo_gpgcheck=1
```

I believe this is one of the additional repositories that Fedora suggests (during install and when running Software for the first time), and therefore this may affect users who haven't gone “off-piste” by installing unsupported third-party repos.

(In reply to Grey Nicholson from comment #8)
> /etc/yum.repos.d/fedora-cisco-openh264.repo:repo_gpgcheck=1

Looking at the contents of this file, it mentions Fedora 33, and indeed this installation has been upgraded from Silverblue 33 (and earlier).

So this specific problem *may* only affect installations that opted into the additional repos at Silverblue version 33 or less, and then upgraded all the way up to 36.

These are the contents of that file in my case. I don't see any F33 mentions:

[fedora-cisco-openh264]
name=Fedora $releasever openh264 (From Cisco) - $basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-$releasever&arch=$basearch
type=rpm
enabled=1
metadata_expire=14d
repo_gpgcheck=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=True

[fedora-cisco-openh264-debuginfo]
name=Fedora $releasever openh264 (From Cisco) - $basearch - Debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-debug-$releasever&arch=$basearch
type=rpm
enabled=1
metadata_expire=14d
repo_gpgcheck=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=True