UCS Server startet nach Update auf Version 5 nicht mehr

UCS - Univention Corporate Server
#11

Hallo,

Danke. Habe mir das nun einmal angesehen.
Allerdings weiß ich nicht genau, wie ich das “disabling page table isolation” einstellen/durchführen kann.

Ich habe in diesem Zusammenhang die Grub Parameter spectre_v2=off nopti pti=off bzw. spectre_v2=off pti=off kpti=off gefunden. Kann das ev. die Lösung sein bzw. kann ich die bei UCS in den Bootoptionen überhaupt setzen?

Weiters habe ich leider erfolglos die Bootoptionen noacpi, noapic und nosmp ausprobiert.

Ich habe auch im BIOS des Proliant Servers alle CPU-Parameter auf Disbabled gestellt (no virtualization, no hyperthreading, no VT-d, usw.) - auch kein Erfolg.
image

Es bleibt misteriös, wieso das System seit dem Upgrade auf UCS 5.0 unter keinen Umständen mehr hochfahren will.

Liebe Grüße,
Michael

#12

Ab und an passieren ja in der EDV Dinge zur gleichen Zeit, die nichts miteinander zu tun haben :slight_smile:
Hast du mal einen Memtest86 laufen lassen, nicht dass du einen defekten Speicher hast.

Gruß Ben

#13

Moin,

memtest ist immer eine gute Idee, um erstmal Grundlegendes auszuschließen.

Nach dem Update lief der Server noch mit dem alten Kernel. Nach dem Neustart mit dem neuen aus UCS5. Hast du schon alle Kernel durchprobiert, die auf dem System noch installiert sind? Welche sind das?

Leider kann man in deinem Screenshot mit dem Traceback den Anfang nicht sehen. Kann man da mit Shift-PageUp noch nach oben scrollen, wenn der Traceback auftritt? Der Kernel steigt da ja absichtlich aus und gibt am Anfang kurz an, warum er das tut (ist jetzt leider oben aus dem Screen rausgescrollt).

Viele Grüße,

Sönke

#14

Moin
weitere Idee um das Problem einzugrenzen

  • ein neues System UCS 5 auf einer leeren HD installieren, um zu sehen ob es sich um ein Softwareproblem UCS5 - Proliant handelt und es einwandfrei arbeitet
  • ist das Bios aktuell, hatte mal ein Problem mit meinem kleinen ProLiant Micro Gen8
  • Festplatten, die verbaut sind, mit smartctl testen oder auf dem Kontroller nachsehen

Grüße aus Berlin

Ben

#15

Moin,

wir haben hier eben nochmal zusammen überlegt:
Da der alte UCS 4.4 Kernel und der neue UCS 5.0 Kernel aktuell nicht mehr booten, müsste es etwas anderes sein. Da kommt neben einem CPU-Defekt fast nur noch ein mit UCS5 ausgeliefertes Microcode-Update in Frage. Kannst du mal im Grub, an der Stelle wo du die Kernelparameter schon ausgetauscht hast (loglevel=7) den Parameter dis_ucode_ldr am Ende der Zeile anfügen. Damit sollte das Laden der Microcode-Updates unterbunden werden.

Viele Grüße,

Sönke

#16

Hallo,

Danke für die tollen Tipps. Ich werde diese heute alle ausprobieren und dann zurück melden. Nochmals vielen Dank.

lg Michael

#17

Hallo,

Ich habe nun heute alles ausprobiert. Mit den folgenden ergebnissen:

  1. Memtest86+: der memtest aus dem Boot-Eintrag des Systems mittels Grub (siehe 2. Screenshot in dem Case) stoppt jedesmal bei 9% und macht dann nichts mehr.
    image
    Ich habe dann zwei bootfähige USB-Sticks mit Memtest86+ erstellt - allerdings bootet der Server damit nicht.

  2. Den Screen nach der Fehlermeldung kann ich mit keinem Tastendruck dazu bewegen nach oben zu scrollen, damit man die gesamte Historie des Bootvorgangs sehen kann. Auch nicht wie erwähnt mit einem Shift-Pageup .

  3. Mit dem Parameter dis_ucode_ldr am Ende der Zeile des Grub-Eintrages verhält sich das System genauso wie ohne den Eintrag - leider kein Unterschied. Von dem Hint hatte ich mir ehrlicherweise am meisten erwartet.

  4. Das BIOS des Servers ist aktuell - es gibt von HP kein Neueres.

  5. CPU-Defekt: im BIOS des Servers können RAM und CPU getestet werden - das brachte keinen Fehler.

  6. Eine Neuinstallation auf einem 32GB USB-Stick war erfolgreich - UCS5 hat sich installieren und fertig konfigurieren lassen.
    image

Allerdings natürlich ohne den RAID-Kontroller. Ich hätte zwar noch eine Platte und die RAID-Konfiguration wird ja angeblich auch auf den Festplatten gespeichert und sollte sich nach einem vollständigen Rückbau mit allen Platten wieder herstellen lassen, aber das habe ich mich dann doch nicht getraut.

Nun, leider nur ein kleiner Teilerfolg mit der erfolgreichen Installation von UCS5 auf einem USB-Stick.

Abschließend eine Frage: kann ich auf dem bestehenden System, welches nicht mehr hoch startet, das UCS5 drüber installieren ohne in der Installationsroutine die Partition neu auf die Harddisk zu schreiben? Dann würde ich mir ev. die komplette Neukonfiguration des Systems ersparen und hätte auch wieder Zugriff auf meine Daten.

Danke und lg Michael

#18

Hallo Michael

  • hast du einmal memtest https://www.memtest86.com/ genutzt und nicht memtest+, sind zwei unterschiedliche Tests.
  • Ich würde die Festplatten vom Raid noch einzeln testen.
    Jeweils einzeln an einem Sata Anschluß und mit den Smarttools. Systeme findest du hier
    https://www.smartmontools.org/wiki/LiveCDs
  • Wird denn das Raid angezeigt, wenn du von deinem Stick UCS 5 gebootet hast? Wenn ja, hast du auch schon einmal einen fsck über die einzelnen Partitionen laufen lassen?
  • Kannst du probeweise die Caches am Raid Adapter ausstellen und dann booten?
    Hoffe etwas bringt dich weiter :slight_smile:

Grüße aus Berlin und ein schönes Wochenende

Ben

#19

Hello Ben, Sönke und alle Anderen,

memtest86: ist nun gelaufen und hat keine Fehler im RAM erkannt.
image
Außerdem habe ich nun im BIOS des HP Proliant Servers das sog. Online-Speicher gesetzt. Dabei werden von den 60GB Gesamtspeicher 20GB reserviert und im Falle eines Fehlers zugeteilt. Damit kann es meiner Meinung nach im OS zu keinem Speicherfehler mehr kommen.

Die Festplatten einzeln testen tue ich mir nun nicht an. Das kostet mich zuviel Zeit.

Und ja, die Festplatte im RAID kann ich unter dem USC5 vom Stick gebootet sehen.
Und ja, auch ein fsck habe ich über die Partitions /dev/sda1 (Grub und /boot) und /(dev/vg_ucs/root als /) laufen - auch da war alles ok.

Den Cache am RAID-Kontroller kann ich nicht deaktivieren.

Ich tippe nun auf einen korrupten RAID-Kontroller Treiber in der UCS Installation auf den RAID-Platten - meiner Meinung nach kommt nicht mehr viel sonst in Frage.

Ich brauche nun schön langsam wieder meine Daten und habe mich entschlossen, das System enu aufzusetzen.
Dazu habe ich folgende Fragen:

  1. Kann ich das System, wenn ich die vorhandenen Partitions nicht lösche, über die bestehende Installation auf /dev/vg_ucs/root drüberinstallieren? Wird das funktionieren? Oder soll ich lieber eine komplett neue Installation machen?
  2. Würde UCS5 beim Drüberinstallieren meine vorherige Installation erkennen und die Programme (Letsencrypt, Nextcloud, usw.) und Settings übernehmen? Aber auch wenn nicht, dann müsste ich das halt alles nachher neu einrichten. Der enstscheidende Vorteile wäre, dass ich direkt wieder auf die Daten zugreifen kann.

Wenn eure Empfehlung eine saubere Neuinstallation ist (also mit einem Löschen der bestehenden Partitions) müsste ich halt mein Backup, dass ich ohnehin habe, wieder einspielen. Das wäre nicht so schlimm - das ganze würde zwar sehr viel Zeit in Anspruch nehmen, aber in die Rettung der vorhandenen Installation habe ich schon 3x mehr Aufwand investiert.

Vielen Dank im Voraus für eure Empfehlung und Einschätzung,
Michael

#20

Moin
ich würde vom Stick booten und mir ansehen welcher Kernel und welche Module für die Karte geladen sind.
Dann würde ich das / system von der Raidkarte mounten, eine chroot Umgebung damit schaffen und ggf. /boot mit einhängen. Dann vergleichen, ob es sich umden gleichen Kernel handelt und diesen ggf. inkl der benötigten Module tauschen. Eventuell mußt du auch die initrd neu bauen.

Gruß Ben

#21

Moin,

bei dem Abgleich würde ich auch gucken, ob das gleiche microcode-Debian-Paket eingespielt ist. Bei Bau der initrd wird das automatisch davorgeklebt. D.h. wenn du die initrds neu baust, wird das in der initrd mit aktualisiert. Ich würde außerdem eine Kopie der initrd-Dateien machen, bevor ich diese neu erstelle.

Viele Grüße,

Sönke

#22

Hallo Ben und Sönke,
Danke für den Tipp. Das kann ich noch ausprobieren. Allerdings reichen fürchte ich meine UNIX-Kenntnisse nicht aus.
Wie kann ich

  • schauen, welche Module für die Karte geladen sind
  • chroot verstehe ich - wie kann ich /boot mit einhängen?
  • benötigte Module tauschen
  • wie kann ich die initrd bzw. initrds neu bauen
    Kurze Tipps würden mir schon reichen. Ich denke die Einzelheiten kann ich mir im Internet zusammensuchen.

Vielen lieben Dank,
Michael

#23

Moin

  1. du schaust in /boot auf beiden Systemen nach den Inhalten, zu sehen sind ua vmlinuz-* initrd.* und siehst anhand der folgenden Zahlen, welche Versionen installiert sind. Bei mir zB vmlinuz-4.9.0-8-amd64
  2. wenn du zB dein / vom Raid unter /mnt/rescue hast, dann dein chroot auf /mnt/rescue gemacht hast, sollte boot leer sein. Dann mußt du natürlich wissen unter welchem Device deine Bootpartition auf dem Raid liegt. ein vi /etc/fstab in der chroot Umgebung sollte dir die Lösung zeigen. Dann kannst du sie einfach einhängen.
  3. auf dem Stick System und dem Raid System jeweils unter /lib/modules/KernelNummer/ Module vergleichen
  4. https://wiki.ubuntuusers.de/Kernel/Kompilierung/
    in /etc/initramfs-tools findest du die Einstellungen für die initrd. In modules siehst du, welche module erstellt werden. Dort kann man auch fehlende eintragen und mit einem Update der initrd diese beim Booten lagen
    Ich hoffe das hilft dir etws weiter

Gruß Ben

#24

Hallo Ben und Sönke,
Das ganze mit Modulen und Kernel war mir dann doch zu kompliziert. Ich habe mich entschlossen, den Server neu aufzusetzen. Zuvor habe ich noch eines probiert: ich habe die Datei initrd.img-4.19.0-16-amd64 vom USB-Stick auf /boot des Systems (RAID-Platte) kopiert und siehe da - der Server bootete wieder einwandfrei. Die Freude war sehr, sehr groß.

Ich habe danach dann das Update noch einmal auf UCS5 ausgeführt und nach einigen Scripts und der Deinstallation des univention-dhcp Servers lief das Update erfolgreich durch. Ich habe nun auch bereits die aktuellen Paket-Aktualisierungen installiert. Das Systeme scheint einwandfrei zu laufen - ich konnte noch nichts finden, was nicht funktioniert hätte.

Eines traue ich mich allerdings nicht: den Server rebooten. Kann ich da Vorkehrungen bzw. Checks machen, die mich vor einem nicht wieder startenden System schützen?

Vielen, vielen Dank für Eure tatkräftige Unterstützung.

lg Michael

#25

Hallo Michael

Erst einmal ist es gut, dass der Server läuft und ich wüßte nicht, wie man es vorher prüfen könnte
aber merke dir, die wahre stärke des Administrators siehst du erst, wenn er ohne Furcht den reboot auslöst :slight_smile:
Ich habe nach so einem Vorfall meinen Server Virtualisiert, um so vor den Updates immer ein aktuellen Snapshot zu haben und ggf zurück zu gehen. Ich weiß nicht wie groß deine Installation ist aber ich hatte es an einem Wochenende hinter mir. Durchgeführt auf einem HP Micro ProLiant Gen8 mit Proxmox
Vorbereitung war ein aktuelles Backup, eine Festplatte, auf die ich mein System mit dd kopiert hatte, dann der große Schritt die alte Installation zu löschen, Proxmox VE drauf, eine VM mit den Werten für Ram CPU usw erstellt, um danach die RAW gespeicherte Installation zu importieren und in das qcow2 zu wandeln. Virtuelle Platte nach Handbuch in der vorbereiteten VM getauscht, gestartet, gefreut.

Nur so als Idee, falls es umzusetzen ist.

Gruß aus Berlin
Ben

#26

Hallo Ben
Und ich bin erst froh darüber.
Die wahre Stärke des Administrators habe ich schon vor rund zwei Wochen auf die Probe gestellt, als ich wahrlich furchtlos den Neustart nach dem Update eingeleitet habe. Jetzt ist es genug.
Und du kannst mir glauben ich habe in meiner IT-Administrator-Berufslaufbahn, die beruflich schon ein paar Jahre her ist, schon viel erlebt. Ich hatte etliche Kundensysteme in der Verantwortung, wo ich von mehreren defekten Platten im RAID5 (Backup musste her), über 40MB Platten die hin und wieder einen leichten Schubser brauchten bis hin zu Windows Servern mit einem Software-RAID sicher sehr viel erlebt habe, wo es mir manchmal ein wenig kalt über den Rücken hinunter lief.

Aber nun zu deinem Vorschlag: so eine Konstellation hatte ich schon einmal vor Jahren laufen, und zwar auf einem VMWare ESXi Server. Mit dem gleichen Gedankengang wie deinem: vor einem Update einfach einen Snapshot ziehen und entspannt herumwerkeln. Damals hatte ich aber irgendein Problem, ich kann mich nicht mehr genau erinnern, wo das UCS ein Problem mit dem VMWare Hypervisor hatte. Daraufhin habe ich UCS wieder direkt auf der Platte installiert.

Ich habe aber darüber nachgedacht, ob ich nicht die Datenpartiton aus der /dev/vg_ucs/root in ein eigenes logicval Volume lege. Dann habe ich bei einem Problem und einer Neuinstallation zwar die Arbeit der Neukonfiguration, aber meine Daten bleiben erhalten, auch wenn ich die /boot und / Partition neu erstellen müsste. Dabei habe ich nur ein Problem: wie kann ich die Daten der Nextcloud auch in diese Partition legen? Ich habe noch keinen Weg gefunden den Ablageort der Dateien der Nextcloud woanders abzuspeichern.

Grüße aus Wien
Michael

#27

Moin Michael
da du bestimmt die Nextcloud von UCS nimmst, läuft sie ja im Docker. Ich habe auf meinem Fileserver eine Freigabe für die Cloud erstellt und diese per external storage eingebunden. Somit ist diese Freigabe unter Kontrolle der Cloud und ich habe die Daten im normalen backup mit drin und kann lokal auch über das Filessystem etwas einspielen. Vielleicht ist das eine Idee für dich.

https://docs.nextcloud.com/server/17/admin_manual/configuration_files/external_storage/smb.html

Das was du mit den Systemen erlebt hast, kann ich bestätigen. Ich mache das auch über 20 Jahre und habe viele Daten gerettet, da Kunden beratungsresistent waren und am Backup sparten. Man wächst mit der Aufgabe :slight_smile:

Das mit dem Trennen der Datenbereiche finde ich eine gute Idee. Viel Glück dabei und wenn du wieder einmal Hilfe benötigst, weißt du ja wo du sie bekommest :slight_smile:

Grüße aus Berlin

Ben

UCS 4 not booting with kernel 4.19.0-21
#28

Nextcloud Dateien kannst du über einen mount point unter /var/lib/univention-appcenter/apps/nextcloud/data auf eine andere Platte legen.

z.B.
/dev/vdb1 on /var/lib/univention-appcenter/apps/nextcloud/data type ext4 (rw,relatime,data=ordered)

in fstab:
UUID=bfcdd03d-5404-46b0-b1b5-560fb14f5bb8 /var/lib/univention-appcenter/apps/nextcloud/data ext4 defaults,user_xattr 0 2

vorher nextcloud stoppen das data verziechnis in einen temp ordner schieben und danach wieder zurück

lg

Christian

p.s. ich würde auch PROXMOX zur Virtualisierung empfehlen - vor allem mit dem neuen PBS (Proxmox Backup Server) der die VM’s inkrementell (also nur geänderte Blöcke) und mit Dedup sichert

#29

Hallo Ben und Christian,

Ja, ich verwende die Nextcloud von UCS. Die Variante von Christian gefällt mir gut.
Weißt du ob das auch mit einem Symbollink geht?

Die Daten auslagern werde ich wohl machen. Und die Virtaulisierung mit PROXMOX werde ich einmal ausprobieren - klingt sehr gut.

Vielen Dank nochmals,
Michael

#30

Hi,

ich hatte anscheinend das gleiche Problem. Mit UCS 5.0-3 errata 609 hat sich das Problem glücklicherweise wieder erledigt:

Viele Grüße,
Stefan

Mastodon