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-syncSupposing 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.
Attachment:
pgpY8gIL1xpLJ.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
