UCS Fehlschlag Upgrade 2.4-4.9 -> 3.0-0.0

Nachdem ein UCS-PDC-Testsystem nach meinem Dafürhalten erfolgreich von 2.4-4.9 auf UCS 3.2 gebracht werden konnte (Parallelbetrieb UCS 3.x - UCS 2.4-4.9), wollte ich das nun auch im Echtsystem durchführen. Auch hier verlief das ganze relativ problemlos bis zu dem Zeitpunkt (ziemlich am Ende des Installatinsdurchgangs), an dem das System (nach meiner Interpretation) den Bootloadereintag manipulieren wollte. Nachdem das System ins updater.log längere Zeit nichts mehr hineingeschrieben hatte und die entsprechenden Versionsvariablen auf Version 2.4 hinwiesen, bootete ich das System selbst und bekam kurze Zeit später den … GRUB-Prompt !?. Daraufhin habe ich sofort den Snapshot für das System wieder hergestellt und bin so wieder auf Stand 2.4-4.9. Sowohl Test als auch Echtsystem sind virtuelle Maschinen. Leider habe ich aufgrund des Snapshotrestore keine Logfiles (die ich eigentlich nach Reboot ermitteln wollte).

Ich hatte vorher mit dem Skript univention-prune-old-kernel die /boot-Verzeichnisse beider Systeme von alten Kernels bereinigt. Schon beim Update des Testsystems bekam ich die Meldung, ich müsste Grub manuell installieren (Ursache ist hier aber m.E. die Erweiterung der Volumegroup vg_ucs-rootfs mit Hilfe einer weiteren Platte /dev/sdb, so dass grub nicht weiss auf welche “phys.” Platte geschreiben werden soll).
TESTSYSTEM ox4ucs24

version/erratalevel: 3
version/patchlevel: 0
version/releasename: Borgfeld
version/security-patchlevel: 9
version/version: 3.2

root@ox4ucs24:/boot# uname -a
Linux ox4ucs24 2.6.32-ucs62-amd64 #1 SMP Mon Apr 23 18:58:05 UTC 2012 x86_64 GNU/Linux
root@ox4ucs24:/boot# ls -ltr
insgesamt 18953
drwx------ 2 root root    12288 28. Apr 2010  lost+found
-rw-r--r-- 1 root root   167264 18. Sep 2011  memtest86+_multiboot.bin
-rw-r--r-- 1 root root   165084 18. Sep 2011  memtest86+.bin
-rw-r--r-- 1 root root  2511104 23. Apr 2012  vmlinuz-2.6.32-ucs62-amd64
-rw-r--r-- 1 root root  1712194 23. Apr 2012  System.map-2.6.32-ucs62-amd64
-rw-r--r-- 1 root root   106189 23. Apr 2012  config-2.6.32-ucs62-amd64
-rw-r--r-- 1 root root 14640684  1. Dez 23:07 initrd.img-2.6.32-ucs62-amd64
drwxr-xr-x 5 root root     7168  3. Dez 19:43 grub
-rw-r--r-- 1 root root      318  3. Dez 19:43 boot.msg

ECHTSYSTEM ox

[code]
version/patchlevel: 4
version/releasename: golden beech
version/security-patchlevel: 9
version/version: 2.4

root@ox:/etc# uname -a
Linux ox 2.6.32-ucs62-amd64 #1 SMP Mon Apr 23 18:58:05 UTC 2012 x86_64 GNU/Linux
root@ox:/boot# ls -ltr
insgesamt 15266
-rw-r–r-- 1 root root 124152 10. Sep 2009 memtest86+.bin
drwx------ 2 root root 12288 11. Mai 2010 lost+found
lrwxrwxrwx 1 root root 1 11. Mai 2010 boot -> .
-rw-r–r-- 1 root root 318 31. Dez 2011 boot.msg
-rw-r–r-- 1 root root 2511104 23. Apr 2012 vmlinuz-2.6.32-ucs62-amd64
-rw-r–r-- 1 root root 1712194 23. Apr 2012 System.map-2.6.32-ucs62-amd64
-rw-r–r-- 1 root root 106189 23. Apr 2012 config-2.6.32-ucs62-amd64
-rw-r–r-- 1 root root 11094264 9. Mai 2012 initrd.img-2.6.32-ucs62-amd64
drwxr-xr-x 2 root root 1024 9. Mai 2012 grub[/code]

Auffälligerweise sind beide Versionen identisch (bei 2.4 eventuell schon mit Sec9 reingekommen). Anhängend das Logfile, das die “erfolgreiche” Installation auf dem Testsystem protokolliert (für den Fehlversuch hab ich ja leider nichts).

Gibt es noch Hinweise, wie das ganze doch noch realisiert werden kann (UCS 2.4-Support läuft aus!)?
updater.log.1.gz (191 KB)

Hallo,

ohne konkrete Meldungen ist es natürlich relativ schwer, hier profilaktisch Dinge zu prüfen.
Wenn ich Sie korrekt verstehe, hat das Update auf einem Klon des Produktivsystems auch funktioniert.

Wahrscheinlicher ist hier eher, dass zu Beginn des Updates der Kernel entfernt wurde (Stichwort univention-prune-old-kernel) und Sie das System vor Einspielen des aktuellen Kernels resettet haben:

Das sollte natürlich keinesfalls gemacht werden - ein laufendes Update (auch wenn es augenscheinlich nichts mehr "tut/protokolliert) abzubrechen und das System neuzustarten kann diverse Fehler nach sich ziehen.

Das einfachste wird es sein, wenn Sie einen aktuellen Snapshot des Systems erstellen und das Update in einem entsprechenden Wartungsfenster erneut durchführen.
Sollten Sie wider Erwarten erneut das Gefühl haben, dass “nichts” mehr passiert, würde ich Sie bitten uns ein wie in SDB-Artikel #1174 beschriebenes Univention-Support-Info Archiv zu diesem Zeitpunkt erstellen - dann können wir uns das Verhalten einmal anschauen.

Mit freundichen Grüßen,
Tim Petersen

Danke für die Antwort.
Nur noch mal zur Klarstellung.
Bei dem System, bei dem das Upgrade funktioniert hatte, handelte es sich nicht um einen Klon, sondern um ein parallel geführtes Testsystem, auf dem ich immer die Updates und Patches getestet und dann bei Erfolg auf dem Echtsystem installiert hatte. Die Systeme sind also nicht gleich/identisch oder wie auch immer. Wenn ich nochmal die Zeit bekomme, würde ich via tail -f die Logfiles auf ein externes Medium schreiben.

Habe gerade die Datei
upload_rtDCvv.bz2 zu diesem Thema wie unter sdb.univention.de/1174 beschrieben
hochgeladen.
Vielleicht sieht man ja in den Dateien, was zum Scheitern führt.

Hallo,

In dem zugesandten Support-Info-Archiv kann ich kein laufendes Update erkennen. Ich bin mir nicht sicher, welchen Status das Support-Info-Archiv aktuell wiedergibt.
Wie bereits beschrieben ist es kaum möglich, profilaktisch Dinge _vor dem Update zu prüfen und es ist sehr wahrscheinlich, dass das Verhalten bzgl. Grub durch den forcierten Reboot hervorgerufen wurde.

Einen anderen Analyseweg als den oben zitierten sehe ich mometan leider nicht.

[quote=“saacke”]Danke für die Antwort.
Nur noch mal zur Klarstellung.
Bei dem System, bei dem das Upgrade funktioniert hatte, handelte es sich nicht um einen Klon, sondern um ein parallel geführtes Testsystem, auf dem ich immer die Updates und Patches getestet und dann bei Erfolg auf dem Echtsystem installiert hatte. Die Systeme sind also nicht gleich/identisch oder wie auch immer. Wenn ich nochmal die Zeit bekomme, würde ich via tail -f die Logfiles auf ein externes Medium schreiben.[/quote]

Hier bietet es sich natürlich an, entsprechende Tests auf einem 1:1 Klon durchzuführen, damit die Schritte und eventuelle Auswirkungen auch vergleichbar bleiben.

Mit freundlichen Grüßen,
Tim Petersen

Mastodon