Hello , 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.
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?
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
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?
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.
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.
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.)
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?
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.)
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!
I didn’t resolve it yet, and some things are still not clear to me.
I’m not sure what “an online upgrade from the multi-user target/runlevel” means. What’s the differentiation between offline/online here? Apparently not in terms of Internet connection, but “offline” is via terminal in the regular desktop environment, and “online” is via terminal without the regular desktop environment?
The impact of No match for group package "iwl2000-firmware" (and gstreamer1-libav, reiserfs-utils, multican) is still not clear to me. Are the packages of the group now grouped in a different group name? Or not grouped at all? Can I get around this by installing all packages explicitly, and the OS upgrade then finds the packages in the new Fedora 40 repos? If I don’t, will the packages stop working or be deleted?
The impact of Skipping packages with broken dependencies: bind-utils is still not clear to me either.
So I’m generally still a bit lost.
I’m also still surprised that just 3 weeks after the EOL the upgrade runs into these issues. Like did the iwl2000-firmware group package still exist 3 weeks earlier? Or has it always been removed from the Fedora 40 repos?
Do you know of good places for professional (paid) support, where someone can assist the upgrade process and in case of things breaking (software not working, OS not booting) is able to fix it?
I’m also thinking of setting up an entirely new system, with lower risk of these upgrade issues. In general I think Fedora is a nice middle ground between rolling releases (too risky), and fixed/LTS releases (often outdated/old packages). Then instead of the regular Fedora, maybe the Atomic spins are better suited for me? In terms of no-risk updates that can be rolled back easily? (Without using BTRFS, as Gregory mentioned above). But then again it’s not clear how long OS versions are kept in the repo, so if on say Kinoite, the 39 to 40 upgrade breaks and I roll back to 40, how long do I have until 40 is deleted? For example Bazzite (an unofficial Fedora Atomic Desktop based OS) says " Additionally, images of the operating system are retained in our repositories for ninety days and can be switched to via the terminal."
It is a little confusing, but essentially it means your internet connection needs to be up when you run the command. The “offline” update performs the package installation while the internet connection is down. (But both versions split the fetching of packages and their installation into separate stages, so the difference isn’t really all that significant.)
No match just means it could not find the package for whatever reason. I think “group package” means the package is part of some “package group” you’ve installed. dnf group list will show what package groups you’ve installed. dnf group info "<group name>" will list what packages are required by package group “<group name>”. I find that one a bit confusing though. I wouldn’t expect iwl2000-firmware to be part of a group. Also, it looks like it was last built for Fedora Linux 38. It appears that the iwlwifi-dvm-firmware provides that firmware for Fedora Linux 39+, so if your upgrade transaction includes iwlwifi-dvm-firmware, I think your hardware should continue to work.
It means bind-utils and anything that depends on it is not guaranteed to work after your upgrade. It’s not good, but I don’t think there is a lot that depends on bind-utils. Since it is just “skipping”, and not “removing”, the old package will remain on your system, so the next time you try to upgrade (F40→F41), it should see that package again and try to upgrade it again. Hopefully it will be able to resolve the dependencies the next time around. (I would recommend trying to upgrade to the next release immediately after this update to, hopefully, resolve some of these issues.)
, 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.