I started the upgrade yesterday, but I recalled seeing this article in fedora magazine. The article is very well written. I started the system-upgrade download and packages started downloading, but I ctrl-c’d it, so I could try this.
The mistake I might have been at:
Then proceed with the standard system-upgrade outlined on the wiki page. TIP: Before running dnf system-upgrade reboot, make another snapshot of root. Call it something like root.dl. That way, you don’t have to download five gigabytes of packages again should you discover that there wasn’t enough free space
I have no idea exactly what I did, whether is was the additional snapshot or the interrupted process. I will appreciate any ideas about if and how there can be ‘going back’ to install the system-upgrade. If there is additional information or logs that can illuminate the current state of my system, I will try to find and upload.
It’s nothing to do with the snapshot. It is just saying that it cannot find a package it needs to do the upgrade. The file it is saying it cannot find in the upgrade is libgnat-12.so. Consequently, it cannot upgrade the ghdl package. Since it cannot find everything it needs to do the upgrade, it is aborting the whole upgrade. A common workaround for that sort of problem is to uninstall the package that cannot be upgraded (in your case dnf remove ghdl, then try the upgrade again).
That shouldn’t be necessary in most cases. But in more extreme cases, it might be required. dnf distro-sync usually comes in handy when a “normal” transaction was started but aborted or failed mid-way through (e.g. due to a power outage). distro-sync tries to “blindly” update the packages one-by-one, just going by the package name, rather than trying to compose an upgrade transaction and doing pre-upgrade checks.
Since the upgrade transaction was not started in this case, distro-sync shouldn’t be necessary. Also, having the snapshot to fall back to should alleviate the need to use distro-sync. Instead, the user could restore the system to its previous state by rolling back to the previous snapshot and then retrying the normal dnf update from there.
Did you see the part where dnf system-upgrade seemed to download packages before I killed the process? The behavior I am seeing now did not occur before this. Also, there is no dnf info information returned, so where is this package I I should uninstall?
It is OK if it downloads the packages. It is only a problem if it begins installing packages and then the installation is killed. The error message in your screenshot appears to indicate that the actual installation process had not yet begun.
I guess dnf info would be looking in the online database for package information. Since that package doesn’t seem to exist on the servers your system is fetching packages from, that command also will not work. rpm -qi ghdl should work. It will retrieve the package info directly from the locally-installed package.
If I’m reading it correctly, that error is due to a special kind of package being used from the “modularity” subsystem. It allows installing versions of packages that are newer or older than what is being distributed from Fedora’s default package database and pinning them so they will not upgrade. It is an advanced feature that I try to avoid using.
There is some documentation for it here:
You probably need to switch to using the normal nodejs package instead of the one you’ve pinned from the modularity system.
