In the process of upgrading a production machine, the tmux session was borked accidentally and the system was left in a partially upgraded state. Unfortunately, this is a production server and I would really prefer to not remove it from service for the time required to rebuild and restore backups.
In the past, booting from the appropriate ISO and performing the upgrade has worked fine, but this time it failed - it did not detect partition with the old version, and when I tried to select it manually the network would not configure properly so I aborted the process.
What is the recommended procedure for recovering from a failed upgrade? Can’t seem to find any previous posts here in the forums. This particular upgrade was 13.2 -> 42.1, but it would seem to apply to any version upgrade failure.
Doing a network upgrade?? you don’t need network connection if you use a full iso.
Not recognizing previous install means that may be significant missing packages perhaps partially installed packages due to interrupted upgrade. Note that both 13.2 and 42.1 are past EOL
Of course, … Doing an ISO upgrade requires downing the machine, … doing it online at least preserves operation.
Ahh, … that’s the purpose OF the upgrade, … the problem is not version specific.
So you are trying to upgrade via zypper??? VM’s involved??
Since both version are EOL and repos are now dead where are you trying to upgrade from if not an ISO/DVD/USB. Are you doing this at the hardware or doing it remotely?? Details are important.
Of course, … what else is there? Per the OP - I do not want to take the machine down if possible.
Sorry, … details are NOT important. The question remains - how does one recover from a borked upgrade? ANY [resonably current] version to ANY next [reasonably current] version? If you want to talk about versions, consider 42.1 -> 42.2. The process is the same for an upgrade, … how would one recover from a borked upgrade in that case?
More specifics, if you wish, sans versions:
-
Upgrade interrupted; zypper up/dup shows 90+ packages will not be installed; trying to force any of them leads to a nightmare of broken dependencies.
-
Replacing the repos with the previous version (& zypper ref) shows no upgrades required, yet there are about 100 packages installed from the next version (IIRC, it started with 254, so that is a guess of where the process was when it was interrupted).
-
Replacing the repos again with the next version (& zypper ref) shows 75 broken dependencies for yast, and many many more if one continues.
-
Running yast under the previous version (after setting those repos & zypper ref) throws the following error:
yast
WARNING: Nokogiri was built against LibXML version 2.9.1, but has dynamically loaded 2.9.4
Maybe the question should be: How does one identify and/or purge the system of packages installed past the current repositories (i.e. after going back to the previous version repos)?
Ok back up can you boot to the system?? or is the system running? So far your explanations are lacking in the detail to know the exact state of the system. We can not look over your shoulder
Since the 13.1 and 41.1 repo no longer exists (yes may be some place but not at the official address) exactly what URL are you setting the upgrade from?? This is why details are important.
If you had done this 9 months or so ago I’d tell you to set repos back to original URLs and do a zypper dup to get back. But since they no longer exist that may be difficult unless you can find them archived somewhere. I don’t know where maybe someone else can point to some. OpenSUSE LEAP will move in 18 month steps https://en.opensuse.org/Lifetime
So since 42.3 is about to come out 42.2 has about 6 months life left. Since you run a production server you may want to consider SLES which has a longer shelf life or be aware of changes and upgrade more often.
If me I would consider doing a zypper upgrade to 42.2 at this point but have a real install disk available if you run into problems and try an upgrade from there. Yes that would require downing the server for say about an hour if all goes well. This is why it is wise to have a test server available with the same hardware to be sure things go well before committing to a new OS on the live server. That is SOP for any 99.99 24/7 server requirement.
That was intentional, to avoid the distractions just like this one. I you don’t know the difference between up & dup, why bother replying?
Since the 13.1 and 41.1 repo no longer exists (yes may be some place but not at the official address) exactly what URL are you setting the upgrade from?? This is why details are important.
NOPE! 13.2 and 42.1 are still there, …
After spending some time borking and un-borking a VM, here are the results of my testing:
13.2 -> 42.1 -> BORK -> 13.2 can be done quite easily with dup! The only problem I had was when doing 42.2 -> 42.3 and could not get the VirtualBox kernel module to build, looks like the 4.4.75 kernel is not ready for prime time.
Conclusions:
-
dup is very good at resolving package versioning issues - it should be run on a regular basis!!
-
Both upgrades AND downgrades can be completed successfully with dup!!
-
At this point, the 4.4.75 kernel is not ready for prime time, … don’t bother going there if you have any utilities that depend on building kernel modules (i.e. VirtualBox). In addition, I saw some notes that Radeon support was changing, so it may take some time before it will be ready.