VServer bootet nach Specte/Meltdown Patch nicht mehr: Kenel Panic

Florian: Ich hab's so gemacht: Erst Rescue System gebootet (grml). Also Bootreihenfolge auf Netzwerk, und Rescue-Image aktivieren. Dann per PXE ins Resuce Image booten. Megapraktisch, macht einen ssh auf, kannste dich direkt einloggen. Dann rootfs mounten:

# mkdir x

# mount /dev/vda1 x

dev, proc und sys bindmounten:

# mount --bind /dev x/dev

# mount --bind /sys x/sys

# mount --bind /proc x/proc

Dann die Kernel kopieren

# cp /boot/vmlinuz-4.9.0-1-grml-amd64 /boot/initrd.img-4.9.0-1-grml-amd64 x/boot

Und die Module auch

# cp -a /lib/modules/4.9.0-1-grml-amd64 x/lib/modules

Dann chroot machen. Shell angeben, wenn bei dir auch keine zsh installiert ist (ich nutze Bash):

# chroot x /bin/bash

Jetzt biste in deinem System. Da machste dann noch

# update-grub

Und der sollte den grml-Kernel erkennen und der grub.cfg hinzufügen. Dann raus

# Ctrl-D

# umount x/dev

# umount x/proc

# umount x/sys

# umount x

# sync

Dann neubooten und in Grub die grml-Kernel auswählen. Funktioniert bei mir...

Kraeutergarten: Hmmm, wie lang müsste ich warten? Ich habe ein Dutzendmal Poweroff gemacht (weil wenn er mit der Kernel Panic hängt, geht Ctrl-Alt-Del nicht mehr, deswegen aus, teilweise Bootreihenfolge geändert, wieder an) -- aber wenn man da länger warten müsste hat das eventuell nicht gereicht? Maximal habe ich das System 1 Minute am Stück ausgehabt. Hat das Einfluss darauf, an welche Hardware auf meine virtuelle Hardware gebunden wird?

Quote from H6G

Code

root@zeta:/home/pzillmann# sha1sum /boot/vmlinuz-4.9.0-5-amd64 
65911c2e164b577ae0822936a60c0816e2434bae  /boot/vmlinuz-4.9.0-5-amd64

Nur mal so als Idee.

Ansonsten würde ich wirklich auf die Hardware tippen. Scheint aber bei einigen Probleme zu geben. Der Kernel läuft ber bei mir momentan auf 4/7 Maschinen ohne Probleme.

Jupp, ist bei mir exakt derselbe:

gula [/boot]: sha1sum vmlinuz-4.9.0-5-amd64 
65911c2e164b577ae0822936a60c0816e2434bae  vmlinuz-4.9.0-5-amd64

Oben hatte ich nur die SHA256SUM gepostet und vergessen dazuzuschreiben, welcher Hash es ist.

EDIT: Das wichtigste habe ich natürlich vergessen zu fragen... was ist mit den 3/7 restlichen Maschinen?

Viele Grüße,

Johannes

Kraeutergarten: Ich hatte auf deinen Beitrag schon geantwortet, https://forum.netcup.de/admini…hr-kenel-panic/#post89097

H6G: Ja, habe das Initramfs in dem Rescue-System neu generiert. Also alle sogar, weil ich zu faul war die genaue Version rauszusuchen. Glaube aber, dass zu dem Zeitpunkt, wo er stirbt (keine 2 Sekunden nach dem Start) das Initramfs noch gar nicht in Benutzung ist (liegt zwar im Speicher, aber ist noch zu früh, glaube ich).

Drücke dir jedenfalls für deine drei anderen Kisten auch die Daumen...!

Aha und gerade habe ich auch eine Antwort auf meine Supportanfrage erhalten, die schon eher dreist ist:

An Ihrem System, also Ihrer Installation, wurde durch das dringend nötige und sicher auch in Ihrem Sinne durchgeführte Update nichts verändert. Sie besitzen bei uns einen virtuellen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.

Neee, ist klar. Die Kernel, die vorher einwandfrei gebootet hat und nach dem Patch des Hosts direkt sofort eine Panic auslöst hat ÜBERHAUPT nichts mit dem Patch zu tun. Hier gibt es nichts zu sehen, lösen Sie ihr Problem selbst!

Veräppeln kann ich mich selber. Dass da ein direkter Zusammenhang besteht zwischen dem Host-Patch und meinem nicht mehr bootendem Guest ist offensichtlich. Den Zusammenhang zu leugnen ist völlig lächerlich.

mlohr: Klaro, ist ja eine berechtigte Frage. Die Logs sagen 14.9.2017 16:30Z. Die dpkg-Logs sagen außerdem dass ich am 4.7.2017 auf linux-image-4.9.0-3-amd64:amd64 upgedatet habe. Das heißt, ich habe garantiert schonmal erfolgreich den 4.9.30-2+deb9u2 gebootet -- und der geht jetzt einfach nicht mehr.

Heute habe ich es noch nicht probiert, ich frickel auch mal mit der Kernel Commandline rum, um den Fehler besser einzugrenzen. Außerdem wären natürlich auch die Zeilen vor dem Oooops interessant, evtl kann ich ihn mit einem vga=xyz Befehl dazu bewegen, mehr Zeilen anzuzeigen, damit man sieht, was da tatsächlich das Problem verursacht.

Aber vielen Dank auf jeden Fall für die Hilfe, ich bin ja auch daran interessiert, die Root Cause zu finden (obwohl ich natürlich schon arg vermute, dass es was mit dem Host-Patch zu tun hat).

Kraeutergarten: Ich weiß gar nicht, wie ich die Anzahl CPUs verändern kann, glaube ehrlichgesagt in meinem Tarif geht das gar nicht, kann das sein? Habe jedenfalls in der Management-Console nichts derartiges gefunden.

Hi nochmal an alle! Vielen Dank für eure zahlreichen Ratschläge. Ich habe das Problem gefixed. Vorab: Es lag nicht an NetCup und auch nicht an dem gepatchten Host, das war nur ein unglücklicher zeitlicher Zufall. Der Support hatte also Recht, dass es mein Problem ist.

Zunächst habe ich mal die Startnachrichten verlangsamt (Kernel commandline boot_delay=xyz) um zu sehen, wie weit er kommt. Zu meiner Überraschung war das initramfs zu dem Zeitpunkt, an dem er stirbt (so etwa nach 2.5 Sekunden) gerade am hochfahren. Also kam das, wie ja H6G vermutet hatte, doch als Fehlerursache in Betracht. Ich war ja ohnehin skeptisch, dass es am Debian Kern liegt (weil den *so* viele Leute nutzen und es sonst ja dutzende Bugreports geben müsste), aber das initramfs wird ja von den initramfs-tools selbst gebaut.

Dann habe ich mir mal eines unter die Lupe genommen. Also binwalk, dann das offset für die Payload bestimmt, dann dd, gunzip und cpio. Dabei habe ich dann festgestellt, dass in /lib die klibc fehlt. Also nachgesehen, das Paket war installiert -- aber auf meinem Host hat die Datei /lib/klibc-k3La8MUnuzHQ0_kG8hokcGAC0PA.so gefehlt! Also apt-get install --reinstall klibc, und sie war wieder da. Dann update-initramfs -u und alles ging wieder.

Warum die Datei plötzlich "weg" war, lässt sich jetzt nicht mehr sagen. Meine Vermutung ist aber, dass, nachdem die Datei gefehlt hatte, irgendwann die intiram-Skripte von einem Systemupdate (nicht notwendigerweise einem Kernelupdate) neugebaut wurden (das kann z.B. auch durch unattended-upgrades passieren, die ich als nightly cronjob habe). Damit war die Falle gestellt und hat nur auf einen Reboot gewartet. NetCup bootet dann meine Instanz durch und PLOPP, mein System startet nicht mehr.

Nochmal vielen Dank an alle, die mitgeholfen haben. Das Brainstorming hat mich dann letztlich zur Korrekten Lösung geführt.

Jupp, schon, security und so Eigentlich sollten da ja nur security-relevante Patches reinkommen. Aber ich glaub das wäre mir auch bei manuellen Updates nicht aufgefallen, bei jedem neu gebauten initrd boote ich ja normalerweise nicht neu. Sollte ich vielleicht überdenken, die Praxis.