Upgrading system: 42.3 -> 15.0 -> 15.1 -> 15.2

I’m going to upgrade my system (finally) from 42.3 to 15.2 ,but reading documentation I see I need to do it step by step (from version to version).

I had all packages updated to last version available in version 42.3 repository.
I have change my repositories to version 15.0:


base:~ # zypper repos -E --uri
Repository priorities are without effect. All enabled repositories share the same priority.


...| Enabled | GPG Check | Refresh | URI                                                              
...+---------+-----------+---------+------------------------------------------------------------------
...| Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/distribution/leap/15.0/repo/oss/    
...| Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/distribution/leap/15.0/repo/non-oss/
...| Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.0/non-oss/           
...| Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.0/oss/    

When I tried to do the Update Zypper and the package management itself, there are problems:


base:~ # zypper patch --updatestack-only
Loading repository data...
Warning: Repository 'openSUSE-Leap-15.0-Update-Non-Oss' appears to be outdated. Consider using a different mirror or server.
Warning: Repository 'openSUSE-Leap-15-0-Update' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...
Resolving package dependencies...
7 Problems:
Problem: PackageKit-branding-openSUSE-42.1-4.1.noarch requires PackageKit = 1.1.3, but this requirement cannot be provided
Problem: libyui-ncurses-pkg7-2.48.4.1-5.3.1.x86_64 requires libzypp.so.1600()(64bit), but this requirement cannot be provided
Problem: libyui-qt-pkg7-2.45.13.1-2.3.1.x86_64 requires libzypp.so.1600()(64bit), but this requirement cannot be provided
Problem: deltarpm-3.6.1-10.4.x86_64 requires librpm.so.3()(64bit), but this requirement cannot be provided
Problem: libsnmp30-5.7.3-7.3.1.x86_64 requires librpm.so.3()(64bit), but this requirement cannot be provided
Problem: libsnmp30-5.7.3-7.3.1.x86_64 requires librpm.so.3()(64bit), but this requirement cannot be provided
Problem: perl-Authen-SASL-2.16-10.1.noarch requires perl(:MODULE_COMPAT_5.18.2), but this requirement cannot be provided


Problem: PackageKit-branding-openSUSE-42.1-4.1.noarch requires PackageKit = 1.1.3, but this requirement cannot be provided
  deleted providers: PackageKit-1.1.3-5.6.1.x86_64
 Solution 1: downgrade of PackageKit-branding-openSUSE-42.1-4.1.noarch to PackageKit-branding-openSUSE-42.1-lp150.1.11.noarch
 Solution 2: do not install patch:openSUSE-2019-1597-1.noarch
 Solution 3: break PackageKit-branding-openSUSE-42.1-4.1.noarch by ignoring some of its dependencies


Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c] (c): c

System doesn’t show any problem with dependencies with ‘zypper verify’ : "Dependencies of all installed packages are satisfied."

These are others packages “PackageKit-branding”:


base:~ # zypper search -s PackageKit-branding
Loading repository data...
Warning: Repository 'openSUSE-Leap-15.0-Update-Non-Oss' appears to be outdated. Consider using a different mirror or server.
Warning: Repository 'openSUSE-Leap-15-0-Update' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...

S | Name                         | Type    | Version            | Arch   | Repository               
--+------------------------------+---------+--------------------+--------+--------------------------
i | PackageKit-branding-openSUSE | package | 42.1-4.1           | noarch | (System Packages)        
v | PackageKit-branding-openSUSE | package | 42.1-lp150.1.11    | noarch | openSUSE-Leap-15-0       
  | PackageKit-branding-upstream | package | 1.1.10-lp150.11.1  | noarch | openSUSE-Leap-15-0-Update
  | PackageKit-branding-upstream | package | 1.1.10-lp150.8.1   | noarch | openSUSE-Leap-15-0-Update
  | PackageKit-branding-upstream | package | 1.1.10-lp150.3.3.1 | noarch | openSUSE-Leap-15-0-Update
  | PackageKit-branding-upstream | package | 1.1.10-lp150.2.1   | noarch | openSUSE-Leap-15-0       


What should I do with “PackageKit-branding-openSUSE”? Should I downgrade as it is in solution 1?
Solution 1: downgrade of PackageKit-branding-openSUSE-42.1-4.1.noarch to PackageKit-branding-openSUSE-42.1-lp150.1.11.noarch

What should I do with others problems? ( libyui-ncurses… , deltarpm… , etc.)

Don’t forget that you’re doing a distribution upgrade as opposed to a regular update.

With your repositories set as you have to Leap 15.0 (for the first stage), you need to use “zypper dup”, and then repeat for the remaining distribution upgrades.

It may be quicker, and perhaps beneficial, to consider a fresh install of 15.2 keeping your existing home.

Yes, true.
But before I do zypper dist-upgrade , I need to do “zypper patch --updatestack-only” – according to documentation: Upgrading the System and System Changes | Start-Up | openSUSE Leap 15.0

and I get stuck on step “zypper patch --updatestack-only” …

Should I omit the step with “zypper patch --updatestack-only” and go directly to “zypper dist-upgrade” ?

While I am already surprised that those repos from 15.0 are still available, like @tannington I am afraid that you could run int all sorts of problems were we can only try a best effort to help you because possibly not many here will have done an upgrade from an unsupported version to an also unsupported version.

In any case doing a zypper patch is not the way to upgrade from 42.3 to 15.0. You need a zypper dup then.

And, like @tannington, I assume that one fresh install instead of three upgrades might give less of a headache.

Additional comment.

I went to that page (more an archive now 15.0 is long out of support), and read about the --updatestack. I never did that. So it may be that you can do without it. OTOH it maybe simething peculiat to 42.3 > 15.0.

I did an update from 42.3 to 15.2. And it went fine.

I am not recommending this. I did it as a test. I changed the repos, then used “zypper dup”. And yes, there were some conflicts that I had to manually resolve.

I should add that this was done in a virtual machine, intended as a test and then throw away. On my actual physical computers, I always do a clean install (but keeping “/home”).

I’ve dup’d over intermediate releases many times in the Leap series, including directly from 42.3 to 15.2. I don’t go straight to dup though. After updating to the target repos, I do something akin to --updatestack, using this script:

#!/bin/sh
# /usr/local/zypstart
zypper -v in --download-in-advance zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl libcurl openSUSE-release
zypper -v in --download-in-advance device-mapper glibc multipath-tools mdadm systemd udev

Once I’m satisfied with the result, I do:

zypper dup

It might be worth trying my process to goto 15.0, then 15.1, then 15.2.

When I get a conflict/dependency problem with the script, my normal procedure is to ID whether the dep is important at the current stage of the upgrade, and usually it isn’t very, so I rpm -e --nodeps the impediment and try again. Sometimes when there’s a problem I choose the last option, “break <something>” that wouldn’t matter while the upgrade is proceeding. The dup will usually bring things related to the purge or “breakage” back into line, testable with zypper verify. Tumbleweed has worked zypper well enough that it has evolved to become seriously outstanding package management, one of the top reasons to choose and stick with openSUSE.

It’s a long, risky process upgrading that many times, you might trial the upgrades virtually as you’ve started to do.
The above posts are well worth considering although the “patch --updatestack” is not described in the most used guide “SDB System upgrade”
Updating zypper is probably unnecessary… It hasn’t changed much over the years, and any changes have added new features which wouldn’t be used for an upgrade.
A caution using the following SDB… It now describes using the $releasever variable instead of explicitly identifying the version which might be supported only in recent zypper versions… So, you’d be advised to use the sed command to modify your zypper repo configurations at each step.

https://en.opensuse.org/SDB:System_upgrade

FYI
Here are the OSS repos for each LEAP version, you should be able to use the repository URLs for each version.

https://ftp.gwdg.de/pub/opensuse/discontinued/distribution/leap/

Here are the update repositories for each LEAP version, it’s highly advisable you “zypper up” to these repositories before you “zypper dup” to the next version

https://ftp.gwdg.de/pub/opensuse/discontinued/update/leap/

Good Luck,
TSU

I’m after upgrade to the version 15.2 (and the system is still “alive” :slight_smile: - we will see how long ;))

True that this is not very easy process, but the worst case was upgrade from 42.3 to 15.0.

Usually (in every upgrade step) I was agreeing with ‘zypper’ suggestion to downgrade some packages. Vendor of many packages have been changed (from “packman” repository to official openSUSE repository).

I don’t understand what is/was behind the decision to downgrade the packages between versions, and I would like to read something about that. If someone know where to find information about it, please share.

I agree that installation of pure version openSUSE 15.2 is less headache process :slight_smile: But how then can we learn …

And I did like you suggested: directly “zypper dist-upgrade” because “patch --updatestack” shown too many problems which I had not sure how to resolve. The good approach is use “–dry-run” option and “–download” option before upgrade. After “–dry-run” I have been trying to decide what to do with package which could make a problem.

I have found for every version, an information to go with “zypper patch --updatestack-only” before “zypper dup” - and I’m not really sure that it is a correct approach::

The trick with variables ("–releasever") (which is also here https://en.opensuse.org/SDB:System_upgrade) is worth to do with such long run.

Thank you all for hints.
Cheers!

About your question about downgrading.

When you disable/remove the Packman repo during the upgrade work, the first upgrade will switch back from the Packman packages to the OSS packages and that can involve a downgrade.

After you have done all the upgrades, you should add the new (for 15.2) Packman repo and then do the “Vendor Switch to Packman”.