Power failure leaves DNF upgrade in limbo

Running Fedora 32 on an ASUS / AMD 32GB machine. Dual boot Windows 10 and RH32. Upgraded to 32 from 30 earlier this year, machine was stable and has been updated periodically since.

Logged on to my account today and opened a terminal, then elevated to SU. Invoked DNF with the command “dnf upgrade --best --allowerasing”. Over 500 packages were marked for upgrade, over 1 Gb of changes. Downloads proceeded OK, transaction tests OK, began transactions.

Suddenly experienced a brief (1 sec.) power outage (probably due to high winds); the machine rebooted into Windows and I shut it down until the weather event passed. Restarted the machine just now and opened a terminal window, elevated to SU, invoked dnf as before. DNF will not load; I get the following message no matter how I invoke dnf:

[CLH@localhost ~]$ su
Password:
[root@localhost CLH]# dnf upgrade --best --allowerasing
Traceback (most recent call last):
File “/usr/bin/dnf”, line 58, in
main.user_main(sys.argv[1:], exit_code=True)
File “/usr/lib/python3.8/site-packages/dnf/cli/main.py”, line 201, in user_main
errcode = main(args)
File “/usr/lib/python3.8/site-packages/dnf/cli/main.py”, line 67, in main
return _main(base, args, cli_class, option_parser_class)
File “/usr/lib/python3.8/site-packages/dnf/cli/main.py”, line 97, in _main
cli = cli_class(base)
File “/usr/lib/python3.8/site-packages/dnf/cli/cli.py”, line 726, in init
self.register_command(dnf.cli.commands.history.HistoryCommand)
AttributeError: module ‘dnf.cli.commands.history’ has no attribute ‘HistoryCommand’

“dnf history”, “dnf list”, “dnf clean” etc. all produce this message. What do I do to resolve this?
Thanks for your suggestions.

-CH-

1 Like

It would appear that one or more files within dnf has been damaged.
A quick search show that both files reported “/usr/lib/python3.8/site-packages/dnf/cli/cli.py” and usr/lib/python3.8/site-packages/dnf/cli/main.py are provided by the package python3-dnf, so you might try “sudo yum reinstall python3-dnf” and see if that fixes it. It could be that dnf was updating itself when the power blip occurred. It also could have been writing the history. Worst case would be that the head moved and overwrote more than one file but you can only deal with one error reported at a time.

If yum does not work for this then try rpm. Documentation here.
You also might try “sudo rpm --rebuilddb” after verifying other commands fail. That is supposed to rebuild all the parts of the dnf/yum database and might be all that is needed.

2 Likes

Fedora 33 upgrade - broken system after 35 hours

1 Like

Thank you for your response. Invoking YUM generates the same error message, so whatever is causing the problem and generating the message is a module common to both. I also ran the rpm --rebuilddb, which concluded without errors, apparently, but after which the same DNF / YUM error message appeared. So it doesn’t appear to be a problem with database corruption, unless I missed something.

I tried using RPM to erase, reinstall, etc. DNF, none of which were successful. I’m probably missing a key parameter; I’m not very familiar with RPM from the CLI. But the failures fell into two general categories: Can’t do that due to dependencies and No such file or path.

Three things I have learned from this:

From GRUB you can boot into a system using an earlier kernel, but the rest of the system is in whatever state the last update left it in. It is not the equivalent of a Windows “rollback”, in other words.

The system appears to require multiple version of certain key components - like Python, for example - due to dependencies of various installations. Rather like the Windows need for multiple versions of C++ redistributables.

Partial upgrades, more frequent upgrades, automatic upgrades, upgrades in better weather and an uninterruptible power supply (UPS) are all a good idea.

Thanks again,
-CH-

1 Like

following the link provided by vgaetera will likely fix it. The --rebuilddb step is only the first part.

1 Like

Can you give the exact commands you used to reinstall DNF via RPM, and the results? Depending on the state your system is, this may or may not be possible. What does

rpm -qa '*dnf*'

currently show?

Here is the result of issuing that command:

[CLH@localhost ~]$ su
Password:
[root@localhost CLH]# rpm -qa ‘dnf
python3-dnf-4.2.23-1.fc32.noarch
python3-libdnf-0.48.0-1.fc32.x86_64
python3-dnf-plugins-core-4.0.18-1.fc32.noarch
libdnf-0.54.2-3.fc32.x86_64
python3-libdnf-0.54.2-3.fc32.x86_64
libdnf-0.48.0-1.fc32.x86_64
dnf-plugins-core-4.0.16-1.fc32.noarch
python3-dnf-4.4.0-3.fc32.noarch
dnf-4.4.0-3.fc32.noarch
python3-dnf-plugins-core-4.0.16-1.fc32.noarch
dnf-data-4.2.23-1.fc32.noarch
dnf-4.2.23-1.fc32.noarch
dnf-data-4.4.0-3.fc32.noarch
[root@localhost CLH]#

I created a live CD from a Fedora 33 Workstation ISO and followed the instructions for creating a new mount point. I ran into difficulties - my system is not “standard” or “default” and after several attempts I now have a system that will not boot.

I may be able to undo what I have done but I think it will take less time to simply wipe everything and install 33. I am more than a little disappointed but thankful that this is not a production machine.

-CH-

I’m sorry this happened to you. A power-outage in the middle of an upgrade is pretty much the worst-case scenario.

This doesn’t help you now, but since you’re reinstalling anyway, you may consider Silverblue. It’s got its own quirks, but one key feature is “atomic” upgrades: you reboot into a new system which is either completely upgraded or you roll back to the unchanged previous system. So, this problem can’t occur.