Home / server / Questions / 1055346
In Process
Richard T
Asked: 2021-02-28 17:05:29 +0800 CST

After power failure restart both DNF and YUM stopped working, do nothing, not even metadata check

  • 772

My environment, happily functioning for a long time, experienced a power outage - of course, the immortal power supply was offline at the time, needing new batteries. As the administrator, I know there hadn't been any updates in some time and there were no administrative tasks going on at the time. And, I know it was fully healthy, having just gotten a replacement motherboard and then having been fully checked-out before being returned to service. (Oh, it also has ECC memory.)

Following reboot when the power came back, all systems rebooted promptly but the backup server appeared to not have run the cron @reboot job that mounts disks between it and the primary.

Investigating, there was no obvious reason why the job didn't run, so I went to look at the email that's supposed to be sent - to root in this case. So, I launched Alpine which I use for this and there was no alpine?! Confused, I figure I somehow forgot to install Alpine, so I ran $ dnf install alpine ... that should do it, but it instantly returned without giving the familiar "Last metadata expiration check" stuff. That's what told me something substantial must have happened. ...I tried it on the working server and it seems healthy.

So, I tried yum with the same it_didn't_do_anything result.

So, I looked at the files. The launcher for dnf is identical to the one on my not-damaged server.

The launcher is python, so I went looking for a way to confirm python itself is OK, and it launches and runs gnome-music just fine, so I suspect something went wrong with the yum & dnf specific python libraries.

I found the rpm files still on my box in /var/cache, but when I try and reinstall with rpm, everything I've tried so far fails with dependency issues, including constructs like $ rpm -Uvh -p /var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/dnf-*.rpm

Here are the rpm files:

/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/dnf-plugins-core-4.0.18-1.fc32.noarch.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/python3-dnf-plugins-core-4.0.18-1.fc32.noarch.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/python3-libdnf-0.55.2-1.fc32.x86_64.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/python3-dnf-4.5.2-1.fc32.noarch.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/libdnf-0.55.2-1.fc32.x86_64.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/dnf-data-4.5.2-1.fc32.noarch.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/dnf-4.5.2-1.fc32.noarch.rpm

Obviously this is a Fedora Core 32 installation. ...I think MAYBE I could get my way out of this if I only knew how to tell rpm to reinstall all these packages - maybe I'm just doing it wrong!

Any help appreciated.

(Note this was errantly posted on Stack Exchange when I should have put it here - I don't have the privs either here or there, as I do on Stack Overflow, to migrate between venues.)

yum python rpm dnf

1 Answers

  1. After spending a lot of fruitless time trying to fix this problem, I stumbled quite by accident on the cause, thanks to the color-schemes Bash uses!

    I just happened to do an ls -l command in /var and spotted a bit of red that shouldn't be there... It happens that because of a number of factors, parts of /var have been moved to another drive, and somehow the link /var/log got corrupted. I recreated the link and all is well now!

    The cause is, my view, a bug for a failure to report the actual cause of the problem since, as a programmer myself, I always put checks for even basic things and report errors both in logs and to the command-line user. If you're going to have a hard failure due to any form of disk I/O error, tell the user what you were trying to do! ... YES, I should have gone looking to the system log file anyway, you could argue, but it honestly never occurred to me that either dnf / yum wouldn't report back to the user's terminal, or that there would be anything from the power failure itself to find in the log files.

    I guess I'll be reporting a bug shortly!

    Meanwhile, over on stack exchange, I got this comment which might help someone else with a similar looking problem but different cause:

    sudo rpm --reinstall /var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/*rpm. If it doesn't help try runnning dnf clean all. – Artem S. Tashkinov

    • 0