Failing to upgrade f40 -> f41

Ask Fedora
1

I’m following directions from Upgrading Fedora Linux Using DNF System Plugin :: Fedora Docs (as I’ve done many times before)
After sudo dnf system-upgrade reboot, an f41 kernel starts up, and login window shows a new background, as expected.
When I try to run remove-retired-packages, it starts listing a lot of stuff. I gave up on this, figuring something is wrong.

If I instead run dnf distro-sync, it starts loading packages from f40 repos!
Found Dnf retrieving packages from version 40 after upgrading to Fedora 41 which said to run it with --releasever=41. This indeed makes it load packages from f41 repos – but then shows me an error:

Failed to resolve the transaction:
Problem 1: installed package ksaneplugin-17.08.3-6.fc32.x86_64 requires libksane.so.0()(64bit), but none of the providers can be installed
  - libksane-15.08.3-12.fc32.x86_64 does not belong to a distupgrade repository
  - problem with installed package
 Problem 2: installed package python2-pillow-6.2.2-7.fc33.x86_64 requires libtiff.so.5()(64bit), but none of the providers can be installed
  - installed package python2-pillow-6.2.2-7.fc33.x86_64 requires libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed
  - libtiff-4.6.0-2.fc40.x86_64 does not belong to a distupgrade repository
  - problem with installed package

Using --skip-broken doesn’t help, and uninstalling these packages vaguely helps – but distro-sync seems to come back to same or another broken state

After this, I reverted to a pre-upgrade btrfs snapshot, so the system is back to working in f40.
First time I tried this upgrade was a few weeks ago; just now tried again and had to roll back again :frowning:

Not sure what’s happening here…
Interestingly, libksane-15.08.3-12.fc32.x86_64 and python2-pillow-6.2.2-7.fc33.x86_64 are not even installed in the pre-upgrade system. Note fc32 and fc33!! Where are these even coming from?!

2

Usual way to fix this type of problem is to remove conflicting packages then upgrade.

Try dnf removing libksane-15.08.3-12.fc32.x86_64 and python2-pillow-6.2.2-7.fc33.x86_64 and try again.

1 Like
3

Apparently those packages seem to be in the rpm database so it tries to match the dependencies.
Maybe try rebuilding the database before doing the upgrade.
sudo rpm --rebuilddb
It is strongly suggested that you backup the database located in /var/lib/rpm before doing this.
https://jfearn.fedorapeople.org/en-US/RPM/4/html/RPM_Guide/ch04s05s02.html

1 Like
4

I rebuilt rpm DB, but output of rpm -qa seems to be the same (so I suspect nothing changed). Will update here after trying an upgrade (might be in a while)

Edit: playing around, I notice there’s stuff like
/var/lib/yum/yumdb/p/**UUID**-python-pillow-2.2.1-7.fc20-x86_64
Pretty sure that’s stale but dnf clean all isn’t clearing it

Should I just blast away /var/lib/yum/yumdb or something?

Hmm… come to think of it, that machine has yum little installed, though I’ve been using dnf for a while. Uninstall yum, I guess?

5

it sounds like you may have been upgrading ever since fc20?

In any case, modern versions of fedora do not have /var/lib/yum/ so that directory could possibly be removed.

When dnf replaced yum you would find that /usr/bin/yum is merely a symlink to /usr/bin/dnf so all the important functionality originally provided by yum is now provided by dnf.

What is the output of dnf list --installed \*yum\* I suspect that would return nothing. As a result removal of the entire /var/lib/yum/ directory tree should be perfectly fine.

Dnf uses /var/lib/dnf/ and /var/cache/dnf/ for its main data storage.

$ sudo dnf provides /var/lib/yum/
Updating and loading repositories:
Repositories loaded.
No matches found. If searching for a file, try specifying the full path or using a wildcard prefix ("*/") at the beginning.
6

Yes, been upgrading for a long time. dnf history goes back at least to 2015 >:)

Uninstalled yum package and removed /var/lib/yum/.
Also, ran rpm --verify -a and reinstalled packages that had missing files (not sure why they were missing).
Aside: find which package is responsible for a file with rpm -qf <path>

Also noticed that /var/lib/dnf/yumdb/p/922e8d130a6a70be8ceb6ef436042da834feeaca-python2-pillow-5.3.0-1.fc29-x86_64/ exists.
All files under /var/lib/dnf/yumdb/ are from 2020, nothing newer. Think I have to remove these (or move them out of the way)

7

That directory appears to also be a relic from the upgrade sequence.

$ ls /var/lib/dnf/
history.sqlite  history.sqlite-shm  history.sqlite-wal  repos  system-upgrade

To ensure all such glitches are completely removed I would suggest that you consider a new clean installation as there have been many -- many -- many changes over the last 9 years.

8

Followup:
After a bunch of poking, prodding and cleaning up, I realized that dates for /var/lib/rpm were several months old. Checking on the interwebz, I found Changes/RelocateRPMToUsr - Fedora Project Wiki.

Apparently, /var/lib/rpm had been converted to a symlink a while ago (pointing to /usr/lib/sysimage/rpm/) – but this machine didn’t get the memo during the upgrades :frowning:

$ strings rpmdb.sqlite |grep -i pillow
python2dist(pillow)!                                                                                                                                                                          
python2.7dist(pillow)!                                                                                                                                                                        
python2-pillow(x86-64)!                                                                                                                                                                       
        python2-pillow!                                                                                                                                                                       
[...]

–so I’m pretty sure that was the real culprit!

Retrying the upgrade again, I guess :slight_smile:

(aside: prefer not to do a clean install for this machine because of …reasons)

Edit: I also came upon dcrpm – but either my db is horrendously messed up or the tool doesn’t recognize it and shows a bunch of errors that don’t look very recoverable.

Also, rpm.org - RPM Database Recovery for recreating rpm db altogether with rpm -i --justdb PACKAGES (need to have ALL packages downloaded, though)

Edit 2: upgraded after the fix, and can confirm that was the issue!

3 Likes