Upgrade from 40 to 41 failed, how to recover?

When upgrading, the process hung for about an hour at 43% and I had no option but to reboot. Now the upgrade does not show in Software, and dnf method of updating has dependency problems, and --skip-broken, skipping protected packages etc. doesn’t work.

Running results in an error:

> [1922/1922] Total                                                                                                                                     100% |  37.2 MiB/s |   2.4 GiB |  01m07s
> Testing offline transaction
> terminate called after throwing an instance of 'libdnf5::AssertionError'
>   what():  libdnf5/rpm/transaction.cpp:193: void libdnf5::rpm::Transaction::fill(const libdnf5::base::Transaction&): Assertion 'implicit_ts_elements.empty()' failed: The rpm transaction contains more elements than requested
> Aborted

So: how can recover from an interrupted upgrade?

Thanks for your great work on Fedora, which I’ve loved since it first existed,

John

Can you try
sudo dnf upgrade --refresh

or try
sudo dnf clean all

Thanks! I should have mentioned that I’ve already tried that, with the same result.

How about manually removing the entire cache with

sudo rm -r /var/cache/dnf

followed by
sudo dnf clean packages

Thanks, I’ll try that.

Thanks again for your help!
After following your advice, then running sudo dnf -y system-upgrade download --releasever=41

The result is:

Problem: The operation would result in removing the following protected packages: NetworkManager, grub2-tools-minimal, selinux-policy-targeted, setup, sudo, systemd, systemd-udev

Then running sudo dnf -y system-upgrade download --releasever=41 --setopt=protected_packages=

has the result:

Testing offline transaction terminate called after throwing an instance of 'libdnf5::AssertionError' what(): libdnf5/rpm/transaction.cpp:193: void libdnf5::rpm::Transaction::fill(const libdnf5::base::Transaction&): Assertion 'implicit_ts_elements.empty()' failed: The rpm transaction contains more elements than requested Aborted

These threads

discuss the option that upgrades have failed due to dnf5 being used for the upgrade.
Maybe try to remove dnf5 and libdnf5, so your system uses the old dnf for the upgrade? If that does not work I hope someone else can chime in…

Im at the exact same spot right now, getting the same error mesage.

Hope this will eventually resolve.

Do you have dnf5 installed in Fedora 40? If so, have you tried removing dnf5 and libdnf5?

yes, to no avail.

But nvm, I will switch to nixOS :smiley:

1 Like

You could just do a clean install of F41 :slight_smile:

yeah if nixOS does not work out, I will probably do that…

Added dnf, dnf-system-upgrade, dnf5, protected-packages, upgrades

Or try Fedora Atomic Desktops this time, where these annoying upgrade issues (which I personally had too) dont ever occur

how well does it do with wayland, gaming and CUDA workloads?

real talk, this screw up has been pretty much a deal breaker to use Fedora in the future.

Will rather give nixOS or Arch a try BTW :wink:

If you need NVIDIA stuff, use uBlues *-nvidia images

If you want Gaming, bazzite is the easiest and it is based on Fedora Kinoite

Thx for the suggestions! However that should be possible on the same system without specialised distros…

I was able to with Fedoraa as well as Ubuntu, and I know its possible with both nix and arch…

In that case you may not have understood the concept of atomic desktops

The idea is to build either a very minimal variant (of the same distro) or a more specialized one (if you need a lot of core system changes, which I dont as I dont need Gaming or proprietary drivers) and then deploy that everywhere

Ublue just consumes the Fedora images, does a bunch of changes and then publishes them again. In their “main” images these changes are really small, the “hwe” images have stuff for ASUS, nvidia and surface. Their advertized ones “Bazzite”, “Bluefin” and “Aurora” have the most changes.

Those are still Fedora too, not different than if you would install it, add a bunch of repos and swap some packages.


Of course you can do whatever you want on mutable distros like (dnf) Fedora, Ubuntu (not Ubuntu core) or Arch.

The point is that as soon as you fire up your package manager, you will introduce changes that are mostly not reversible. The package manager just looks that all packages have their dependencies, but doesnt manage the set of packages or files.

Nix is different and if it is kinda easy to start, may actually be better for people that want a custom, but specific and composed system. It is basically the same as atomic but it allows users to change their system locally in an easier way