Ox6ase bootet nicht nach UMC Onlineupdate

UCS - Univention Corporate Server
,
#1

Hallo zusammen,

wir haben heute per UMC ein Onlineupdate unseres ox6ase Systems gemacht. Hierbei wurden unter anderem auch 2 neue Kerlen installiert. Das Update lief Problemlos (keine Fehlermeldungen im update.log). Allerdings bootet das System nicht, wenn wir mit einen der beiden neuen Kernel starten wollen.

Der UCS Server ist auf Version 2.4-1. Das Update wurde heute durchgeführt.

Der Kernel, der bei der Erstinstallation dabei war und Problemlos bootet ist: “UCS, kernel 2.6.32-ucs11-amd64”

Die beiden neuen Kernel, welche nicht booten sind “UCS, kernel 2.6.32-ucs21-amd64” und “UCS, kernel 2.6.32-ucs35-amd64”.

Das ox6ase Sytem läuft als virtuelle Maschine auf einem Xen Virtualisierungscluster (Vers. 5.6 FP1) mit einem redundanten Open-E V6 Storage im Hintergund.

Es finden sich keine Hinweise zu Problemen mit den neuen Kerneln in den System Logs.

MfG,
moehlingEDV

#2

Hallo,

dieses Problem wurde bereits in folgendem Thread gemeldet, dort finden Sie auch einen Lösungsweg:

Mit freundlichen Grüßen
Janis Meybohm

#3

Guten Morgen Herr Meybohm,

danke für den Hinweis auf den anderen Thread.

Ich habe mit der Anleitung bzw. dem Lösungsweg des anderen Threads versucht unsere Konfiguration entsprechend anzupassen.

Allerdings ergeben sich schon beim Abfragen der nötigen UCR Variablen andere Ergebnisse als in dem von Ihnen beschrieben Fall.

# ucr get grub/root /dev/mapper/vg_ucs-rootfs

# ucr get grub/append root2fstype=ext3 splash=silent

Der letzte Parameter muss ja offensichtlich nicht angepasst werden, da er keinen Hinweis auf den Root Pfad enthält.
Bei dem anderen Parameter bin ich mir nicht sicher, in wie fern er angepasst werden muss, da der Pfad völlig anders ist, als der in Ihrem Beispiel.
Vielleicht können Sie hier noch helfen.

Beste Grüße,
moehlingEDV

#4

Hallo,

bei der Verwendung von LVM sollte eigentlich keine Anpassung notwendig sein da sich der Name des LVM VG/LV nicht ändert.

Welche Fehlermeldungen gibt es beim Booten genau?
Welche Devices sind in der Recovery-Shell verfügbar und kann das LVM manuell aktiviert werden (“vgchange -a -y”)?

Sollte der Bootvorgang bei einer “waiting for root filesystem…” Meldung “stehen bleiben”, kann die Wartezeut durch den Kernel-Parameter “rootdelay=5” verkürzt werden.

Mit freundlichen Grüßen
Janis Meybohm

#5

Guten Tag,

leider bin ich erst jetzt dazu gekommen, die Hinweise aus Ihrem Post zu probieren.

Zu etwaigen Fehlermeldungen kann ich nichts sagen, da weder in der Xen Center Konsole der VM noch in den System Logs der OX6ASE VM etwas zu dem Fehlerhaften Bootvorgang vermerkt ist.

Beim booten mit eingelegter OX6ASE Installer DVD und Auswahl der Konsole kommt bei Eingabe von “vgchange -a -y” nur die Meldung “unrecognized command”.

Trotz des gesetzten “rootdelay=5” Kernel-Parameters tut sich selbst bei gut 20 minütiger Wartezeit rein garnichts.

Grüße,
moehlingEDV

#6

Hallo,

das System müsste bei einem normalen Boot (wenn das Root-Dateisystem nicht gefunden wurde) in eine Recovery-Shell (initrd) zurückfallen.
In jedem Fall werden wärend des Bootvorgangs und vor allem vor dem Fallback in die Recovery-Shell einige Hinweise auf der Konsole ausgegeben. Ich würde Sie bitten diese zu Posten da ansonsten nur spekuliert werden kann wo hier das Problem liegt.

Mit freundlichen Grüßen
Janis Meybohm

#7

Hallo Herr Meybohm,

wir haben das OX6ASE System nun vom Xen Virtualisierungssystem auf echte Hardware umgezogen. Offensichtlich war das Problem mit dem Kernel durch die Xen Virtualisierung ausgelöst worden.

Allerdings hat sich in der vorherigen Konstellation keine Recovery-Shell geöffnet und es wurden auch keine Hinweise bezüglich Fehlermeldungen oder ähnlichem ausgegeben.
Wie bereits vorher geschrieben waren auch die Logs “sauber”.

Mit freundlichen Grüßen,

moehlingEDV

#8

Moin
ich kann mich nur dem Support anschließen da ich selber die ASE Version in einer Xen Umgebung mit Sles11 betreibe. Falls sie die Xen Umgabung noch haben, starten sie einen Kern, der bootet und editieren sie einfach einmal den Eintrag in Grub für den nicht startenden Kern in der Art:

“Es ist nicht mehr /dev/sda3, sondern wird zu /dev/xvda3”

Was mir bei dem aktuellen Kern noch aufgefallen ist, dies kann auch mit der erweiterten Paravirtualisierung zusammen hängen, das die Netzwerkkarte nicht mehr mit lspci zu sehen ist und ich sie daher neu anlegen mußte. Danach war der Server auch wieder erreichbar.

Grüße aus Berlin

Ben Sommer

Mastodon