Bug 1266683 - dnf system-upgrade fails to upgrade cleanly and dnf distro-sync fails to do what is intends to do, downgrade some packages.
dnf system-upgrade fails to upgrade cleanly and dnf distro-sync fails to do w...
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-09-26 10:05 EDT by zimon
Modified: 2015-10-16 07:03 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-13 09:04:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description zimon 2015-09-26 10:05:00 EDT
Description of problem:

dnf asked me to report this.
"If the above doesn't help please report this error at (here)"

I upgraded from F21 to F22 with the following commands:
# dnf system-upgrade download --releasever 22
# dnf system-upgrade reboot


After some difficulties, I got system upgraded. But now there is all old F21 packages also in the system.

I got a suggestion to try dnf distro-sync.
dnf distro-sync fails to deliver.

Version-Release number of selected component (if applicable):
Well, the problem is, the working dnf is v 0.6.4
I also have dnf v 1.1.1-2.fc22 installed, but it has its files overwritten.

# rpm -q dnf

If I try to:
dnf reinstall dnf
it complains:
Running transaction check
Error: transaction check vs depsolve:
dnf <= 0.6.4 is obsoleted by (installed) python3-dnf-1.1.1-2.fc22.noarch
dnf <= 0.6.4 is obsoleted by (installed) python-dnf-1.1.1-2.fc22.noarch
To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'.
To fix inconsistent RPMDB, try running: 'rpm --rebuilddb'.
If the above doesn't help please report this error at 'https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf'.

How reproducible:
For me, right now, always.

Actual results:
dnf distro-sync failes to deliver.

Expected results:
To have distro sync, some packages downgraded.

Additional info:

# dnf distro-sync 
Using metadata from Wed Sep 23 19:16:51 2015 (2 days, 21:25:24 hours old)
Dependencies resolved.
....(lines omitted)
Transaction Summary
Install      3 Packages
Downgrade  169 Packages

Total download size: 339 M
Is this ok [y/N]: y
Downloading Packages:
(1/172): glib2-devel-2.44.1-1.fc22.x86_64.rpm   1.7 MB/s | 433 kB     00:00    
(2/172): ibus-typing-booster-1.2.11-1.fc22.noar 1.9 MB/s | 136 kB     00:00   
....(lines omitted)
Running transaction check
Error: transaction check vs depsolve:
ecore <= 1.7.10 is obsoleted by efl-1.15.0-1.fc22.x86_64
eet <= 1.7.10 is obsoleted by efl-1.15.0-1.fc22.x86_64
evas <= 1.7.10 is obsoleted by efl-1.15.0-1.fc22.x86_64
libeina <= 1.7.10 is obsoleted by efl-1.15.0-1.fc22.x86_64
perl-Encode < 2:2.64-2 conflicts with perl-encoding-2:2.76-1.fc22.x86_64
yum < 3.4.3-505 conflicts with (installed) dnf-yum-1.1.1-2.fc22.noarch
libgdata < 0.17.1 conflicts with compat-libgdata19-0.16.1-1.fc22.x86_64
To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'.
To fix inconsistent RPMDB, try running: 'rpm --rebuilddb'.
If the above doesn't help please report this error at 'https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf'.

# rpm --rebuilddb
# dnf distro-sync 

But "dnf distro-sync" again fails and reports the same "obsoleted" problems.
Comment 1 zimon 2015-09-26 11:37:17 EDT
As I mentioned, there is all old F21-packages left in the system after "dnf system-upgrade":

# rpm -qa|grep fc22|wc -l
# rpm -qa|grep fc21|wc -l

# rpm -qa|sort|head
# rpm -V a52dec-0.7.4-19.fc22.x86_64
## (emtpy output)
# rpm -V a52dec-0.7.4-19.fc21.x86_64
S.5......    /usr/bin/a52dec
S.5......    /usr/bin/extract_a52
S.5......    /usr/lib64/liba52.so.0.0.0

I got dnf upgraded from version 0.6.4 to version dnf-1.1.1-2.fc22 by enforcing with rpm:

But even with this newest dnf, the "dnf distro-sync" does not work.

If I add --allowerasing, it would like to remove 4325 of 4659 F22 packages and downgrade 557 of 4657 F21 packages.

# dnf distro-sync --allowerasing
Transaction Summary
Install       5 Packages
Remove     4325 Packages
Downgrade   557 Packages
CNTRL+C -> cancelled after the first transaction test.

I wonder, if I allow it to proceed, will the system go broken and not boot.
Comment 2 zimon 2015-10-01 03:46:45 EDT
I was not able to "distro-sync" properly even after some different manoeuvres and trials.

I upgraded then to Fedora 23, from this mixed Fedora 21&22 system.
It went smoothly and the system was upgraded to Fedora 23 (beta). (....otherwise but gdm, gnome-session and several other programs crash, but that is not dnf's fault.)

Now currently the system has:

$ rpm -qa | grep fc21 | wc -l
$ rpm -qa | grep fc22 | wc -l
$ rpm -qa | grep fc23 | wc -l

So, to conclude, the problem with "dnf system-upgrade" from F21 to F22 was either (maybe):

a) I had testing-repositories enabled and some version of packages were greater than what F22 provided, so dnf/rpm/somethingelse was confused and did not overwrite those F21 packages.

b) The upgrade process got hung for some unknown reason and when I had rebooted, the dnf system was left in inconsistent state and it could not recover, although it would be good if it would. "dnf distro-sync --allowerasing" was going to do something very risky looking things and I never tried it through, because the system was going to remove all F22 packages and not the F21 packages which had mostly overwritten installed files in the system.

I can provide extra information if needed, but I do not know if there is evidence left in the system now when it is upgraded to Fedora 23.
Comment 3 Jaroslav Mracek 2015-10-13 09:04:55 EDT
It is probably problem of RPM and corrupted db. The problem is befor RPM transaction but it is not a problem of dnf.
Comment 4 zimon 2015-10-16 07:03:42 EDT
This bug is closed already, but just for information, if someone happens to encounter the same kind of mess sometimes.

The system thinks it is F23 now, most of the packages are F23, but the F22 and F21 packages are many conflicting eachothers, at least when listed the packages which would be in the system.

eg. I noticed with SELinux bug 1268948 report had all three perl packages mentioned in the AVC-notice. And yes, with "rpm -qa" all perl packages were there.

So, "dnf system-upgrade" partly failed also from F21&F22 to F23.
Would think, when "dnf system-upgrade" upgraded perl, which had fc23 package, it would had removed fc21 and fc22 packages, but no. 

I guess there is no ready tool to solve this mess, but a script has to be written, or whole fresh new install of OS and delete all old packages, or just live with these double and on some cases triple (fc21,fc22,fc23) packages.

# rpm -qa|grep -E 'fc21|fc22'|sort

...an hour later
So I wrote a script to get rid of unnecessary fc21-packages:

# cat >/usr/local/bin/fix_fc21_fc22-mess.sh <<_ENDSCRIPT
# 2015-10-16

strip_rpm_name () {
   # eg. x264-libs-0.142-11.20141221git6a301b6.fc21.x86_64 -> x264-libs
   echo $1 | perl -ape 's/(.*)\.(.*\..*)/$1/e; s/(.*)\-(.*)\-(.*)/$1/e;'

pkgName=`strip_rpm_name $1`

# Removes the fc21 package. Then tries to reinstall the named package without
# specifying the version first from default (fc23) repositories and if fails 
# then from fc22 repositories.
dnf -y remove "$pkgNameVersion"
dnf -y reinstall "$pkgName" || dnf -y --releasever 22 reinstall "$pkgName"

# rpm -qa | grep 'fc21 | xargs -n 1 fix_fc21_fc22-mess.sh

...took a while, but looks better now:
# rpm -qa|grep fc23|wc -l
# rpm -qa|grep fc22|wc -l
# rpm -qa|grep fc21|wc -l
# rpm -qa|grep fc20|wc -l
# rpm -qa|grep fc19|wc -l
# rpm -qa|grep fc18|wc -l
# rpm -qa|grep fc17|wc -l
# rpm -qa|grep fc16|wc -l
# rpm -qa|grep fc15|wc -l
# rpm -qa|grep fc14|wc -l
# rpm -qa|grep fc13|wc -l
# rpm -qa|grep fc12|wc -l
# rpm -qa|grep fc11|wc -l

Note You need to log in before you can comment on or make changes to this bug.