Dependency issue during upgrade from Fedora 39 to 40

Ask Fedora
1

Hello :wave:, I was a bit too late and Fedora 39 seems to be EOL for 3 weeks now, so instead of updating via Software Center to 41 and skipping 40, I’m following the recommendation in Upgrading Fedora Linux to a New Release :: Fedora Docs, which says I should update via command line. And then it’s probably safer to go version by version.

So following Upgrading Fedora Linux Using DNF System Plugin :: Fedora Docs, I’m at sudo dnf system-upgrade download --releasever=40, and it leads to output that leads me to 3 questions:

  1. It contains a lot of lines like No match for group package "iwl2000-firmware". What does that mean? There are 168 such lines! Most are for some fonts only, but 32 are for firmware or gstreamer1-libav, reiserfs-utils, multican and similar, where I’m worried that they might be needed, but apparently don’t exist in Fedora 40 anymore?

  2. It prints the following errors:

    Problem 1: package bind-libs-32:9.18.28-2.fc40.x86_64 from updates obsoletes bind-license < 32:9.18.27-2 provided by bind-license-32:9.18.24-1.fc40.noarch from fedora
 - cannot install the best update candidate for package bind-license-32:9.18.28-2.fc39.noarch
 - cannot install the best update candidate for package bind-libs-32:9.18.28-2.fc39.x86_64
Problem 2: package bind-libs-32:9.18.28-2.fc40.x86_64 from updates obsoletes bind-license < 32:9.18.27-2 provided by bind-license-32:9.18.24-1.fc40.noarch from fedora
 - package bind-utils-32:9.18.28-2.fc40.x86_64 from updates requires libbind9-9.18.28.so()(64bit), but none of the providers can be installed
 - package bind-utils-32:9.18.28-2.fc40.x86_64 from updates requires libdns-9.18.28.so()(64bit), but none of the providers can be installed
 - package bind-utils-32:9.18.28-2.fc40.x86_64 from updates requires libirs-9.18.28.so()(64bit), but none of the providers can be installed
 - package bind-utils-32:9.18.28-2.fc40.x86_64 from updates requires libisc-9.18.28.so()(64bit), but none of the providers can be installed
 - package bind-utils-32:9.18.28-2.fc40.x86_64 from updates requires libisccfg-9.18.28.so()(64bit), but none of the providers can be installed
 - package bind-utils-32:9.18.28-2.fc40.x86_64 from updates requires libns-9.18.28.so()(64bit), but none of the providers can be installed
 - problem with installed package bind-license-32:9.18.28-2.fc39.noarch
 - cannot install the best update candidate for package bind-utils-32:9.18.28-2.fc39.x86_64
 - bind-license-32:9.18.28-2.fc39.noarch from @System  does not belong to a distupgrade repository
 - bind-libs-32:9.18.28-2.fc39.x86_64 from @System  does not belong to a distupgrade repository

    At the end there’s:

    Skipping packages with broken dependencies:
 bind-utils                                                   x86_64                32:9.18.28-2.fc40                                        updates                                  224 k

Transaction Summary
====================================================================================================================================================   =====================================
Install     192 Packages
Upgrade    2588 Packages
Remove        5 Packages
Downgrade     6 Packages
Skip          1 Package

    I haven’t installed those bind packages explicitly, I assume they’re a dependency of some other package. I’m also not aware of running the bind server, except again maybe some other package does implicitly?

    What should I do here? Remove the packages (which ones?) and retry the upgrade? Or just continue the upgrade with the skipping? If the latter, what do I need to do in Fedora 40 then? Will those packages be broken?

  3. It contains lines like:

    minizip-ng-compat                                            x86_64                3.0.10-7.fc40                                            fedora                                    65 k
  replacing  minizip-compat.x86_64 1.2.13-4.fc39

    Are those new packages proper replacement packages, i.e. intended by Fedora 40 to replace the Fedora 39 packages? Or is it guessing which package might be a replacement, and I should double check all of them?

Thank you so much in advance!

PS: My Fedora install was originally 35, on the first Framework Laptop 13. Then I updated to 36 via CLI, then to 38 via GUI (before 36 was EOL), then to 39 via GUI.

2

I think it means you waited too long. :slight_smile:

This is just my opinion, but I don’t think I’d trust the offline installer in this situation. My preference would be to do an online upgrade from the multi-user target/runlevel (i.e. without the full GUI running) so that I could have a chance at fixing things and re-running the dnf update command if necessary.

Also, make sure you have root’s password set so you will be able to get to the emergency shell if the update fails. It’s unlikely, but better safe than sorry. :slight_smile:

Once you are at the CLI of the multi-user target (as the “root” user), try dnf upgrade --releasever=40 --best --allowerasing. Based on your above report, it will probably want to remove some packages. If it doesn’t look like anything that you know you need is listed, then it is probably safe to proceed.

You can use sudo init 3 to shutdown your GUI and get to the multi-user target. (There is probably a better way to do that these days with systemd, but I haven’t looked it up.)

3

It is a proper known-correct replacement. You can trust that it is correct.

4

The systemd way is systemctl isolate multi-user.target but it basically does the exact same thing.

1 Like
5

So how did this get resolved? I’m seeing the same error on my 39->40 upgrade.

While bind-license isn’t system critical, bind-libs probably is. The output says “Downgrading” so I assume some version of those packages will still be present?

6

Yes, both “downgrading” and “skipping” would leave some version of the package on your system. It is the removed packages that you need to keep an eye on and make sure nothing you need is listed. If you are not sure what a package is, you can cancel the transaction a use rpm -qi <package-name> to get more info about it.

In an absolute worse-case scenario that leaves your system unbootable (highly unlikely), you could use a Live image to repair the installation.

Btrfs snapshot can provide another means of reversing an update in case it goes wrong. Working with Btrfs snapshots and using them to roll back an installation is an advanced operation. If you are interested in that, there is some documentation here: Make use of Btrfs snapshots to upgrade Fedora Linux with easy fallback - Fedora Magazine (You should experiment with it on a test system that does not contain any important files.)

1 Like
7

Not sure if this is a passing issue that’s only problematic during dnf upgrade. I guess we’re finding out. I ran the reboot and went to bed.
Pretty sure these are xfs filesystems. That seems like an interesting use of snapshots though!