1

Earlier today I installed Fedora 23 on a USB. After the installation was complete, I was doing the standard dnf upgrade, shell configurations, and ultimately preparations for installing the NVIDIA drivers (all of the computers I will use this on have NVIDIA GPUs).

I pushed my poor USB stick a little too hard, as I was doing an rsync of my 20GB+ folder at the same time as the dnf upgrade. I realize this was a terrible idea, but I have already more than paid for it.

Other than Fedora 23 destroying the bootloader of my /dev/sda on the computer it installed on (regardless of the fact that I installed from /dev/sdd to /dev/sde -- USB to USB), at some point everything died and the computer shutdown during the update. The results have been somewhat surprising, and I am very interested in trying to figure out

  1. Where to look or better how to parse things like /var/log*,
  2. How to programattically identify all broken packages, and
  3. What the right way of fixing them is wrt dnf.

A large number of important system packages seem to have two versions, the one from before the update and the one that was being updated to. This is making life difficult to develop in...


Examples:

On a different computer I finished the dnf upgrade and all seemed fine. I updated to a shiny new kernel, etc. Upon reboot though, I realized that although kernel 4.4 was installed grub only listed 4.2. I was in the process of giving up and building vmlinuz from source when I found an obscure bug report for F20 mentioning the same problem, and they fixed it by installing grubby. Many comments later, it turns out that I needed to dnf reinstall kernel-core (I already had grubby and the latest version).

This has been the theme of many fixes along the way, only it is occurring with some rather crucially important packages which makes me feel like something else is going on.

  • Had to remove the conflicting hplip-libs-3.{15,16} (both were installed and dnf was unwilling to do anything without removing both and then installing 3.16).
  • Any time a command that was not real was entered (e.g. typo):

    Failed to search for file: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PackageKit was not provided by any .service files

    • I saw a lot of posts about that one online, especially for gedit. But not for a command not found in the terminal.
    • Ok NP dnf search PackageKit oh ok I'll just try and install it then. But as it turned out, even with reinstall --allowerasing, I still had 1.0.10 and 1.0.11 installed and dnf would not budge.
    • I got a little reckless at this point considering everything involved with this package...

      dnf remove PackageKit-*
      dnf install PackageKit-*
      dnf list PackageKit-*    # shows 1.0.10
      dnf check-update && dnf upgrade
      dnf list PackageKit-*    # shows 1.0.11 now
      
    • But it works now, because the conflicting versions are reduced to a singularity again.


Any pointers? I've been scrolling through the logs / man pages of dnf / trying some of the various utilities like distro-sync (probably more than I should have), but can't seem to figure out what is going on.

These conflicts keep popping up unexpectedly. They have to end, right?

Looking at the logs, the only thing that seems meaningful is that sometime probably right around where the initial crash was there are a bunch of non-ascii characters in /var/log/dnf.rpm.log, or at least with less it appears as a long line of ^@ before the next logging initialized few hours later.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.