Update form Open SuSE 15.5 to 15.6
WalterH this is a very good question. I am using the appliance since end of 2023, the only additional packages I installed are zabbix client and bareos backup client. It looks like it was installed as a dependency of chromium.
dependencies:
libc++abi.so.1()(64bit) is needed by (installed) llvm17-libc++1-17.0.6-bp155.5.1.x86_64
libc++abi.so.1()(64bit) is needed by (installed) chromium-131.0.6778.204-bp155.2.153.1.x86_64
libc++abi.so.1()(64bit) is needed by (installed) chromedriver-131.0.6778.204-bp155.2.153.1.x86_64
libc++abi1 = 17.0.6 is needed by (installed) llvm17-libc++1-17.0.6-bp155.5.1.x86_64
So I'll uninstall chrome and give it another try. Thank you, your question helped to guide me into the right direction
WalterH Please note, with the script grommunio-update there is also a possibility to update to SuSE 15.6. However, no backup of the configuration is created and there is no possibility to compare the package before and after the update.
This recipe shows the manual update way which offers more possibilities and error checking.
Hallo zusammen,
ich bin ITler/Informatiker, betreibe aber mein System privat und mit der Zeit, die mir mit Beruf und Familie so bleibt.
Ich lese die Dokus und versuche diese auch zu verstehe und befolgen, jedoch ist das nebenbei m.E. schon ziemlich anspruchsvoll, zumal ich beruflich in der MS Welt lebe, lediglich meine privaten Server ausschließlich Linux.
Deswegen habe ich versucht, einen Snapshot zu machen und den schnellen Weg (grommunio-update upgrade) auf 2025.01.01 zu nehmen. Erhofft hatte ich dabei, dass wie oben zitiert, damit auch das Update von 15.5 auf 15.6 passiert.
Dem ist aber leider nicht so. Meine Installation sieht jetzt so aus.
Ich verwende Keycloak mit einer eigenen CA was ebenfalls den Update von 24.x auf 26.1 mitgemacht hat.
Soweit funktioniert lt. Tests auch alles wieder ok. Mir fehlt es allerdings am Verständnis - warum?
Ich hätte verstanden, dass 2025. 01.01 für 15.6 compiliert und gelinkt ist und somit die Version 15.6 braucht.
Wenn dem nicht so ist, wie sehe ich bis zu welchem Kernel die Version rückwärtskompatibel ist bzw. wann ich den Kernelschritt unbedingt machen muss.
Wieso wurde mit "grommunio-update upgrade" nicht auf 15.6 migriert, bzw. was muss ich tun, dass das script das macht oder muss ich wirklich den langen Weg gehen.
Vielen Dank
Klaus
- Edited
Das Update von 15.5 auf 15.6 ist hier im Text beschrieben: https://community.grommunio.com/d/1879-update-form-open-suse-155-to-156 , dabei wird auch auf die aktuelle grommunio Version upgedatet. Ja man muss die Schritte durcharbeiten.
- Edited
Bei dieser Art von Umstellung bin ich irgendwann aussen vor, das fängt schon in Schritt 17 an, dass ich 1 von 2 Services nicht starten kann. Welche wichtigen Unterschiede in Schritt 19 erscheinen können, ist unklar, bei Schritt 20 breche ich ab, da der Vorgang für mich nicht prozeßsicher funktioniert. Mit Schritt 21 geht es im Prinzip so weiter.
Ich bin nach wie vor der Meinung, dass es Scripte geben sollte, die Unwägbarkeiten ausschliessen, es Appliances geben sollte, die funktional vollständig funktionieren, ohne dass man erst darauf kommen muss. Die Admins vor Ort tragen das aus.
Andy Wenn bei Punkt 17. Services nicht starten, hatten die vermutlich vorher auch schon Probleme. Bei 19. klären ob alle Dienste wieder vorhanden sind, auch ob neue Dienste installiert wurden, ist aber nur zur Information. 20. man muss die alten Konfig Dateien an die neuen anpassen, auch die Kommentare. 21. wenn man die neuen Konfig Dateien löscht ohne die alten in 20. anzupassen, vernichtet man Wissen.
- Edited
WalterH Punkt 17. Services nicht starten, hatten die vermutlich vorher auch schon Probleme
Insofern ist in meiner laufenden Installation der eine betroffene Dienst ebenso down, allerdings ist da jetzt im laufenden Betrieb nichts davon bemerkbar.
localhost:~ # systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● searchd.service loaded failed failed Sphinx - SQL Full Text Search Engine
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed.
localhost:~ #
WalterH ... man muss die alten Konfig Dateien an die neuen anpassen ... die neuen Konfig Dateien löscht ohne die alten in 20. anzupassen,
Wäre es nicht umgekehrt? Muss man da nicht aus den Altdateien in die Neudateien übertragen? Und was passiert, wenn nichts verändert wird? Denn, wenn ich eine neue Appliance installiere und übertrage die Nutzdaten aus den Modulen, gehen im Grunde ansonsten ja auch Informationen verloren.
Ich muss mich korrigieren, in meiner Produktivinstallation laufen alle Dienste
localhost:~ # systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.
localhost:~ #
In einer Kopie davon, welche ich seit einiger Zeit für Tests verwende und mit welcher ich die obige Migration getestet hatte, läuft dieser Service nicht.
Die Frage wäre dennoch, welche der Schritte 19-21 wären ggf. verzichtbar, wenn deren Bearbeitung entsprechendes Know-How erfordern würde, welches aber ggf. nicht vorhanden ist.
- Edited
Ist diese Anleitung hier der einzige Weg von 15.5 auf 15.6 umzustellen?
Ich habe das wie in Post 1 beschriebene Script grommunio-update upgrade supported
laufen lassen. Allerdings führt dieses Script nicht das Update auf 15.6 durch.
Entweder diesen Weg oder Neuinstallation mit Datenübertragung.
grommunio-update upgrade [supported]
ist nicht anderes als ein zypper dist-upgrade welches so lange die repositories nicht geändert worden sind höchstens andere builds von den repo's holt im normalfall.
Befolge einfach Walter's anleitung oder wo hängts?
chats Das Script kann das: https://docs.grommunio.com/admin/operations.html#updating-grommunio
Der Nachteil vom Script ist aber, das man keine Kontrolle über den Update Prozess hat und bei einem Fehler erst am Ende sieht das es nicht funktioniert hat. Daher meine Anleitung die mehr Informationen liefert und Möglichkeiten zum Eingreifen bietet.
- Edited
WalterH mehr Informationen liefert und Möglichkeiten zum Eingreifen bietet.
Das ist aus dieser Sicht richtig, ich unterstelle aber, ich gehe da auch von mir aus, dass nicht jeder damit nichts anfangen kann, weil Kenntnisse fehlen. Ich bevorzuge daher die Neuinstallation und Datenübertragung.
Innerhalb von max. 30 Minuten ist das erledigt. Wenn ein Vorgang aber Interpretationen zulässt, die nicht jeder durchdringen kann, wird es für nicht so kundige schwierig.
- Edited
WalterH Das Script kann das: https://docs.grommunio.com/admin/operations.html#updating-grommunio
Wüsste ich nichts von und im git repo ist noch der alte kram drin sowie auf den installierten systemen..
grom-test-4:~ # rpm -q grommunio-admin-common
grommunio-admin-common-42.e17ec55-lp156.36.1.noarch
grom-test-4:~ # grep -Po '15.?([0-9])?.*' /etc/zypp/repos.d/* /usr/sbin/grommunio-repo /usr/sbin/grommunio-update
/etc/zypp/repos.d/base.repo:15.6/repo/oss
/etc/zypp/repos.d/base.repo:15.6/oss
/etc/zypp/repos.d/base.repo:15.6/repo/oss
/etc/zypp/repos.d/base.repo:15.6/oss
/etc/zypp/repos.d/base.repo:15.6/repo/oss/
/etc/zypp/repos.d/grommunio-base.repo:15.6/repo/oss
/etc/zypp/repos.d/grommunio-base.repo:15.6/oss
/etc/zypp/repos.d/grommunio-base.repo:15.6/sle/
/etc/zypp/repos.d/grommunio-base.repo:15.6/backports/
/etc/zypp/repos.d/grommunio-base.repo:15.6/repo/oss
/etc/zypp/repos.d/grommunio-base.repo:15.6/oss
/etc/zypp/repos.d/grommunio-base.repo:15.6/sle/
/etc/zypp/repos.d/grommunio-base.repo:15.6/backports_debug/
/etc/zypp/repos.d/grommunio-base.repo:15.6/repo/oss/
/etc/zypp/repos.d/grommunio.repo:15.6/?ssl_verify=no
/usr/sbin/grommunio-repo:15.[34]#${VERSION_ID}#g" /etc/zypp/repos.d/*.repo > /dev/null 2>&1
/usr/sbin/grommunio-update:15 Minutes: "$5 }')
Da ist keine mechanik drin die von 15.5 auf 15.6 aktualisiert weil die ziffer 5 nach der 34 fehlt was es dann jedoch einfach ohne nachfrage machen würde durch ein klicken auf update im admin-web...
Also sofern man in die datei /etc/os-release
einfach mal 15.6 eintragen würde jetzt wo das auch genutzt wird \o/
- Edited
Ich habe da mal an einem Klone meiner Produktiv-VM mit Leap 155 getestet: Ersetzen der Einträge 15.5 -> 15.6 in
/etc/zypp/repos.d/base.repo
/etc/zypp/repos.d/grommunio.repo
/etc/zypp/repos.d/grommunio-base.repo
/etc/os-release
und zypper --verbose ref -f && zypper --verbose dup
ausgeführt:
Die folgenden 478 Pakete werden aktualisiert:
adwaita-icon-theme 41.0-150400.1.10 -> 45.0-150600.1.2
alsa 1.2.8-150500.1.1 -> 1.2.10-150600.2.3
alsa-ucm-conf 1.2.8-150500.1.1 -> 1.2.10-150600.1.2
alsa-utils 1.2.8-150500.1.2 -> 1.2.10-150600.3.3.6
.
.
.
Das folgende Schema wird aktualisiert:
grommunio 1-lp155.9.1 -> 1-lp156.9.1
Die folgenden 10 Pakete werden durch eine ältere Version ausgetauscht:
libprotobuf-lite20 3.9.2-150200.4.24.1 -> 3.9.2-150200.4.21.1
libtiff5 4.0.9-150000.45.47.1 -> 4.0.9-150000.45.41.1
php8-redis 5.3.7-lp155.1.9 -> 5.3.7-bp156.2.5
python3-argcomplete 1.9.2-150000.3.8.1 -> 1.9.2-150000.3.5.1
python3-dnspython 1.15.0-150000.3.10.2 -> 1.15.0-150000.3.2.1
python3-Jinja2 2.10.1-150000.3.18.1 -> 2.10.1-3.10.2
python3-PyYAML 5.4.1-150300.3.3.1 -> 5.4.1-1.1
python3-requests 2.25.1-150300.3.12.2 -> 2.25.1-150300.3.6.1
python3-urllib3 1.25.10-150300.4.12.1 -> 1.25.10-150300.4.9.1
python3-Werkzeug 1.0.1-150300.3.8.1 -> 1.0.1-150300.3.3.1
Die folgenden 48 NEUEN Pakete werden installiert:
kernel-default 6.4.0-150600.23.42.2
libavc1394-0 0.5.4-1.27
libb2-1 0.98.1-150400.1.4
libbpf1 1.2.2-150600.3.3.1
libc++1 19.1.7-bp156.4.2
libc++abi1
.
.
.
Die folgenden 4 Pakete werden GELÖSCHT:
libsemanage1 3.1-150400.3.4.2
llvm17-libc++1 17.0.6-bp155.5.1
llvm17-libc++abi1 17.0.6-bp155.5.1
systemd-sysvinit 249.17-150400.8.46.1
Das folgende Paket erfordert einen Systemneustart:
kernel-default 6.4.0-150600.23.42.2
478 Pakete werden aktualisiert, 10 werden zurückgestuft, 48 neue, 4 zu entfernen.
Größe des Pakets zum Herunterladen: 1,18 GiB
Änderung der Installationsgröße des Pakets:
| 4,30 GiB erforderlich für Pakete, die installiert werden sollen
445,7 MiB | - 3,86 GiB freigegeben von Paketen, die entfernt werden sollen
Hinweis: Systemneustart erforderlich.
Backend: classic_rpmtrans
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):
Insgesamt wurden 539 Pakete heruntergeladen und installiert, wobei auffällig war eigentlich nur das
Nach einem Reboot am Ende scheint die VM ohne ein Problem mit Leap 156 zu laufen. Wäre das vielleicht ein sicherer Weg?