.

===========================================================================================================================
#Update opensuse 42.3 to Leap 15.0

#! /bin/bash
zypper mr -adR

#add new repos for upgrade - Ahtung : hinter http: müssen die "blanks" wieder entfernt werden

zypper ar -n "openSUSE-15.0 OSS"  http:   //download.opensuse.org/distribution/leap/15.0/repo/oss/ repo-15.0-oss
zypper ar -n "openSUSE-15.0 Non-OSS" http:    //download.opensuse.org/distribution/leap/15.0/repo/non-oss/ repo-15.0-non-oss
zypper ar -f -n "openSUSE-15.0 Updates OSS"  http:    //download.opensuse.org/update/leap/15.0/oss/ repo-15.0-update-oss
zypper ar -f -n "openSUSE-15.0 Updates Non-OSS"  http:    //download.opensuse.org/update/leap/15.0/non-oss/ repo-15.0-update-non-oss

#refresh zypper repository cache
zypper ref
===========================================================================================================================

Doch da fehlte noch etwas : die wichtigste Zeile :

• zypper clean -a && zypper dup

und nach vielen vielen Minuten - je nach Anbindung - es werden etwa 2 GB herunter geladen und installiert. Der Fluch der schnellen 3.4 GHz CPUs ist, der Text rast über den Bildschirm, man kann nichts mehr mitlesen.

• zypper refresh

.

Kapitel 13.1.2.2 - Shut Down Virtual Machines
If your machine serves as a VM Host Server for KVM or Xen, make sure to properly shut down all running VM Guests prior to the update. Otherwise you may not be able to access the guests after the update.
.
Wichtig soll sein, jede Update-Stufe einzeln anzukurbeln. Das Update von 42.x auf 15.3 soll angeblich nicht funktionieren. Es lohnt nicht, das auch nochmal selbst auszuprobieren.
.
Darum habe ich - wie in dem Forum vorgeschlagen - das Urscript dupliziert und entsprechend korrigiert.
.
-rw-r-xr-- 1 root 17. Feb 00:03 Upgrading-system-43.3-15.0
-rw-r-xr-- 1 root 17. Feb 2022  Upgrading-system-15.0-15.1
-rw-r-xr-- 1 root 17. Feb 2022  Upgrading-system-15.1-15.2
-rw-r-xr-- 1 root 17. Feb 2022  Upgrading-system-15.2-15.3

Diese Scripte - im /tmp/ Verzeichnis abgelegt - müssen ausführbar gemacht werden. Dazu braucht man den "mc", das geht am schnellsten.

.

Vorgabe aus dem Forum: Das Leap 15 musst Du dann natürlich durch die entsprechende 42.x Version ersetzen (also durch 42.3, danach dann auf Leap15)
===========================================================================================================================
#Upgrade Suse 42.3 to Leap 15 - (hier korrigiert auf 15.0)
#! /bin/bash
#deactivate other repositories
zypper mr -adR

#add new repos for upgrade

zypper ar -n "openSUSE-15.0 OSS"  download.opensuse.org/distribution/leap/15.0/repo/oss/ repo-15.0-oss
zypper ar -n "openSUSE-15.0 Non-OSS" download.opensuse.org/distribution/leap/15.0/repo/non-oss/ repo-15.0-non-oss
zypper ar -f -n "openSUSE-15.0 Updates OSS"  download.opensuse.org/update/leap/15.0/oss/ repo-15.0-update-oss
zypper ar -f -n "openSUSE-15.0 Updates Non-OSS"  download.opensuse.org/update/leap/15.0/non-oss/ repo-15.0-update-non-oss
#refresh zypper repository cache
zypper ref
===========================================================================================================================
zypper refresh
zypper clean -a && zypper dup
zypper refresh

Dieses "zypper refresh" ist bei mir nur zur Sicherheit, es ist nicht unbedingt notwendig.

===========================================================================================================================
#Upgrade Suse 15.0 to Leap 15.1

#! /bin/bash
zypper mr -adR

zypper ar -n "openSUSE-15.1 OSS"  download.opensuse.org/distribution/leap/15.1/repo/oss/ repo-15.1-oss
zypper ar -n "openSUSE-15.1 Non-OSS" download.opensuse.org/distribution/leap/15.1/repo/non-oss/ repo-15.1-non-oss
zypper ar -f -n "openSUSE-15.1 Updates OSS"  download.opensuse.org/update/leap/15.1/oss/ repo-15.1-update-oss
zypper ar -f -n "openSUSE-15.1 Updates Non-OSS"  download.opensuse.org/update/leap/15.1/non-oss/ repo-15.1-update-non-oss

#refresh zypper repository cache
zypper ref
===========================================================================================================================
zypper refresh
zypper clean -a && zypper dup
zypper refresh

===========================================================================================================================
#Upgrade Suse 15.1 to Leap 15.2

#! /bin/bash
zypper mr -adR

zypper ar -n "openSUSE-15.2 OSS"  download.opensuse.org/distribution/leap/15.2/repo/oss/ repo-15.2-oss
zypper ar -n "openSUSE-15.2 Non-OSS" download.opensuse.org/distribution/leap/15.2/repo/non-oss/ repo-15.2-non-oss
zypper ar -f -n "openSUSE-15.2 Updates OSS"  download.opensuse.org/update/leap/15.2/oss/ repo-15.2-update-oss
zypper ar -f -n "openSUSE-15.2 Updates Non-OSS"  download.opensuse.org/update/leap/15.2/non-oss/ repo-15.2-update-non-oss

#refresh zypper repository cache
zypper ref
===========================================================================================================================
zypper refresh
zypper clean -a && zypper dup
zypper refresh

===========================================================================================================================
#Upgrade Suse 15.2 to Leap 15.3

#! /bin/bash
zypper mr -adR

zypper ar -n "openSUSE-15.3 OSS"  download.opensuse.org/distribution/leap/15.3/repo/oss/ repo-15.3-oss
zypper ar -n "openSUSE-15.3 Non-OSS" download.opensuse.org/distribution/leap/15.3/repo/non-oss/ repo-15.3-non-oss
zypper ar -f -n "openSUSE-15.3 Updates OSS"  download.opensuse.org/update/leap/15.3/oss/ repo-15.3-update-oss
zypper ar -f -n "openSUSE-15.3 Updates Non-OSS"  download.opensuse.org/update/leap/15.3/non-oss/ repo-15.3-update-non-oss

#refresh zypper repository cache
zypper ref
===========================================================================================================================
zypper refresh
.
Und bringen Sie locker 1,5 Stunden Zeit mit. Es dauert. Wir haben hier einen 100 Mbit/s Kabel-Anschluß, der nach 23 Uhr fast immer in voller Geschwindigkeit funktioniert. Und dennoch, es dauert. Es sind jedesmal 2 Gigabyte in 1.900 kleinen Brocken.
.
Wenn Sie das bei sich durchführen wollen, kopieren Sie diese Scripte hier raus und bereinigen Sie die erst mal. So laufen die nicht durch.
.

Auch der 4. Durchgang ist mit nur einem Fehler durchgelaufen. Ob dieser Fehler "systemrelevant" war oder nciht ??

( 369/2306) kernel-default-5.3.18-lp152.106.1.x86_64  wird entfernt .............................................................................................................................................................[Fehler]
Entfernen von (95297)kernel-default-5.3.18-lp152.106.1.x86_64(@System) fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: /var/tmp/rpm-tmp.x5sUhA: line 1: /usr/lib/module-init-tools/kernel-scriptlets/rpm-preun: No such file or directory
error: %preun(kernel-default-5.3.18-lp152.106.1.x86_64) scriptlet failed, exit status 127
error: kernel-default-5.3.18-lp152.106.1.x86_64: erase failed

Abbrechen, wiederholen, ignorieren? [a/w/i] (a):

"ignorieren" war meine Entscheidung.

Jetzt steht die Bereinigung an. Ich darf natürlich auch beim Testen nicht verdrängen, daß ich später in der kritischen DOM-0 auf dem virtualisierten Server in Düsseldorf "remote" arbeite. Und der wird noch gebraucht. Also "Spielerchen" gehen da überhaupt nicht.
.

.

Und das ist für einen "remote" Server (in Düsseldorf) wichtig, ich muß ja mit "putty" wieder drauf kommen. Weiterhin muß ich den getunnelten "vnc-server" starten können und die Firewall für VNC öffnen.

Das stimmt natürlich nur zur Hälfte, weil eine der Upgrade Stufen (welche ?) eine neue sshd-config mitbringt und die alte in sshd-config.rpmsave umbenennt.

Die Bereinigung der alten nicht mehr gebrauchten Einträge der boot-Umgebung und der Repos geht mit den grafischen YAST2 (mit Maus) besser als mit YAST (nur mit der Tastatur). Dazu muß in der Firewall der VNC-Dienst freigegeben werden sowie der VNC-Server gestartet werden.
.

Doch der VNC-Server antwortet nicht ???? Schade, der VNC-Server nimmt keine Client-Logins an ???? Warum denn das jetzt nicht ? Es hatte mit 42.3 alles noch sauber funktioniert.
.

.

.

Bei unseren Servern in Düsseldorf ist der (sind alle) SSH-Port(s) ganz weit nach oben "verlegt". Wird eine neue sshd-config installiert und aktiviert, sind alle alten Einträge auf Standard zurückgesetzt. Meine SSH Ports sind weg von Port 22 auf den hohen Port 38xxx verlegt, sodaß sich die "Freunde aus den Ländern der aufgehenden Sonne" oder aus der östlichen Ostsee die Finger wund tippen oder die Script-Automaten mehrere Minuten pro IP-Nummer zum Scannen benötigen. Bei dem Test-Server stand noch Port = 22, darum kam ich sofort wieder drauf. In Düsseldorf wäre ich regelrecht "aufgeschmissen", wenn "putty" nicht mehr geht. Also  muß vorher der Port 22 im sshd-Dienst sowie in der Firewall wieder aktiviert werden. Die Firewall abzuschalten ist bei einer DOM-0 sehr unglücklich.
.

..... mußte ich lange suchen. Auf dem Testserver habe ich mehrere !!!!! Firewalls gelöscht, einschließlich der SUSE Firewall, weil immer noch die VNC Ports geblockt wurden. Das geht bei einem "Produktiv-System" draußen im Internet überhaupt nicht. In der neuen (vom Upgrade eingespielten) "sshd-config" wurde "tunneling" per Default auf "off" gesetzt. Dann geht natürlich keine VNC-Verbindung mehr !! Bis Sie da mal darauf kommen, dauert es.
.
Nach einigen fehlerhaften Versuchen ist es jetzt wieder möglich, über "SSH putty" die Windows-VNC Verbindung zu tunneln und so wieder eine gesicherte grafische Verbindung zum Server herzustellen. Die brauche ich wegen des XEN Virt-Managers.
.
Noch etwas zum "tight-vnc-server" und dem "ICEWM" Windows-Manager. Wurde bei dem ICEWM vorher eine andere Oberfläche ausgesucht und eingerichtet, sind nach dem Upgrade alle Texte in den Menüs weg sowie die Buttons für die 4 Konsolen. Also vorher die VNC Oberfläche wieder zurück auf Standard setzen.
.

Das hatte mich schon lange gestört, da ich im Texteditor "joe" im ssh-putty-Fenster die Texte raus und rein holen konnte, mit dem "joe" im VNC Fenster aber dort wieder nicht. Der VNC-Viewer unter Windows "könnte" es, der VNC-Server aber nicht.

Dazu brauchte man (laut Ubuntu-Forum) ein Zusatzprogramm mit Namen "autocutsel", welches im "Xstartup"-Script eingebaut werden muß. Zuerst "autocutsel" über YAST installieren und dann: Die VNC-Datei "Xstartup" findet man bei opensuse im Verzeichnis "/etc/X11/xdm/". Der neue Eintrag sollte ziemlich weit oben im Script stehen und "autocutsel -fork" lauten. Das habe ich ausprobiert, es funktioniert wirklich.
.

Die aktiven VMs soll/muß man zu Beginn unbedingt runter fahren und die automatische Startfunktion abschalten. Dann erst darf die Upgrade Session starten. Sonst sind sie im Virt-Manager nicht mehr sichtbar. Warum ? Da schweigt sich Suse aus. Jedenfalls muß ich die (imer noch vorhandenen VMs) wieder im Virt-Manager sichtbar machen.
.
Die ganze Virtualisierung startet aber nicht mehr. Wieder geht die Sucherei los.
.

.

Bitte beachten Sie als Gast und Leser, das sind unsere hausinternen Protokolle. Ich bin in keiner Weise mit irgend einer Firma oder einem Anbieter "verheiratet".
.

.