Bug 2249732
| Summary: | dnf looking for outdated librpmio and librpm | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Todd <ToddAndMargo> |
| Component: | dnf | Assignee: | amatej |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 39 | CC: | daniel.mach, jkolarik, jmracek, jrohel, mblaha, packaging-team-maint, pkratoch, pmatilai, rpm-software-management |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-12-05 05:53:33 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
> Fedora 39 ^^ > dnf-4.18.1-1.fc38.noarch ^^ You have dnf from Fedora 38 on claimed Fedora 39. Dnf itself is just a Python program and wont know anything about librpm versions, the underlying issue is some other package, presumably libdnf being similarly left at F38 version. And if there's one, there's likely to be more. You'll want to check 'rpm -qa|grep fc38' on that system. I had something similar happen to me on my home desktop upgrade, but in my case rpm itself and the entire Python stack got held back, dnf didn't work and I had loads of "fun" manually resolving that with just rpm. Geez. I never tought to look at that.
# dnf upgrade dnf --releasever=39 --best --allowerasing
Screwed up a lot and left a lot of fc38 stuff in place
# dnf upgrade dnf --releasever=39
Failed on its ....
# dnf upgrade --releasever=39
3000+ file later,
# dnf upgrade dnf --releasever=39 --best --allowerasing
273 files later, and
# rpm -qa dnf
dnf-4.18.1-1.fc39.noarch
# rpm -qa | grep -i fc38
And I still have hundred of rpm's on fc38. Using dnf whatprovides, I am finding that the fc38 versions are slightly higher than the fc39 versions:
# dnf whatprovides cups --releasever=39
Last metadata expiration check: 1:34:34 ago on Wed 15 Nov 2023 01:19:42 AM PST.
cups-1:2.4.7-1.fc39.x86_64 : CUPS printing system
Repo : fedora
Matched from:
Provide : cups = 1:2.4.7-1.fc39
cups-1:2.4.7-2.fc38.x86_64 : CUPS printing system
Repo : @System
Matched from:
Provide : cups = 1:2.4.7-2.fc38
GGGGRRRRRRR
You should use "distro-sync" instead of "upgrade" for distro upgrades, because despite packager best intentions, in the real world its not rare to have older packages in a newer distro due to updates getting out of sync. Another option would be to use the system-upgrade plugin which is designed for this: https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/ (it does some additional things like upgrading groups and environments). There doesn't appear to be a dnf bug so I am closing this. If you find there is some dnf problem here after all please reopen. |
Fedora 39 dnf-4.18.1-1.fc38.noarch dnf is looking for outdated version 9 instead of version 10 of librpmio librpm.so # dnf whatprovides leafpad Traceback (most recent call last): File "/usr/bin/dnf", line 61, in <module> from dnf.cli import main File "/usr/lib/python3.12/site-packages/dnf/__init__.py", line 30, in <module> import dnf.base File "/usr/lib/python3.12/site-packages/dnf/base.py", line 29, in <module> import libdnf.transaction File "/usr/lib64/python3.12/site-packages/libdnf/__init__.py", line 14, in <module> from . import conf File "/usr/lib64/python3.12/site-packages/libdnf/conf.py", line 10, in <module> from . import _conf ImportError: librpm.so.9: cannot open shared object file: No such file or directory Workaround: # cd /usr/lib64 # ln -s librpmio.so.10.0.0 librpmio.so.9 # ln -s librpm.so.10.0.0 librpm.so.9