**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.
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.
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>
On the main openSUSE page <https://www.opensuse.org/> there’s a section “CONTRIBUTE TO OPENSUSE – Be 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.