Eyal Lebedinsky writes:
What is the correct way to complete the upgrade? (I kept an image of
the
failure).
Unfortunately, there is no cookie-cutter, paint by numbers, recipe for
recovering from this kind of a botch. Chances are good that this situation
is salvageable, especially since you can boot and have a semi-stable system
to work in, apparently. But correctly recovering from this fail requires a
mandatory, complete understanding how rpm, dnf, and packages work, and by
having sufficient background and experience to be able to analyze the state
of the current system, and using one's knowledge of rpm and dnf to figure out
how to reach a stable state.
To start with, it is not the kernel package version that determines what
version of Fedora you are running. I believe that it is the fedora-release
package.
So the first thing I would do is check which version of fedora-release is
installed, in order to establish a baseline. Generally, the chances of
success are better, with a partially aborted system upgrade, to try to reach
the new version of the distro, rather than attepmt to recover to the
previous version, given that newer versions of at least some packages were
already installed, and you can't just uninstall a newer version and expect
all the files from the previous version, which got overwritten by the newer
version during the upgrade, to reappear from /dev/null. Once an upgrade has
started, there's no going back, only forward.
Assuming that I have only fedora-release-27 installed, the next thing I
would do is
dnf distro-sync
Supposing that distro-sync comes up with some kind of a plan, I would look
at the list of packages it will attempt to install and remove, reconcile it
with the version of fedora-release that's on the system, and see if what dnf
is proposing to do here makes any sense. If so, I'd give a shot. If not,
I'll try to figure out what plan B is.
However in your case you also apparently have multiple releases of the same
packages installed. Not sure what the end result of doing a distro-sync in
that situation is going to be.
And if one of those multiple releases is the fedora-release package itself,
with both the 26 and 27 versions, then I would manually try to rpm -e the 26
release, with --force if necessary, before proceeding.
If I do not have fedora-release-27 installed, given that the upgrade has
started, and given that some packages were already installed, I would then
download fedora-release-27 myself, and attempt to upgade it with rpm -UvhF,
and force the upgrade, if necessary, before trying distro-sync.
Again, as I said, there is no paint-by-numbers, cookie-cutter recipe from
recovering from this kind of a failed upgrade. It's mostly improvisation,
looking at what packages are or are not installed, and figuring out what to
do next. For example, I would not hesitate to manually resolve the situation
of both F26 and F27 versions of, say, ImageMagick installed by manually "rpm
-e"-ing the F26 version. But I wouldn't be so quick to pull the trigger
with, say, glibc, at least not without having a better grasp of the current
situation.
Then there's also the fact that it takes, at least for me, on average of no
more than an hour or two to install Fedora on an empty box. If my initial
analysis of the situation indicates it's going to be a long road to haul,
would just salvage whatever data I can grab, and just reformat and reinstall
from scratch. It makes no sense to piddle away an entire day fixing a borked
upgrade, if I can kick off a fresh install before breaking for lunch, then
come back and spend ten minutes restoring my files, and setting everything
up again.