| Summary: | f23 -> f24: 'dnf update dnf' omits libsolv | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Felix Miata <mrmazda> |
| Component: | dnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | jmracek, jsilhan, mluscon, mrmazda, packaging-team-maint, pnemade, rjones, vmukhame |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-03-02 13:25:50 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: | |
|
Description
Felix Miata
2016-02-14 04:27:47 UTC
Can you post `rpm -q hawkey libsolv dnf` for broken combination and when everything works fine? If you do downgrade libsolv/dnf, is it broken again? Downgrade:
A procedure I've never attempted, nor seen explanation how to do.
Before:
(A lot of work to setup/discover):
# rpm -q hawkey libsolv dnf
hawkey-0.6.2-3.fc23.i686
libsolv-0.6.14-7.fc23.i686
dnf-1.1.6-2.fc23.noarch
# dnf install fedora-repos-rawhide
# dnf config-manager --set-disabled fedora updates
# dnf config-manager --set-enabled rawhide
# dnf update dnf
Complete!
# dnf update kdm
Traceback (most recent call last):
File "/usr/bin/dnf", line 56, in <module>
from dnf.cli import main
File "/usr/lib/python3.5/site-packages/dnf/__init__.py", line 31, in <module>
import dnf.base
File "/usr/lib/python3.5/site-packages/dnf/base.py", line 29, in <module>
from dnf.yum import history
File "/usr/lib/python3.5/site-packages/dnf/yum/history.py", line 22, in
<module>
import hawkey
File "/usr/lib/python3.5/site-packages/hawkey/__init__.py", line 24, in
<module>
from . import _hawkey
ImportError: /lib/libhawkey.so.2: symbol solv_extend_realloc, version SOLV_1.0 not defined in file libsolv.so.0 with link time reference
# rpm -q hawkey libsolv dnf
hawkey-0.6.2-4.fc24.i686
libsolv-0.6.14-7.fc23.i686
dnf-1.1.6-2.fc24.noarch
After completing repairs:
hawkey-0.6.2-4.fc24.i686
libsolv-0.6.15-6.fc24.i686
dnf-1.1.6-2.fc24.noarch
Why isn't package installation and removal logged to disk (like zypper does by default automatically)?
we can release newer version of libsolv and rebuild a hawkey for f22, f23 and rawhide if it can fix the issue. Essentially the same thing happens trying to update an i686 Rawhide that hadn't been updated for 2 or 3 months. This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase I have the same problem, but on armv7hl. We have found that documented upgrade procedure on the page https://fedoraproject.org/wiki/Upgrading_Fedora_using_dnf is not properer one (we marked the page for deletion). We recommend to use a description from https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager or more preferably to use the system-update plugin. We apologize for your problem, but it is impassible to follow and keep updated all wiki pages, that can be created by anyone and anytime. I am going to close this bud, but feel free to reopen it if description on pages that we recommend fails. (In reply to Jaroslav Mracek from comment #7) > preferably to use the system-update plugin. Bug 1032541 blocks the system-upgrade method on https://fedoraproject.org/wiki/DNF_system_upgrade from being used for F23->F24. Using the comment 0 method allows to update blocks of packages in order to not exhaust freespace with rpms waiting to be installed. Nothing at all can get installed, so libsolv not being installed would be subsumed by the bigger obstacle, negating any point in reopening this before the blocker gets fixed. |