Failed upgrade from Fedora 38 to 39

my back ground: I’m a long time fedora user, not much of an admin, though I am studying for Linux+ certification, so I am familiar with fedora and other *nix variants, concepts and comfortable on the cli.
My current install started life as Fedora 36 and I have successfully upgraded to 37 (via CLI/DNF ) then 38 via GUI (discover)
The situation:
Feeling lazy, I was upgrading my system to Fedora 39; this time using discover. All went well until the first reboot, somewhere in the 49% complete range, my system froze and I was forced to reboot.
My system does boot, all hardware seems to be functioning properly, but the upgrade failed, obviously.
After I log in, I get a system notification of the failure with an option to repair, this also fails.
Dropping to the command line:

$ sudo dnf upgrade --refresh
Traceback (most recent call last):
File “/usr/bin/dnf”, line 61, in
from dnf.cli import main
ModuleNotFoundError: No module named ‘dnf’

well, ok, fine, lets try this…

sudo rpm -Va *dnf* python3*
rpm: error while loading shared libraries: /lib64/ file too short

None of the google search results for that error seem relevant, mostly regarding issues with YUM and anywhere from 8-10 years old.

So, I’m stuck.
The question: What can I do to repair my system and or continue the upgrade?
Is it easier to just nuke and pave? (I’d rather not, but i’m not totally opposed to the idea)
Is there a “repair install” option anywhere? similar to the windows command sfc /scannow?

If there is a log I should attach, I’ll be glad to do so, just not sure what may be needed.


May be an selinux issue.

Try this to fix the selinix labels that has come up recently as a way to break dnf.

sudo touch /.autorelabel 
sudo reboot

If this does work let us know and we can offer more suggestions

1 Like

If a system upgrade was broken in the middle, I’d advise you to just do a fresh install. Keep your old /home (but back up your important files anyway), so that you’ll keep all your data, and just reinstall the system. It will be much easier and safer than trying to fix a broken system (which might appear fixed at some point, just to break again later). Sorry for your experience.

It would be good to figure out why your system froze during upgrade. You can play with journalctl --list-boots and journalctl -b NUMBER to find the system journal of the upgrade process session, and link it here, perhaps we might see what went wrong.

1 Like

thanks for the suggestions, I think Kamil’s response is likely the direction I will proceed.

output from “journalctl --list-boots”

-7 f0b055bdfbec42aaac38ee77c0ee1deb Fri 2023-11-24 12:33:06 EST Mon 2023-11-27 14:50:50 EST
-6 4d179deeb1284716a041d1371549fe4e Mon 2023-11-27 09:51:25 EST Mon 2023-11-27 14:53:01 EST
-5 79ad3994f9b349b6b41a74f40d6bc844 Mon 2023-11-27 09:53:36 EST Tue 2023-11-28 11:11:24 EST
-4 bd05fc4efb1d4c6aa7d5d80b63df8680 Tue 2023-11-28 06:11:59 EST Tue 2023-11-28 11:17:44 EST
-3 6cb4f2fa676c4782af499ad96c42a5c1 Tue 2023-11-28 11:34:58 EST Tue 2023-11-28 11:36:12 EST
-2 2aa8ef99d02d46dbb26b92ac67ffe1be Tue 2023-11-28 11:36:51 EST Tue 2023-11-28 11:47:16 EST
-1 3c9f4859061c4ebcade8b3c87ea556d4 Tue 2023-11-28 11:48:05 EST Tue 2023-11-28 14:20:34 EST
0 48526ad31d7c4761892b5a933b37bad9 Tue 2023-11-28 14:44:09 EST Thu 2023-11-30 09:11:30 EST

If I have the timing right -4 is the first reboot during the upgrade

output of journalctl -b -4 is 6k +/- lines.

1 Like

That’s doesn’t look like a journal from the actual system upgrade. Look into a different one. You should see lots of lines with RPMs being upgraded one by one.

Alternatively, also look at sudo dnf system-upgrade log output, it can help you figure out which log is the right one. And then access it with sudo dnf system-upgrade log --number NUMBER.