Created attachment 1881775 [details]
Description of problem:
Gnome Software is unusable.
Version-Release number of selected component (if applicable):
How reproducible: always
Steps to Reproduce:
1. Open it.
Actual results: See attachment.
Expected results: It should work.
Before this, I was having bug 2083715. Now that one's fixed, and after following bug 2083715 comment 24 instructions, this new failure started happening. Renders gnome-software still unusable.
> gnome-software --quit
> env LANG=C gnome-software
08:12:54:0566 Gs /etc/PackageKit/Vendor.conf file not found
08:12:54:0826 Gs No AppStream data, try 'make install-sample-data' in data/
08:12:55:0528 Gs Only 0 apps for popular list, hiding
08:12:55:0529 Gs failed to get featured apps: no apps to show
08:12:55:0529 Gs Only 0 apps for recent list, hiding
08:12:55:0954 Gs Failed to get system: Failed to refine '*/*/*/system/*': failed to obtain lock 'metadata': Failed to create file ?/var/run/dnf-metadata.lock.N1ZFM1?: Permission denied
08:12:56:0065 flatpak Warning: Treating remote fetch error as non-fatal since runtime/net.lutris.Lutris.Runner.Wine/x86_64/beta is already installed: No such ref 'runtime/net.lutris.Lutris.Runner.Wine/x86_64/beta' in remote flathub-beta
08:12:57:0052 Gs failed to get installed apps: failed to obtain lock 'metadata': Failed to create file ?/var/run/dnf-metadata.lock.9ONHM1?: Permission denied
08:12:58:0863 Gs updates-shell: failed to get updates: failed to obtain lock 'metadata': Failed to create file ?/var/run/dnf-metadata.lock.ML1DM1?: Permission denied
I gues this can help too:
> rpm-ostree status -bv
Version: 36.20220516.0 (2022-05-16T00:43:32Z)
├─ repo-0 (2022-05-04T21:16:11Z)
├─ repo-1 (2022-05-16T00:16:44Z)
└─ repo-2 (2022-05-16T00:18:39Z)
├─ 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)
GPGSignature: 1 signature
Signature made lun 16 may 2022 01:43:39 using RSA key ID 999F7CBF38AB71F4
Good signature from "Fedora <email@example.com>"
LayeredPackages: codium direnv faac fdk-aac ffmpeg fish git-subrepo gnome-boxes
gnome-tweaks gstreamer1-libav gstreamer1-plugin-openh264
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
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
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:
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)
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:
name=Fedora $releasever openh264 (From Cisco) - $basearch
name=Fedora $releasever openh264 (From Cisco) - $basearch - Debug