Posts by spectre

    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.

    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.

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


    Code
    1. 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.

    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...!

    Code
    1. root@zeta:/home/pzillmann# sha1sum /boot/vmlinuz-4.9.0-5-amd64
    2. 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:


    Code
    1. gula [/boot]: sha1sum vmlinuz-4.9.0-5-amd64
    2. 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 : 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?

    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...

    Oliver : Danke, Bierchen ist gerade in der Gefriertruhe weil man natürlich genau in so einer Situation keines im Kühlschrank stehen hat ;-) dd-dump zu ziehen kann bei meiner Leitung dauern, ich glaube ich werfe das aber trotzdem mal an. Kann nicht schaden.


    Kraeutergarten : Der Kernel ist schon der richtige (keine zurückgehaltenen Pakete) aktuell -- ich hatte nur den Paketnamen verwendet (linux-image-4.9.0-5-amd64), die Kernelversion ist aber natürlich 4.9.65-3+deb9u2:


    Code
    1. gula [~]: dpkg -l|grep linux-image                                                                   
    2. ii  linux-image-4.14.0-2-amd64        4.14.7-1                       amd64        Linux 4.14 for 64-bit PCs
    3. ii  linux-image-4.9.0-3-amd64         4.9.30-2+deb9u5                amd64        Linux 4.9 for 64-bit PCs
    4. ii  linux-image-4.9.0-5-amd64         4.9.65-3+deb9u2                amd64        Linux 4.9 for 64-bit PCs
    5. ii  linux-image-amd64                 4.9+80+deb9u3                  amd64        Linux for 64-bit PCs (meta-package)

    Hallo Oliver,


    hatte deine Nachricht erst gerade gelesen. Puh, die Snapshots habe ich noch nie benutzt und ehrlichgesagt würde ich ungern auf meinem Produktivsystem damit herumexperimentieren und es auf Verdacht Plattmachen. Der Kernel ist schon der aktuellste, den JessieStretch zu bieten hat (4.9.0-5), den konnte ich via Rescue-System einspielen.


    Aber was ich morgen probieren könnte wäre mit einen eigenen Kern zu backen und dann mal zu schauen, ob das damit auch auftritt. Was mich wiegesagt so sehr wundert ist dass ich offenbar alleine mit dem Problem bin (d.h. ich glaube ehrlichgesagt nicht, dass das ein Debian-Problem ist, sonst wäre das ja überall). Also eher ein Problem mit meiner Instanz? Keine Ahnung.


    Ich habe auch mal den NetCup Support angefunkt und hoffe, von denen zu hören. Eventuell können die Licht ins Dunkel bringen. Ich bin jedenfalls für heute Abend nicht mehr arbeitsfähig, mache mir ein Feierabendbier auf und versuche drüber zu schlafen... puh...


    Viele Grüße,

    Johannes

    So. Mit dem Frankenkernel läuft er wieder grundsätzlich:


    Code
    1. gula joe [~]: uname -a
    2. Linux gula 4.9.0-1-grml-amd64 #1 SMP Debian 4.9.29-1+grml.1 (2017-05-24) x86_64 GNU/Linux


    Aber wiegesagt, Debian Stock Kernel -- keine Chance :-(


    Die hier gehen bei mir alle nicht:


    Code
    1. f4aca79acaf6c657832978f319c6c1e56b4003952ffdc1c528b9f2308bad0c3d  vmlinuz-4.9.0-3-amd64
    2. ceea0415b7a262d2ed73bddbd7d553615923c3ad0da4b3cce9db943b10fc7997  vmlinuz-4.9.0-5-amd64
    3. e459cc4236e514b89fa347570f476a52b35dafd040ba49fba3917c474b7b4447  vmlinuz-4.14.0-2-amd64


    Also falls jemand noch eine Idee hat, ich bin für alles offen (ziemlich verzweifelt...).


    Viele Grüße,

    Johannes

    Florian : Ich drücke die Daumen :-/


    @Krautergarten: Ja, wundert mich auch -- wenn Debian grundsätzlich betroffen wäre, müssten die Mailinglisten *voll* sein mit dem Issue. Sind sie aber nicht, ich finde nur hie und da Hinweise. Evtl bin ich aber auch auf einer anderen HW-Virtualisierung als du. Sowohl Ubuntu 16.04 konnte ich im Rescue-Modus booten als auch das grml-Rescue image. Mit dem grml-Kernel kann ich auch mein System booten. Ich baue mir da jetzt einen Frankenkernel aus grml-Kern und Debian-initramfs, um das Teils wenigstens grundsätzlich wieder ans Laufen zu kriegen.


    So ein Scheiß :-(

    Habe gerade nochmal reingebootet in das grml Rescue und mein Debian rootfs gemountet und rein-gechdired. InitramFS und Kernel passen definitiv zusammen:



    in grub.cfg (UUID von rootfs habe ich gesnipped)

    echo 'Loading Linux 4.9.0-5-amd64 ...' linux /boot/vmlinuz-4.9.0-5-amd64 root=UUID=XXXX ro quiet echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-4.9.0-5-amd64


    Vielen Dank schonmal für deine Hilfe,

    Viele Grüße,

    Johannes

    Passen sie, sowohl beim alten Kern als auch beim neuen. Habe gerade auch mal das -grml- Rescue-System gebootet (das geht auch) und mit den Kern und das Initramfs rüberkopiert. Das kann ich tatsächlich manuell via Grub booten, aber Debian Stock Kernel (AMD64) geht nicht. Die Panics sind immer mal unterschiedlich, z.B. hier ein zweiter angehängt.

    Hi,


    nachdem der Server heute durchgestartet wurde, kommt mein Debian Strech nicht mehr hoch, sondern verabschiedet sich direkt mit einer Kernel Panic. Im Stacktrace sehe ich system_call_fast_compare_end SyS_exit_group und dann do_group_exit do_exit. Screenshot anbei.


    Habe via Ubuntu Rescue reingebootet und den Kernel auf 4.9.30-2+deb9u5 upgedatet (der neuste im Tree). Problem besteht.


    Kann mir bitte jemand helfen?

    Vielen Dank,

    Johannes