upgrade from Opensuse 13.1 to LEAP 42.3 best practices?

Dear fellow Admins,

here is a laptop that ran OpenSUSE 13.1 'Bottle` Evergreen for a long while.
(With additional stable KDE 4 repos with KDEpim and Plasma.)

Now I want to upgrade it and aim for LEAP 42.3.
I’ve read through a number of pages and did some searches.

The official guide I get via opensuse.org -> Install LEAP -> https://en.opensuse.org/SDB:System_upgrade
tells me:

**Warning: Do not skip a release when upgrading! Example: do *not upgrade from 13.1 to 42.1. ***

This would mean for me to do four upgrades: -> 13.2 -> 42.1 -> 42.2 -> 42.3
Is this really meant this way and a good approach? Are all packages available for all versions?
It seems a bit tedious to me and there is a risk that something fails at one stage.

Also an offline upgrading approach is said to be

safer and more versatile

As my root file system is not btrfs, I’m not moving /var/cache to another subvolume.

What I’ve learned is that going for an offline upgrade via usb-stick probably is better than trying
the upgrade online. As for doing for upgrade I’m unsure. I’m did a couple upgrades with zypper and
I have a fairly good understanding of GNU/Linux systems, so I tend to try a direct upgrade 13.1 to 42.3 and rather deal
with the upcoming issues than potentially having issues on all four steps.

Did someone try this? I’m grateful for hints, improvement suggestions and experiences.

Best Regards,

This recent thread may be relevant…

Make sure you backup any important data fiirst before proceeding with the upgrade. (I generally prefer the online method with zyper dup).

Thanks for pointing to the other thread.

Is there any particular drawback of the offline method?
(I haven’t seen a more in-depth comparison of the two methods,
except the statement that the offline method is more safe and versatile.)

I like the online method allowing minimal downtime and fully upgraded system in one sweep, but if in doubt choose the offline method.

The definitive answer is, as always, in the Release Notes:

There was a note somewhere that, " # zypper dup" is not recommended for upgrades between major releases but, I can’t quickly put my finger on it . . .

Assuming that, you’ve backed up all the system settings, system fonts, user directories and /srv directories, a 13.1 to Leap 42.3 upgrade by means of booting the Leap 42.3 DVD, with an Ethernet cable connected – to pull in the latest patches – should simply work.
By backup of the user directories I also mean that, each user’s Kontact PIM data should be exported to the user’s Kontact archive directory structure.

Be aware that, after the upgrade, the user’s GUIs will migrate at the first login. For each user there will some extra effort to check that, the KDE4 Plasma to KDE Plasma 5 migration has executed correctly.
Check especially the Kontact PIM files: everything is now in “~/.local/share/” and ~/.config/ . . .
Be aware that, the KOrganizer appointments and tasks may unexpectedly migrate from ~/.kde4/ to the Kontact archive directory structure.

Leap 42.? is quite happy with ext4 system partitions – my desktop system has separate partitions for /tmp, /var and /srv.

So I’ve used an offline upgrade via usb-drive, configured an additional wlan access and ignored the incompatibility warning.
The upgrade went fine and the system rebooted right away.

A bit more about my setup:

  • two harddrives, with crypto setup. One SSD with a dual-boot windows 7 setup and another spinning drive with extra data.

  • Laptop with intel on-chip-graphics and second Radeon graphic card.

  • Using a Plasma Desktop and KDE Pim (aka Kontact).

I still have to do more tests, especially the Kontact/Akonadi
wanted the account configuration from me and then took a very long break
which I had to interrupt.

Graphics were only on the Intel card. I haven’t checked to enable the radeon for some application
(I may have even disabled it for GNU/Linux in the old configuration).

Additional tests have to come for scanning (were I had to use a binary only sane driver backend before)
and printing.

Thanks again for your help and for the OpenSUSE GNU/Linux distribution
(I there is a place where I can pay some Euros voluntaringly to support your work, let me know.)
Best Regards,

I’m not a member of the “trust totally, completely, encrypted disks” community.

  • Given the encryption changes which may occur as part of a major operating system upgrade – any operating system – I can only suggest that, all major operating system upgrades should only be performed on non-encrypted drives.
  • Once the upgrade has been successfully completed and, checked, then, of course encryption can be re-applied to the system’s drive(s) – with the encryption supplied with the new version of the operating system.

Given the major KDE change from 13.2 to Leap – “KDE4 Plasma” to “KDE Plasma 5” – despite, the KDE migration routines, it always pays to export and/or archive all the Kontact data – e-Mails; address book; appointments; tasks; journals; notes; etc., etc. – before the operating system upgrade. Usually, the KDE4 to Plasma 5 migration functions without any major issues but, IMHO, it is better to setup the Plasma 5 Kontact environment “fresh” (new) and then, to import the KDE4 data into the new Kontact configuration.

Intel/AMD dual-graphics hardware is not as easy as “pure” AMD dual-graphics but, there is an ArchWiki page which may provide some insights:
Section “Hybrid graphics/AMD Dynamic Switchable Graphics” here: <https://wiki.archlinux.org/index.php/ATI&gt;

On the main openSUSE page <https://www.opensuse.org/&gt; there’s a section “CONTRIBUTE TO OPENSUSEBe part of our community contributing with any of the following:”

There’s also a German (only) boxed DVD which diverts some of the Euros received to the openSUSE project.

For me ( and for openQA ) this means your install was quite stock distro, i.e. no exotic repos.
And no, we don’t have a donation system. A thing like that needs maintenance, a legal entity, accounting etc etc. Like Don writes, we do like contributions, very much. And your posts here are a very good start. Thanks for sharing.

Don’t overlook that everything described in posts up to this point are only about the OS itself.
If you are running any applications, particularly database applications, they must be handled separately.