I've an up-to-date Fedora 36 Silverblue installation and when a GNOME Software tries to install a package, it ends with an error: cannot create temporary file: /var/cache/rpm-ostree/solv/fedora-cisco-openh264.solv.XuN0fQ The same error blocks other tasks as well. I do not think the error comes from the gnome-software package, I did not find it there, thus I think it comes from the rpm-ostree. I tried to create a file there as a regular user, which failed (as expected) and then I tried to create a file in that directory as a root, which worked fine. Running some rpm-ostree commands (like installing libreoffice-calc) do not exhibit the problem, which is weird, I'd expect is also uses the same D-Bus service in the background, but I do not know any internals of the rpm-ostree. Do you have any hints how to debug this further, and/or how to fix it, please? Versions installed: gnome-software-42.1-1.fc36.x86_64 rpm-ostree-2022.8-1.fc36.x86_64
Created attachment 1878445 [details] Screenshot of the error message in GNOME Software
I have the same issue. When I disable the Cisco repository I get the error message seen in the screenshot.
*** Bug 2083743 has been marked as a duplicate of this bug. ***
I'm moving this to libdnf. From the [1], the libdnf and related packages changed: libdnf 0.66.0-1.fc36 -> 0.67.0-2.fc36. While the update contains a gnome-software update too, the related part of the code in the gnome-software did not change since 2021-03-31, thus for more than a year. There did change many other things in the gnome-software during that year. [1] https://github.com/fedora-silverblue/issue-tracker/issues/257#issuecomment-1123177734
Created attachment 1878557 [details] dnftest.c This is a minimal reproducer. The code, when run under Silveblue, fails on the dnf_context_setup_sack_with_flags() call. When I skip the call I get a list of repos, but it's not relevant, because the gnome-software calls this dnf_context_setup_sack_with_flags() semi-often.
For what it's worth, running the minimal test from the comment #5 under Fedora 35 Silverblue with libdnf-0.66.0-1.fc35.x86_64 works perfectly fine, no error is shown. There is one error I did not notice before, libdnf prints a runtime warning: 08:09:27:0664 libdnf Solv userdata length mismatch, read: 0 vs expected: 48
(In reply to Milan Crha from comment #6) > There is one error I did not notice before, libdnf prints a runtime warning: > > 08:09:27:0664 libdnf Solv userdata length mismatch, read: 0 vs expected: 48 One more observation: when I delete /var/cache/rpm-ostree/ and run the dnftest as root (thus it can write the files there), then it prints the repos just fine, with no error. The same when I run it as a regular user (as the files are "refreshed" by the run as root), the repos are listed. Nonetheless, I run gnome-software and then the quoted error is back. After that the dnftest also fails. If needed, I can try to figure out what precisely the gnome-software calls that it breaks the regenerated /var/cache/rpm-ostree/ files, but as long as Fedora 35 Silverblue, aka libdnf 0.66.0, doesn't have any problem with it...
Franto, you might be also interested in this from Silverblue QA point of view.
This may relate to a libsolv update, where cache files generated by older versions of libsolv are not readable by newer versions. Unfortunately such a bug will sail right through our current CI I think.
Created attachment 1878747 [details] /var/cache/rpm-ostree/solv contents Just to test, I changed the permissions of /var/cache/rpm-ostree/solv/ to 757 and ran Gnome Software. With these permissions, it runs correctly. But there are now files in this directory written under my user id, not root. Attached is the output of `ls -l` during the startup of Gnome Software. The first `ls -l` was run while Gnome Software shows "Software catalog is being downloaded" on the screen. The second `ls -l` was run after that was complete. Oddly it seems that some of the files begin the download as root, but then are completed as my username.
Hi, I come from the issue on the Fedora Silverblue issue tracker issue and I tried to investigate this issue today, I was told to share my findings, and ended up going through bodhi, the upstream fedora-silverblue and now here on bugzilla. So, I spent most of the day trying to figure out how to get Gnome Software back to a working state and, while I first tried downgrading gnome software and its rpm-ostree plugin, it only really worked after downgrading libdnf (it did keep working after I undid the gnome software downgrade). For more info, please check this comment on GitHub: https://github.com/fedora-silverblue/issue-tracker/issues/257#issuecomment-1124293928 The important part is that the current workaround is to manually downgrade libdnf by running `rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2022-7a894b6507` and that whatever broke gnome-software happened on the upgrade from 0.66.0 to 0.67.0. IMHO the best fix to current Silverblue 36 users would be to also downgrade libdnf on the base image and send an update, but yeah, the bug was introduced in libdnf 0.67.0. Hope that helps!
The problem likely is that rpm-ostree bundles its own libdnf (it looks like it has version 0.64.0) but we have changed the solv cache format in 0.67.0 (we have started to properly version it). Every time rpm-ostree is asked to generate metadata is uses 0.64.0 and generates the old format, Gnome Software then uses the new libdnf which sees the old format cache rejects it and starts to regenerate the metadata but it doesn't have permissions (I guess only rpm-ostree can do that). Unfortunately libdnf cannot use the old cache in general because it could have been generated with old libsolv and some advisory information could be missing (https://bugzilla.redhat.com/show_bug.cgi?id=2027445). I think the best solution would be for rpm-ostree to use 0.67.0 libdnf. Moving to rpm-ostree to see what they think.
I'm not very familiar with the Gnome Software and libdnf stack, but from I can gather there are two bugs outside of rpm-ostree at play here: * libdnf-0.67.0 not being able to parse its own metadata generated at a previous version * Gnome Software (a user process) trying to generate system-wide cache data in a location it doesn't own/control
(In reply to Luca BRUNO from comment #13) > * libdnf-0.67.0 not being able to parse its own metadata generated at a previous version FWIW the metadata are just a cache and we're working under the assumption we can just drop and re-generate them. Nothing else should really be touching that data, it's not a "public interface".
(In reply to Luca BRUNO from comment #13) If you clear the metadata with "sudo rpm-ostree cleanup -mb" and then run gnome-software, as a regular user, the cache is repopulated without the previously shown error message re. permissions.
(In reply to Luca BRUNO from comment #13) > I'm not very familiar with the Gnome Software and libdnf stack, but from I > can gather there are two bugs outside of rpm-ostree at play here: > * libdnf-0.67.0 not being able to parse its own metadata generated at a > previous version I won't call it a bug. It happens that libraries'/apps' private data changes and needs regeneration in newer version. > * Gnome Software (a user process) trying to generate system-wide cache data > in a location it doesn't own/control Above is a test program proving it's not GNOME Software, but libdnf. (In reply to amatej from comment #12) > I think the best solution would be for rpm-ostree to use 0.67.0 libdnf. I agree with that. This just shows that bundling libraries is a bad idea. From what you wrote I understood that the two versions are fighting on the cache version/format, one of them failing to regenerate, which is fine, because: a) regular user cannot and should not access that directory for writing; b) the next rpm-ostree call would regenerate the cache again, then the next time the "host system" libdnf accesses the cache would regenerate again, then the next rpm-ostree call would regenerate the cache again, then the next time... Just constant cache regeneration.
FEDORA-2022-af207692d6 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-af207692d6
(In reply to Fedora Update System from comment #17) > FEDORA-2022-af207692d6 has been submitted as an update to Fedora 36. > https://bodhi.fedoraproject.org/updates/FEDORA-2022-af207692d6 rpm-ostree override replace rpm-ostree-2022.9-1.fc36.x86_64.rpm rpm-ostree-libs-2022.9-1.fc36.x86_64.rpm Works. gnome-software comes up and runs normally (so far).
This command: rpm-ostree override replace rpm-ostree-2022.9-1.fc36.x86_64.rpm rpm-ostree-libs-2022.9-1.fc36.x86_64.rpm Gives me this error: error: Preparing D-Bus arguments: No such file or directory (os error 2)
(In reply to Eduardo Medina from comment #19) > This command: > > rpm-ostree override replace rpm-ostree-2022.9-1.fc36.x86_64.rpm > rpm-ostree-libs-2022.9-1.fc36.x86_64.rpm > > Gives me this error: > > error: Preparing D-Bus arguments: No such file or directory (os error 2) On the right column of https://bodhi.fedoraproject.org/updates/FEDORA-2022-af207692d6 is a link to the builds. You need to download the rpm's from https://koji.fedoraproject.org/koji/buildinfo?buildID=1966077 namely: https://kojipkgs.fedoraproject.org//packages/rpm-ostree/2022.9/1.fc36/x86_64/rpm-ostree-2022.9-1.fc36.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/rpm-ostree/2022.9/1.fc36/x86_64/rpm-ostree-libs-2022.9-1.fc36.x86_64.rpm
FEDORA-2022-af207692d6 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
Sorry to bother with my previous comment. I just updated and I don't see the "your system is outdated" like message (I use the system in Spanish) in update section of GNOME Software. Flatpak seems to work correctly. Now I can update my real machines and I will keep an eye on this. Thank you very much.
Hi. I applied the update but the problem persist in my Siverblue 36 workstation. If I run rpm-ostree upgrade I get a bunch of "Inactive base replacements": dnf-4.11.1-1.fc36.noarch dnf-automatic-4.11.1-1.fc36.noarch dnf-data-4.11.1-1.fc36.noarch dnf-plugins-core-4.1.0-1.fc36.noarch dnf-utils-4.1.0-1.fc36.noarch libdnf-debuginfo-0.66.0-1.fc36.x86_64 libdnf-debugsource-0.66.0-1.fc36.x86_64 libdnf-devel-0.66.0-1.fc36.x86_64 microdnf-3.8.1-1.fc36.x86_64 microdnf-debuginfo-3.8.1-1.fc36.x86_64 microdnf-debugsource-3.8.1-1.fc36.x86_64 python3-dnf-4.11.1-1.fc36.noarch python3-dnf-plugin-kickstart-4.0.16-1.fc36.noarch python3-dnf-plugin-leaves-4.1.0-1.fc36.noarch python3-dnf-plugin-local-4.1.0-1.fc36.noarch python3-dnf-plugin-modulesync-4.1.0-1.fc36.noarch python3-dnf-plugin-post-transaction-actions-4.1.0-1.fc36.noarch python3-dnf-plugin-rpmconf-4.0.16-1.fc36.noarch python3-dnf-plugin-show-leaves-4.1.0-1.fc36.noarch python3-dnf-plugin-showvars-4.0.16-1.fc36.noarch python3-dnf-plugin-snapper-4.0.16-1.fc36.noarch python3-dnf-plugin-system-upgrade-4.0.16-1.fc36.noarch python3-dnf-plugin-torproxy-4.0.16-1.fc36.noarch python3-dnf-plugin-tracer-4.0.16-1.fc36.noarch python3-dnf-plugin-versionlock-4.1.0-1.fc36.noarch python3-dnf-plugins-core-4.1.0-1.fc36.noarch python3-dnf-plugins-extras-common-4.0.16-1.fc36.noarch python3-hawkey-0.66.0-1.fc36.x86_64 python3-hawkey-debuginfo-0.66.0-1.fc36.x86_64 python3-libdnf-0.66.0-1.fc36.x86_64 python3-libdnf-debuginfo-0.66.0-1.fc36.x86_64 yum-4.11.1-1.fc36.noarch Notwithstanding, I can still update from the command prompt, but gnome-software remains with the issue.
(In reply to Boricua from comment #23) > Hi. I applied the update but the problem persist in my Siverblue 36 > workstation. If I run rpm-ostree upgrade I get a bunch of "Inactive base > replacements": > > dnf-4.11.1-1.fc36.noarch > dnf-automatic-4.11.1-1.fc36.noarch > dnf-data-4.11.1-1.fc36.noarch > dnf-plugins-core-4.1.0-1.fc36.noarch > dnf-utils-4.1.0-1.fc36.noarch > libdnf-debuginfo-0.66.0-1.fc36.x86_64 > libdnf-debugsource-0.66.0-1.fc36.x86_64 > libdnf-devel-0.66.0-1.fc36.x86_64 > microdnf-3.8.1-1.fc36.x86_64 > microdnf-debuginfo-3.8.1-1.fc36.x86_64 > microdnf-debugsource-3.8.1-1.fc36.x86_64 > python3-dnf-4.11.1-1.fc36.noarch > python3-dnf-plugin-kickstart-4.0.16-1.fc36.noarch > python3-dnf-plugin-leaves-4.1.0-1.fc36.noarch > python3-dnf-plugin-local-4.1.0-1.fc36.noarch > python3-dnf-plugin-modulesync-4.1.0-1.fc36.noarch > python3-dnf-plugin-post-transaction-actions-4.1.0-1.fc36.noarch > python3-dnf-plugin-rpmconf-4.0.16-1.fc36.noarch > python3-dnf-plugin-show-leaves-4.1.0-1.fc36.noarch > python3-dnf-plugin-showvars-4.0.16-1.fc36.noarch > python3-dnf-plugin-snapper-4.0.16-1.fc36.noarch > python3-dnf-plugin-system-upgrade-4.0.16-1.fc36.noarch > python3-dnf-plugin-torproxy-4.0.16-1.fc36.noarch > python3-dnf-plugin-tracer-4.0.16-1.fc36.noarch > python3-dnf-plugin-versionlock-4.1.0-1.fc36.noarch > python3-dnf-plugins-core-4.1.0-1.fc36.noarch > python3-dnf-plugins-extras-common-4.0.16-1.fc36.noarch > python3-hawkey-0.66.0-1.fc36.x86_64 > python3-hawkey-debuginfo-0.66.0-1.fc36.x86_64 > python3-libdnf-0.66.0-1.fc36.x86_64 > python3-libdnf-debuginfo-0.66.0-1.fc36.x86_64 > yum-4.11.1-1.fc36.noarch > > Notwithstanding, I can still update from the command prompt, but > gnome-software remains with the issue. Hi, please read this: https://github.com/fedora-silverblue/issue-tracker/issues/257#issuecomment-1126392386 . You did the override replace to downgrade libdnf (which gnome-software was using a newer version of) to the same version as rpm-ostree had bult-in, the actual fix to the issue was by upgrading the bult-in rpm-ostree libdnf to the newer one and that is what was shipped recently with rpm-ostree 2022.9, now you have the mismatched versions again by rpm-ostree using a newer version and gnome-software an older one (i.e. the same original problem, but with the reversed roles). To fix this on your system you also need to do the reverse step and reset the overrides. About the "Inactive Base Replacements": Basically, by installing the replacement libdnf with the bodhi link, it tried to also replace the all the packages in the update (there were other packages there like dnf, macrodfn and dnf plugins), including split packages, but it actually replace those that weren't in the image (well, it couldn't really do that) so that's why they show up as inactive replacements. If you had used the koji link for the libdnf build, you would only get libdnf and its split packages (so still some inactive ones, but fewer), if you had specifically used only the koji link for the specific libdnf rpm, it would have only tried that one (and so, only replace that and no inactive base replacements), do note that you would have to pick a compatible rpm (e.g., same architecture). As a tip, Inactive Base Replacements are not shown on `rpm-ostree status` but are on `rpm-ostree status -v`. If you have never manually done any other override or don't have any of those currently (including, for example, removing firefox from the base image, which is something that many do and I myself do due to preferring the Flatpak version), you can just run this to reset everything (do note that layered packages are different from overrides, layered packages will be kept): ``` rpm-ostree override reset ``` If you did make any other overrides and would prefer to keep them instead of redoing them from scratch, just reset the ones that came from the bodhi link (unfortunately for override reset you have to give every single package name individually =/, copy pasting might be your friend here) by running this command: ``` rpm-ostree override reset libdnf dnf-4.11.1-1.fc36.noarch dnf-automatic-4.11.1-1.fc36.noarch dnf-data-4.11.1-1.fc36.noarch dnf-plugins-core-4.1.0-1.fc36.noarch dnf-utils-4.1.0-1.fc36.noarch libdnf-debuginfo-0.66.0-1.fc36.x86_64 libdnf-debugsource-0.66.0-1.fc36.x86_64 libdnf-devel-0.66.0-1.fc36.x86_64 microdnf-3.8.1-1.fc36.x86_64 microdnf-debuginfo-3.8.1-1.fc36.x86_64 microdnf-debugsource-3.8.1-1.fc36.x86_64 python3-dnf-4.11.1-1.fc36.noarch python3-dnf-plugin-kickstart-4.0.16-1.fc36.noarch python3-dnf-plugin-leaves-4.1.0-1.fc36.noarch python3-dnf-plugin-local-4.1.0-1.fc36.noarch python3-dnf-plugin-modulesync-4.1.0-1.fc36.noarch python3-dnf-plugin-post-transaction-actions-4.1.0-1.fc36.noarch python3-dnf-plugin-rpmconf-4.0.16-1.fc36.noarch python3-dnf-plugin-show-leaves-4.1.0-1.fc36.noarch python3-dnf-plugin-showvars-4.0.16-1.fc36.noarch python3-dnf-plugin-snapper-4.0.16-1.fc36.noarch python3-dnf-plugin-system-upgrade-4.0.16-1.fc36.noarch python3-dnf-plugin-torproxy-4.0.16-1.fc36.noarch python3-dnf-plugin-tracer-4.0.16-1.fc36.noarch python3-dnf-plugin-versionlock-4.1.0-1.fc36.noarch python3-dnf-plugins-core-4.1.0-1.fc36.noarch python3-dnf-plugins-extras-common-4.0.16-1.fc36.noarch python3-hawkey-0.66.0-1.fc36.x86_64 python3-hawkey-debuginfo-0.66.0-1.fc36.x86_64 python3-libdnf-0.66.0-1.fc36.x86_64 python3-libdnf-debuginfo-0.66.0-1.fc36.x86_64 yum-4.11.1-1.fc36.noarch ``` Reboot, and then after that just a few more steps when you log in: Run `gnome-sotware --quit` (close Gnome Software so it doesn't interfere, including stopping it from running in the background), `rpm-ostree cleanup --repomd` (should fix any rpm-ostree cache conflicts between the two libdnf versions, by removing everything) and `rpm-ostree refresh-md` (gnome-software can't create `/var/cache/rpm-ostree/repomd/` and `/var/cache/rpm-ostree/solv/` if they don't exist, they were deleted when cleaning the repo cache and are recreated when refreshing it) and then run GNOME Software as normal. If even then you still have problems, it's likely due to Gnome Software's own cache, run the same steps as above, but just after running `gnome-software --quit`, delete the folder `~/.cache/gnome-software` (Enable hidden files in Nautilus if trying via GUI, so you can find the hidden .cache folder, Ctrl+H or the "Show hidden files"option in the hamburguer menu should allow you to enable that), then run the two other rpm-ostree commands in order. After that things should work.
Created attachment 1880019 [details] Still failing I've done all those steps and it still fails. Running from terminal: > env LANG=C gnome-software 06:41:15:0919 Gs /etc/PackageKit/Vendor.conf file not found 06:41:16:0200 Gs No AppStream data, try 'make install-sample-data' in data/ 06:41:36:0571 Gs failed to get featured apps: no apps to show 06:41:36:0572 Gs Only 0 apps for popular list, hiding 06:41:36:0572 Gs Only 0 apps for recent list, hiding 06:41:36:0978 Gs Failed to get system: Failed to refine '*/*/*/system/*': failed to obtain lock 'metadata': Failed to create file ?/var/run/dnf-metadata.lock.1GMRM1?: Permission denied 06:41:37:0497 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 06:41:38:0122 Gs failed to get installed apps: failed to obtain lock 'metadata': Failed to create file ?/var/run/dnf-metadata.lock.H7R6L1?: Permission denied 06:41:40:0346 Gs updates-shell: failed to get updates: failed to obtain lock 'metadata': Failed to create file ?/var/run/dnf-metadata.lock.B7ZCM1?: Permission denied Also you can see the UI still displays the failure, as in the attachment. This should 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>" 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
(In reply to Mateus Rodrigues Costa from comment #24) > (In reply to Boricua from comment #23) > > Hi. I applied the update but the problem persist in my Siverblue 36 > > workstation. If I run rpm-ostree upgrade I get a bunch of "Inactive base > > replacements": > > > > dnf-4.11.1-1.fc36.noarch > > dnf-automatic-4.11.1-1.fc36.noarch > > dnf-data-4.11.1-1.fc36.noarch > > dnf-plugins-core-4.1.0-1.fc36.noarch > > dnf-utils-4.1.0-1.fc36.noarch > > libdnf-debuginfo-0.66.0-1.fc36.x86_64 > > libdnf-debugsource-0.66.0-1.fc36.x86_64 > > libdnf-devel-0.66.0-1.fc36.x86_64 > > microdnf-3.8.1-1.fc36.x86_64 > > microdnf-debuginfo-3.8.1-1.fc36.x86_64 > > microdnf-debugsource-3.8.1-1.fc36.x86_64 > > python3-dnf-4.11.1-1.fc36.noarch > > python3-dnf-plugin-kickstart-4.0.16-1.fc36.noarch > > python3-dnf-plugin-leaves-4.1.0-1.fc36.noarch > > python3-dnf-plugin-local-4.1.0-1.fc36.noarch > > python3-dnf-plugin-modulesync-4.1.0-1.fc36.noarch > > python3-dnf-plugin-post-transaction-actions-4.1.0-1.fc36.noarch > > python3-dnf-plugin-rpmconf-4.0.16-1.fc36.noarch > > python3-dnf-plugin-show-leaves-4.1.0-1.fc36.noarch > > python3-dnf-plugin-showvars-4.0.16-1.fc36.noarch > > python3-dnf-plugin-snapper-4.0.16-1.fc36.noarch > > python3-dnf-plugin-system-upgrade-4.0.16-1.fc36.noarch > > python3-dnf-plugin-torproxy-4.0.16-1.fc36.noarch > > python3-dnf-plugin-tracer-4.0.16-1.fc36.noarch > > python3-dnf-plugin-versionlock-4.1.0-1.fc36.noarch > > python3-dnf-plugins-core-4.1.0-1.fc36.noarch > > python3-dnf-plugins-extras-common-4.0.16-1.fc36.noarch > > python3-hawkey-0.66.0-1.fc36.x86_64 > > python3-hawkey-debuginfo-0.66.0-1.fc36.x86_64 > > python3-libdnf-0.66.0-1.fc36.x86_64 > > python3-libdnf-debuginfo-0.66.0-1.fc36.x86_64 > > yum-4.11.1-1.fc36.noarch > > > > Notwithstanding, I can still update from the command prompt, but > > gnome-software remains with the issue. > > Hi, please read this: > https://github.com/fedora-silverblue/issue-tracker/issues/257#issuecomment- > 1126392386 . > > You did the override replace to downgrade libdnf (which gnome-software was > using a newer version of) to the same version as rpm-ostree had bult-in, the > actual fix to the issue was by upgrading the bult-in rpm-ostree libdnf to > the newer one and that is what was shipped recently with rpm-ostree 2022.9, > now you have the mismatched versions again by rpm-ostree using a newer > version and gnome-software an older one (i.e. the same original problem, but > with the reversed roles). To fix this on your system you also need to do > the reverse step and reset the overrides. > > About the "Inactive Base Replacements": Basically, by installing the > replacement libdnf with the bodhi link, it tried to also replace the all the > packages in the update (there were other packages there like dnf, macrodfn > and dnf plugins), including split packages, but it actually replace those > that weren't in the image (well, it couldn't really do that) so that's why > they show up as inactive replacements. If you had used the koji link for the > libdnf build, you would only get libdnf and its split packages (so still > some inactive ones, but fewer), if you had specifically used only the koji > link for the specific libdnf rpm, it would have only tried that one (and so, > only replace that and no inactive base replacements), do note that you would > have to pick a compatible rpm (e.g., same architecture). > As a tip, Inactive Base Replacements are not shown on `rpm-ostree status` > but are on `rpm-ostree status -v`. > > If you have never manually done any other override or don't have any of > those currently (including, for example, removing firefox from the base > image, which is something that many do and I myself do due to preferring the > Flatpak version), you can just run this to reset everything (do note that > layered packages are different from overrides, layered packages will be > kept): > > ``` > rpm-ostree override reset > ``` > > If you did make any other overrides and would prefer to keep them instead of > redoing them from scratch, just reset the ones that came from the bodhi link > (unfortunately for override reset you have to give every single package name > individually =/, copy pasting might be your friend here) by running this > command: > > ``` > rpm-ostree override reset libdnf dnf-4.11.1-1.fc36.noarch > dnf-automatic-4.11.1-1.fc36.noarch dnf-data-4.11.1-1.fc36.noarch > dnf-plugins-core-4.1.0-1.fc36.noarch dnf-utils-4.1.0-1.fc36.noarch > libdnf-debuginfo-0.66.0-1.fc36.x86_64 > libdnf-debugsource-0.66.0-1.fc36.x86_64 libdnf-devel-0.66.0-1.fc36.x86_64 > microdnf-3.8.1-1.fc36.x86_64 microdnf-debuginfo-3.8.1-1.fc36.x86_64 > microdnf-debugsource-3.8.1-1.fc36.x86_64 python3-dnf-4.11.1-1.fc36.noarch > python3-dnf-plugin-kickstart-4.0.16-1.fc36.noarch > python3-dnf-plugin-leaves-4.1.0-1.fc36.noarch > python3-dnf-plugin-local-4.1.0-1.fc36.noarch > python3-dnf-plugin-modulesync-4.1.0-1.fc36.noarch > python3-dnf-plugin-post-transaction-actions-4.1.0-1.fc36.noarch > python3-dnf-plugin-rpmconf-4.0.16-1.fc36.noarch > python3-dnf-plugin-show-leaves-4.1.0-1.fc36.noarch > python3-dnf-plugin-showvars-4.0.16-1.fc36.noarch > python3-dnf-plugin-snapper-4.0.16-1.fc36.noarch > python3-dnf-plugin-system-upgrade-4.0.16-1.fc36.noarch > python3-dnf-plugin-torproxy-4.0.16-1.fc36.noarch > python3-dnf-plugin-tracer-4.0.16-1.fc36.noarch > python3-dnf-plugin-versionlock-4.1.0-1.fc36.noarch > python3-dnf-plugins-core-4.1.0-1.fc36.noarch > python3-dnf-plugins-extras-common-4.0.16-1.fc36.noarch > python3-hawkey-0.66.0-1.fc36.x86_64 > python3-hawkey-debuginfo-0.66.0-1.fc36.x86_64 > python3-libdnf-0.66.0-1.fc36.x86_64 > python3-libdnf-debuginfo-0.66.0-1.fc36.x86_64 yum-4.11.1-1.fc36.noarch > ``` > > Reboot, and then after that just a few more steps when you log in: > > Run `gnome-sotware --quit` (close Gnome Software so it doesn't interfere, > including stopping it from running in the background), `rpm-ostree cleanup > --repomd` (should fix any rpm-ostree cache conflicts between the two libdnf > versions, by removing everything) and `rpm-ostree refresh-md` > (gnome-software can't create `/var/cache/rpm-ostree/repomd/` and > `/var/cache/rpm-ostree/solv/` if they don't exist, they were deleted when > cleaning the repo cache and are recreated when refreshing it) and then run > GNOME Software as normal. > > If even then you still have problems, it's likely due to Gnome Software's > own cache, run the same steps as above, but just after running > `gnome-software --quit`, delete the folder `~/.cache/gnome-software` (Enable > hidden files in Nautilus if trying via GUI, so you can find the hidden > .cache folder, Ctrl+H or the "Show hidden files"option in the hamburguer > menu should allow you to enable that), then run the two other rpm-ostree > commands in order. > > After that things should work. I can´t thank you enough. It's fixed. With the command "rpm-ostree override reset libdnf" and the later commands I was able to get Gnome Software again. However, I kept getting the "Inactive base replacements" from the command prompt. So, I repeated all the steps except "rpm-ostree override reset libdnf", which was already done, and now I have what seems to me normal behavior: [francisco@principal ~]$ rpm-ostree upgrade 2 metadata, 0 content objects fetched; 788 B transferred in 2 seconds; 0 bytes content written Inactive requests: fedora-workstation-repositories (already provided by fedora-workstation-repositories-35-3.fc36.noarch) Checking out tree e4dbe1f... done Enabled rpm-md repositories: fedora-cisco-openh264 fedora-modular updates-modular updates fedora rpmfusion-free-updates rpmfusion-free rpmfusion-nonfree-updates rpmfusion-nonfree updates-testing updates-archive Importing rpm-md... done rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2022-04-07T16:52:38Z solvables: 4 rpm-md repo 'fedora-modular' (cached); generated: 2022-05-04T21:12:01Z solvables: 825 rpm-md repo 'updates-modular' (cached); generated: 2022-05-16T00:18:23Z solvables: 1129 rpm-md repo 'updates' (cached); generated: 2022-05-16T01:00:22Z solvables: 8681 rpm-md repo 'fedora' (cached); generated: 2022-05-04T21:16:11Z solvables: 67992 rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2022-05-13T10:06:59Z solvables: 1 rpm-md repo 'rpmfusion-free' (cached); generated: 2022-05-04T04:48:11Z solvables: 506 rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2022-05-13T10:33:29Z solvables: 2 rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2022-05-04T05:11:55Z solvables: 225 rpm-md repo 'updates-testing' (cached); generated: 2022-05-16T02:48:22Z solvables: 15660 rpm-md repo 'updates-archive' (cached); generated: 2022-05-16T01:26:27Z solvables: 7806 Resolving dependencies... done No upgrade available. No need to delete folder `~/.cache/gnome-software` for a second time.
After following the steps outlined in comment #24, I still experience this issue. Issuing gnome-software --stop, rm -rf ~/.cache/gnome-software and re-running the 2 rpm-ostree commands do not resolve the issue.
(In reply to Geomancer626 from comment #27) > After following the steps outlined in comment #24, I still experience this > issue. Issuing gnome-software --stop, rm -rf ~/.cache/gnome-software and > re-running the 2 rpm-ostree commands do not resolve the issue. Hi @Geomancer626, I was having the same problem, but I was able to solve it today. The issue was that one of my installed repositories did not support Fedora 36, so the repo url returned a 404. When `rpm-ostree refresh-md` is run, it can't fetch the repository so doesn't create the cache. Then, when running gnome-software, it sees that the repo cache doesn't exist, tries to create it, but permission is denied. In my case, it was the Tailscale repo. Check your repos and disable any that don't support Fedora 36. Then, re-run `rpm-ostree cleanup --repomd` and `rpm-ostree refresh-md`, and retry gnome-software.
(In reply to Adam Israel from comment #28) > (In reply to Geomancer626 from comment #27) > > After following the steps outlined in comment #24, I still experience this > > issue. Issuing gnome-software --stop, rm -rf ~/.cache/gnome-software and > > re-running the 2 rpm-ostree commands do not resolve the issue. > > Hi @Geomancer626, > > I was having the same problem, but I was able to solve it today. > > The issue was that one of my installed repositories did not support Fedora > 36, so the repo url returned a 404. When `rpm-ostree refresh-md` is run, it > can't fetch the repository so doesn't create the cache. Then, when running > gnome-software, it sees that the repo cache doesn't exist, tries to create > it, but permission is denied. > > In my case, it was the Tailscale repo. Check your repos and disable any that > don't support Fedora 36. Then, re-run `rpm-ostree cleanup --repomd` and > `rpm-ostree refresh-md`, and retry gnome-software. Adam, Thank you for taking the time to respond back to me. I attempted to follow your suggestion, but my issue unfortunately appears to lie somewhere else based on the output of rpm-ostree refresh-md --- rpm-ostree refresh-md Enabled rpm-md repositories: fedora-cisco-openh264 fedora-modular updates-modular updates fedora protonvpn-fedora-stable rpmfusion-free-updates rpmfusion-free rpmfusion-nonfree-updates rpmfusion-nonfree phracek-PyCharm rpmfusion-nonfree-nvidia-driver rpmfusion-nonfree-steam google-chrome updates-archive Importing rpm-md... done rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2022-04-07T16:52:38Z solvables: 4 rpm-md repo 'fedora-modular' (cached); generated: 2022-05-04T21:12:01Z solvables: 825 rpm-md repo 'updates-modular' (cached); generated: 2022-05-16T00:18:23Z solvables: 1119 rpm-md repo 'updates' (cached); generated: 2022-05-17T01:07:21Z solvables: 7609 rpm-md repo 'fedora' (cached); generated: 2022-05-04T21:16:11Z solvables: 67992 rpm-md repo 'protonvpn-fedora-stable' (cached); generated: 2022-05-18T00:04:06Z solvables: 5 rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2022-05-13T10:06:59Z solvables: 1 rpm-md repo 'rpmfusion-free' (cached); generated: 2022-05-04T04:48:11Z solvables: 506 rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2022-05-13T10:33:29Z solvables: 2 rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2022-05-04T05:11:55Z solvables: 225 rpm-md repo 'phracek-PyCharm' (cached); generated: 2022-05-13T04:23:58Z solvables: 5 rpm-md repo 'rpmfusion-nonfree-nvidia-driver' (cached); generated: 2022-05-13T09:29:28Z solvables: 29 rpm-md repo 'rpmfusion-nonfree-steam' (cached); generated: 2022-02-13T17:48:12Z solvables: 2 rpm-md repo 'google-chrome' (cached); generated: 2022-05-12T18:20:59Z solvables: 3 rpm-md repo 'updates-archive' (cached); generated: 2022-05-18T01:24:11Z solvables: 8080 ---
I did some further research last night. I asked the Tailscale team, and they created a repo for f36, but when I re-added the repo I still saw the failure. I ran `gnome-software --verbose` and found these logs: ``` 02:13:33:0820 librepo lr_handle_perform: Using dir: /var/cache/rpm-ostree/repomd/tailscale-stable-36-x86_64 02:13:33:0820 librepo lr_handle_prepare_internal_mirrorlist: Preparing internal mirrorlist 02:13:33:0820 librepo lr_handle_prepare_internal_mirrorlist: Finalizing internal mirrorlist 02:13:33:0820 librepo lr_handle_prepare_internal_mirrorlist: Finalizing mirrors reported via LRI_MIRRORS 02:13:33:0820 librepo lr_handle_perform: Downloading/Locating yum repo 02:13:33:0820 librepo lr_yum_use_local: Locating repo.. 02:13:33:0820 librepo lr_yum_use_local_load_base: Parsing repomd.xml 02:13:33:0846 librepo lr_gpg_check_signature_fd: signature verify error (no signatures) 02:13:33:0846 librepo lr_yum_use_local_load_base: repomd.xml GPG signature verification failed: Signature verify error - no signatures 02:13:33:0846 libdnf failed to check, attempting update: repodata tailscale-stable was not complete: repomd.xml GPG signature verification failed: Signature verify error - no signatures 02:13:33:0846 libdnf setting keyfile data for tailscale-stable 02:13:33:0846 libdnf Failed to remove /var/cache/rpm-ostree/repomd/tailscale-stable-36-x86_64.tmp: cannot open directory /var/cache/rpm-ostree/repomd/tailscale-stable-36-x86_64.tmp: Error opening directory “/var/cache/rpm-ostree/repomd/tailscale-stable-36-x86_64.tmp”: No such file or directory 02:13:33:0851 Gs updates-shell: failed to get updates: failed to obtain lock 'metadata': Failed to create file “/var/run/dnf-metadata.lock.5XKIM1”: Permission denied ``` The tailscale.repo file: ``` [tailscale-stable] name=Tailscale stable baseurl=https://pkgs.tailscale.com/stable/fedora/36/$basearch enabled=1 type=rpm repo_gpgcheck=1 gpgcheck=0 gpgkey=https://pkgs.tailscale.com/stable/fedora/36/repo.gpg ``` If I set `repo_gpgcheck=0`, gnome-software works as expected. Something with the verification of the repo gog key is failing. I'm not sure if that's the root cause of the failure, but it seems like a step forward.
The logs indicate the error. The tailscale repository is missing GPG signatures. 02:13:33:0846 librepo lr_gpg_check_signature_fd: signature verify error (no signatures) 02:13:33:0846 librepo lr_yum_use_local_load_base: repomd.xml GPG signature verification failed: Signature verify error - no signatures
(In reply to Neil Darlow from comment #31) > The logs indicate the error. The tailscale repository is missing GPG > signatures. > > 02:13:33:0846 librepo lr_gpg_check_signature_fd: signature verify error (no > signatures) > 02:13:33:0846 librepo lr_yum_use_local_load_base: repomd.xml GPG signature > verification failed: Signature verify error - no signatures That's what I thought, too, but the repo seems to have a gpg key available. I'm not familiar enough with repositories to know what would need to be changed to fix that. What I discovered, though, was that every other repo I had installed has `repo_gpgcheck` disabled. So perhaps enabling that setting is problematic on Sivlerblue 36?
According to the DNF documentation both repo_gpgcheck and gpgcheck default to false. I would guess that this permits unsigned repositories and packages to be accepted without error. My .repo files all have repo_gpgcheck=0 and gpgcheck=1 and are unmodified so if that works for you, I'd go with it.
Since it still fails for me, but the logs are different, I opened the new bug 2088878