[gelöst] Kernel panic not syncing bei stretch/sid, stable bp

[segmentationfault]

Hallo Cosmac,

dank Deiner Info habe ich mal auf die Changelog-Info für Systemd geschaut. Das Changelog von der Backports-Version 230-7 stammt vom 08.07.2016 und nach einigen weiteren Versionen folgt die aktuell in testing enthaltene Version 232-6 am 21.11.2016. Die Version 232-7 aus unstable stammt vom 30.11.2016.

Alle genannten Versionen zeigen auf meinem System reproduzierbar die Kernel-panic. Jedoch trat das Problem auf meinem Rechner erst vor nun etwas mehr als 3 Tagen auf.

Auf der einen Seite identifiziere ich klar systemd als Ursache, aber verstehe nicht warum das erst jetzt auftritt wenn doch die Backports-Version schon seit Juli existiert und ich ja vor kurzem stretch noch am Laufen hatte dessen Systemd sicher > 230-7 war.

Da muss es noch etwas geben was ich noch nicht berücksichtige. Ich werde mir die Changelogs aller anhängenden Pakete anschauen. Meine Vermutung ist, daß zwar das systemd-Paket schon neuer war als 230-7 und bei mir gelaufen hat, daß aber anhängende Pakete eine Version erreicht haben wo es dann in Kombination mit systemd bei mir knallt.

Gruß
segmentationfault

[cosmac]

Hast du berücksichtigt, dass es immer eine Zeit dauert, bis ein Paket nach einer Änderung in stretch auftaucht? Auf der Paketseite gibt es auch einen Link zum Packet Tracking System (PTS) mit einer Liste wann das Paket wo aufgetaucht ist.

[segmentationfault]

guter Hinweis - Danke.

Da habe ich nicht dran gedacht.

Gruß
segmentationfault

[segmentationfault]

Hallo,

eine mögliche Idee ist mir gerade gekommen.

Wenn ich mir die abhängigen Pakete bei den oben genannten systemd-Versionen anschaue, so ist nur bei der ältesten Variante bei Jessie (215-17+deb8u5) eine Abhängigkeit von udev (Version >= 208-8) gegeben. Nicht jedoch bei den neueren Versionen.

Ich probiere mal aus was passiert wenn ich eine alte Jessie-Installations-DVD nehme und udev in der dort alten Version belasse, d.h. nicht die neueste stable-Version vom Server lade und dann mit der veralteten udev-Version auf stretch aktualisiere.

Bei udev kann ich kein Changelog verfolgen. Wenn ich bei packages.debian.org unter udev das Debian-Changelog aufrufe dann wird mir das Changelog vom jeweiligen systemd angezeigt.

Ich probiere das mal aus, kann aber erst in ein paar Tagen was dazu berichten.

Ich habe mir auch überlegt ob ich eventuell mittels apt-pinning ein älteres udev / anderer Pakete nachträglich erreichen kann. Laut debian wiki zu apt-pinning sollte das durch entsprechende Prioritäten doch möglich sein.

Ich würde stretch über jessie installieren und dann die Version von udev prüfen und dann ggf. per apt-pinning ein älteres udev versuchen einzuspielen bevor ich den Rechner neu starten würde was sonst zur Kernel-panic führen würde.


Ich habe mir noch angesehen wann eine Version im Changelog auftaucht und wann es unter packages.qa.debian.org in der jeweiligen Distribution aufgenommen wurde.

Version 232-7 aus unstable hat das Changelog-Datum am 30.11.2016 und wurde am 01.12.2016 in unstable aufgenommen
Version 232-6 aus testing hat das Changelog-Datum am 21.11.2016 und wurde am 25.11.2016 in testing aufgenommen
Version 215-17+deb8u5 aus stable hat das Changelog-Datum am 08.07.2016 und wurde am 03.09.2016 in stable aufgenommen
Version 230-7 wurde am 08.07.2016 in unstable aufgenommen und am 14.07.2016 nach testing migriert. Die Backportversion ist allerdings die 230-7~bpo8+2

Teilweise liegt also das Datum zwischen Changelog und Aufnahme in der Distribution sehr nahe, teilweise mit größerem Abstand.
Aus den Changelogs versuche ich für die Version 215-17+deb8u5 noch herauszusuchen wann sich z.B. bei udev was getan hat.

Gruß
segmentationfault

[cosmac]

Wenn ich mir die abhängigen Pakete bei den o ben genannten systemd-Versionen anschaue, so ist nur bei der ältesten Variante bei Jessie (215-17+deb8u5) eine Abhängigkeit von udev (Version >= 208-8) gegeben. Nicht jedoch bei den neueren Versionen.

Das ist so seit 227-2, 11.11.2015. Begründung: udev wird sowieso immer automatisch installiert. Allerdings hat systemd immer nur mit wenigen, passenden udev-Versionen funktioniert.

Aber wenn du es so genau wissen willst, solltest du doch mal nach der vollständigen Fehlermeldung schauen. Wenn deine VM (nur) ein VGA-Terminal emuliert kann man evt. nach dem Crash das VM-Fenster zurück scrollen. Oder man mach es vorher sehr groß. Vielleicht kann man den virtuellen CPU-Takt der VM runter drehen bis man mit lesen kann. Man könnte eine network console einrichten (müsste als kernel parameter gehen) und über das Netzwerk der VM und "netcat -l -p 1234" die Meldungen in einem x-Terminal beobachten.

[segmentationfault]

Hallo zusammen,

um Systemd als Ursache entgültig einzugrenzen habe ich Testing (stretch) nun ohne systemd mit sysVinit eingerichtet mit tadellosem Verhalten ohne Kernel-panic.
Ich werde wie zuvor berichtet die Varianten mit systemd in der Virtualbox weiter unter die Lupe nehmen was funktioniert und welche Konstellationen abstürzen um noch präziser einzugrenzen welche Versionen nicht funktionieren.

Aktuell ist es ganz ok ohne systemd zu arbeiten. Die Unterstützung, die ich zuvor wegen der Grafik ohne stretch vermisst hatte habe ich nun wieder verfügbar.
Allerdings habe ich eigentlich nichts gegen systemd und möchte weiter verstehen was hier das Problem ist. Ich mache am Wochenende noch ein paar Versuche.

Gruß
segmentationfault

[segmentationfault]

Hallo,

heute Morgen habe ich mit Virtualbox geprüft welche Meldungen ich bei dem Fall erfassen kann, daß ausgehend vom einem neu installierten Jessie das Paket systemd aus den Backports eingerichtet wird und welche Fehlermeldungen danach beim Neustarten erfolgen.

Bei Virtualbox kann man ja einen Videomodus aktivieren. Dann wird alles was man beim Hochfahren des virtuellen Systems macht bis zum Abschalten aufgezeichnet und als webm-Film gespeichert.

Einmal ist mir aufgefallen, daß bei der Installation der aktuelleren Version von systemd aus den backports bei der Installation mittels dpkg Fehlermeldungen bei mindestens zwei abhängigen Paketen auftreten.
Das habe ich mal auf folgendem Bild festgehalten: http://debianforum.de/forum/gallery/ima ... age_id=469

Alternativer Link zu dem Bild: https://picload.org/image/raoglprp/dpkg ... allati.png

Hier ist eindeutig die Information enthalten, daß udev und ifupdown offenbar fehlerhaft konfiguriert werden und deren Installation beschädigt wird.

Wenn man nun nach der Installation der Backports-Variante von systemd neu startet kommt unmittelbar vor der Kernel-panic folgende unauffällige Bootmeldung:
http://debianforum.de/forum/gallery/ima ... age_id=470

Alternativer Link zu dem Bild: https://picload.org/image/raoglprc/dire ... _panic.png

Direkt danach kommt dann was ich schon als Bild gezeigt hatte: http://debianforum.de/forum/gallery/ima ... age_id=471

Alternativer Link zu dem Bild: https://picload.org/image/raoglpdd/kern ... jessie.png


Leider ist nicht mehr zu sehen. Ich habe den Film Bild für Bild abgespult und nur diese Infos herausholen können.

Noch genauer schaffe ich momentan leider nicht den exakten Fehler einzugrenzen. Nächster Schritt wäre zu schauen was genau bei udev und ifupdown schiefgelaufen ist.

Ich setze den Thread mal als gelöst fest. Grundsätzlich habe ich ja tatsächlich nur die Chance auf eine systemd-Version zu hoffen, bei der das Problem nicht mehr auftritt da selbst bei vollständigem Verständnis des Problems ich ja keine Chance hätte während einer Neuinstallation den Fehler zu vermeiden und eine korrigierte Version einzuspielen.

Ich lasse stretch erst mal auf sysVinit laufen und beobachte die Weiterentwicklung von systemd durch Antesten in der Virtualbox.

Es wird eine Weile dauern. Wenn es wieder funktioniert ergänze ich hier einen Beitrag mit der Version von systemd ab der es wieder funktioniert.

Gruß
segmentationfault

[KP97]

Hallo @segmentationfault
Da der Fehler mit der Galerie immer noch nicht behoben ist, haben wir angemeldeten User leider keinen Zugriff auf die von Dir eingestellten Bilder.
viewtopic.php?f=14&t=162846
Ich glaube auch nicht, daß sich jetzt jeder abmeldet, daher ist die Resonanz eher spärlich.
Wenn Du Lust hast, kannst Du ja nochmal einen Bilderhoster wählen mit vergrößerbaren png's für Foren.

[segmentationfault]

Hallo KP97,

ok, ich schaue mal was ich für einen Hoster finde und verlinke dann noch dahin sofern das für den Webmaster kein Problem ist.

Übrigens kann ich auf die Bildergallerie zugreifen und sowohl die von Anderen als auch von mir eingestellten Bilder zugreifen.

Gruß
segmentationfault

[KP97]

Vorab, leider habe ich keine wirkliche Idee dazu. Es ist schon so, daß mit den früheren Versionen von systemd doch einige Fehler aufgetreten sind.
Da ich Sid verwende, habe ich die alle mitbekommen. Evtl. liegt das wirklich an den Backportpaketen, möglich wäre es. Es sind ja alles Abhängigkeiten von systemd.

Also bei mir besteht der Fehler in der Galerie weiterhin. Ich habe jetzt mal etwas experimentiert und stelle die Screenshots in den richtigen Threed.
Evtl. hilft es ja bei der Fehlersuche.
Der Link steht im vorletzten Beitrag.

[segmentationfault]

Hallo KP97,

ich habe jetzt bei jedem Beitrag wo ich auf Bilder aus der Bildergallerie verlinkt habe darunter mit "Alternativer Link zu dem Bild" jeweils noch einen zweiten Uploadlink für das Bild hinzugefügt. Ich hoffe das ist auch für den Webmaster und die Moderatoren ok. Ansonsten lösche ich die Links wieder raus.

Das Problem mit dem systemd ergab sich ab der Backportversion und zieht sich über testing bis nach sid. Entweder haben die neueren systemd-Versionen ein Problem mit meiner Hardwarekonfiguration oder ich habe ein ungünstiges Zusammentreffen von voneinander abhängigen Packages. Zumindest scheinen udev und ifupdown nicht "mitzuziehen". Ich sehe beim dpkg nicht, daß die jeweilige neue Version von z.B. udev mitgezogen werden sondern die alte Version offenbar bleibt und dann beschädigt wird.

Daher lasse ich mein System erstmal auf sysVinit und warte neuere Versionen von Systemd ab bzw. versuche einen neuen Installer von Testing über den aktuellen "Alpha8" oder warte sogar bis stretch zu stable wird.

Gruß
segmentationfault

[KP97]

Das ist ja wirklich seltsam. Gerade udev wird doch aus den sourcen von systemd gebaut, da sollte man annehmen, daß auch die richtigen Versionen installiert werden.
Dann ist der Fehler aber plausibel, da systemd ja fehlerhaft ist und alles Weitere davon abhängt.
Du könntest zur Not probieren, die richtigen Versionen einzeln drüber zu installieren.
https://packages.debian.org/search?suit ... words=udev

[segmentationfault]

Hallo KP97,

ich muss meine Aussage zurückziehen, daß die Versionen von udev und ifupdown nicht nachgezogen werden! Ich habe nochmal mit einem Klon von Jessie in der Virtualbox das Updaten von Systemd aus den Backports laufen lassen und nach dem Update und vor einem Neustart mir die Meldungen von dpkg (dpkg.log) und während der Installation herausgezogen.

Danach sind udev und ifupdown doch in der gleichen Version aus den Backports mitgezogen.

Es kommt am Anfang eine Infomeldung offenbar von dem Paketbetreuer des Paketes ifupdown. Hier das Bild dazu: https://picload.org/image/raogcpra/meldung_ifupdown.png

Dann habe ich hier noch die Ausgabe aus der Konsole während der Installation mit dpkg: http://nopaste.debianforum.de/39622

Und hier noch das komplette dpkg.log der Virtualbox-Installation nach dem Update von systemd aus den Backports: http://nopaste.debianforum.de/39623

Es kann ja auch nicht an der Aktualisierung der Pakete liegen da ja auch ausgehend vom Testing-Installer der Fehler genauso passiert und da sind ja die älteren Paketversionen von udev und ifupdown auch nicht enthalten.

Gruß
segmentationfault

[KP97]

Die Logs sind alle sauber. Die Meldung mit ...durch systemd beschädigt.... ist nur ein Hinweis, da das eigentliche Paket systemd erst danach entpackt und installiert wird.
Tja, tut mir leid, ich sehe da keinen Fehler und muß passen....

[segmentationfault]

Hallo KP97,

danke für Deine Unterstützung.

Ich warte mal spätere Versionen von systemd ab bzw. wenn Stretch zu stable wird. Ansonsten bleibe ich bei sysVinit. Ich habe ein System mit dem ich arbeiten kann.

Und wenn es bei SysVinit mal ein ähnliches Problem geben sollte habe ich mit Jessie und dem systemd Version 215... mit den Backports bis eben auf systemd aus den Backport noch eine Rückfalloption als Kompromiss.

Gruß
segmentationfault

[segmentationfault]

Hallo,

eine Beobachtung möchte ich noch mitteilen weil dieses eventuell mit dem Problem doch zusammenhängt.

Bei Jessie konnte ich im BIOS bezüglich der Grafik zwischen den Einstellungen Hybrid und Diskret wählen und hatte immer ein lauffähiges System.
Entweder wurde so auf die NVIDIA-Karte mit der Einstellung diskret erzwungen oder es lief auch die Intel-GPU bei der Einstellung Hybrid.

Mit Debian Testing hatte ich - egal ob Testing auf dem Host oder einer virtuellen Installation lief - mit der BIOS-Einstellung Diskret Probleme und konnte erst nur im Recovery-Modus starten und mich als root anmelden und dann mittels "startx" eine GUI starten.

Der Kerne-panic Absturz ergab sich bei Testing auch mit der Einstellung Hybrid.

Was mit sysVinit nun auch mit Testing (stretch) funktioniert ist die Einstellung Diskret ohne Notwendigkeit mit einem Recovery-Modus starten zu müssen.

Vielleicht liegt hier doch das Grundproblem mit den neueren Systemd-Versionen. Vielleicht führt die Neuerung in den Systemd-Versionen ab der Backportversion dazu dass auch der Umgang mit so einem Grafikkartensystem wie ich es habe der Kernel irgendnwie ins Leere läuft (Nullpointer-Exception) und dann mit der Panic anhält.

Es kann ja kein generelles Problem sein denn sonst wäre der Aufschrei viel größer und in den meisten Fällen passiert der Fehler eben nicht. Der Fehler zieht sich ja über mehrere Versionen von den Backports bis nach sid bei mir.

Ich vermute daher eine Inkompatibilität in der Ansteuerung meiner Hardware über die Software systemd ohne dass ein Hardwaredefekt vorliegt.

Gruß
segmentationfault

[segmentationfault]

Guten Morgen zusammen,

jetzt habe ich endlich die Ursache für das hier behandelte Problem ermittelt. Ich lag vorher völlig falsch sowohl was das Thema Grafik betrifft als auch die Software systemd.
Jetzt kann ich den Thread als entgültig gelöst markieren!

Heute Morgen hatte ich versucht zu überprüfen ob das Problem auch bei meinem 15 Jahre alten Laptop (ASUS L3800C) auftritt auf dem ich seit Jahren Wheezy am Laufen habe.
Dazu habe ich das System auf Jessie aktualisiert und danach das Systemd aus den Backports eingespielt.

Der alte Rechner hat einen Pentium4M 1800 Mhz-Prozessor und benötigt daher die i386-Installation.

Jessie lief dann auch soweit erst mal sauber und hatte systemd in der auch bei meinem neueren Gerät funktionierenden Version 215-17 eingerichtet. Nach Update des systemd aus den Backports war dann die bekannte Version 230-7 enthalten. Im dpkg-Log hatte ich dort nicht die Meldungen zu udev und ifupdown gesehen.

Jedenfalls nach dem Update auf systemd aus den backports zeigte auch der 15 Jahre alte Laptop die Kernel-panic.

Hier das Bild von dem alten Rechner mit der Kernel-panic: https://picload.org/image/rallpcpo/dscf0244.jpg

Diese Tatsache hat mir dann klar gemacht, daß die Hybridgrafik auf meinem neuen Gerät nichts mit dem Problem zu tun hat. Ich habe nach Gemeinsamkeiten beider Rechner gesucht und konnte nur ein Detail identifizieren: Die Partitionierung der Platte auf der das Debian läuft.

Seit Jahren hatte ich mir angewohnt das System erstens immer mit dem ext4-Dateisystem zu nutzen und zweitens das System auf mehrere Partitionen zu verteilen.

Ich hatte für folgende Verzeichnisse eine eigene Partition: Root, boot, var, usr, usr/lib, usr/local, opt, srv, tmp und home.
Dabei war das Rootverzeichnis auf einer primären Partition und alle Anderen auf logischen Laufwerken.

Der Grund warum ich das seit Jahren so gemacht habe war die Idee das Thema Fragmentierung von Dateien im Dateisystem einzugrenzen.
Mittlerweile habe ich aber schon gelernt, daß das ext4 nur geringfügig fragmentiert und dann auch einem niedrigen Niveau verbleibt (so 0,1 bis 0,7 % laut Filesystemcheck).

Und das war nun das Problem. Die Aufteilung des Debian-Dateisystem auf mehrere Partitionen hat systemd nach Version 215-17 nicht gepasst. Während also sysVinit und Systemd bis Version 215-17 damit klargekommen waren das System so zu partitionieren haben die neueren systemd-Versionen zumindest ab 230-7 ein Problem damit.

Ich habe meinen neuen Rechner nun nur bezüglich des home-Verzeichnisses mit einer eigenen Partition versehen (die ich auch lange Zeit nicht mehr angefasst habe) und den Rest in die Rootpartition als primäre Partition gesteckt. Und siehe da auch das nun in Testing aktuelle systemd 232-7 funktioniert.

Als ich mit der Virtualbox-Installation versucht hatte den Fehler genauer zu identifizieren war die Kernelpanic ja auch während des Überprüfens der Dateisysteme aufgetreten. Ich konnte klar feststellen, daß die Panic genau dort stattfand und zwar genau nach dem zweiten Dateisystem. Daher habe ich nun auch maximal zwei Dateisysteme angelegt - root und home - um eben bei drei nicht schon wieder in das Problem zu kommen.

Jetzt kann ich dank wieder funktionierendem Systemd wieder völlig normal mit dem Rechner arbeiten. Bei sysvinit mußte ich auf policykit1 und auch die Einbindung von USB-Laufwerken verzichten.

Also sollte man schon aufpassen bei der Partitionierung wenn man das System neu aufsetzt und kann eben nicht jede Variante die das Installationsprogramm zuläßt auch dann nutzen.

Ich hätte mich wohl dumm und dämlich warten können auf der Hoffnung nach einem systemd das sich wieder so verhält wie Version 215-17.
Den Unterschied hätte ich schon gerne noch der Vollständigkeit halber verstanden. Das schaue ich mir dann doch nochmal an.


Gruß
segmentationfault

[segmentationfault]

Hallo zusammen,

folgende Partitionierung ist möglich mit systemd Version 232-7:

Root, boot, usr, var, home, d.h. Aufteilung auf 5 Partitionen.

andere Varianten bis zur ursprünglichen Partitionierung nähere ich mittels Virtueller Installation an (root, boot, var, usr, usr/lib, usr/local, opt, srv, tmp. home)

Dann wäre interessant bei welcher Konstellation / ab welcher Konstellation der Fehler wieder auftritt.

Gruß
segmentationfault

[KP97]

Dann wäre interessant bei welcher Konstellation / ab welcher Konstellation der Fehler wieder auftritt.

Wenn das nur eine akademische Frage ist, dann viel Spaß beim testen, ansonsten ist es aber völlig unnötig, die einzelnen Verzeichnisse auf getrennte Partitionen zu legen.
Das hat man ganz früher mal gemacht, aber bei den heutigen Plattengrößen ist das schon seit Jahren überholt. Einzig das Homeverzeichnis könnte man auslagern, wenn man bei einem Umzug schnell die Einstellungen wieder haben will. Aber auch das halte ich für keine gute Lösung, da ja durch z.B. unterschiedliche Versionen von Programmen eine 1:1 Übernahme auf Fehler laufen kann.
Ich habe meine Systeme immer nur ins Wurzelverzeichnis installiert und hatte nie Probleme und weniger Aufwand bei der Installation.

[segmentationfault]

Hallo KP97,

klar ist Deine Lösung völlig in Ordnung.

Jetzt interessiert es mich aber doch ob ich reproduzierbar den Fehler erreiche wenn ich die frühere Partitionierung auf 10 Partitionen einstelle und ob dann systemd > Version 230-7 damit nicht klar kommt und vorher schon.

Das ist in der Tat dann nur noch eine akademische Frage. Aber wo ich das Problem jetzt schon so eingrenzen könnte möchte ich es dann doch genau wissen.
Wenn ich einen Zusammenhang gefunden habe (Tests mit Virtualbox) dann schreibe ich das noch zum Abschluss hier hin.

Gruß
segmentationfault

[cosmac]

Root, boot, var, usr, usr/lib, usr/local, opt, srv, tmp und home

Wahrscheinlich liegt es an der eigenen Partition für /usr/lib. /usr wird schon in der initrd gemountet, /usr/lib eher nicht. Die systemd-Entwickler wollten schon lange keine getrennte /usr-Partition mehr unterstützen, garnicht zu reden von /usr/lib. Aber momentan sollte eine eigene /usr noch unterstützt werden (mit initrd).

/boot, /var, /srv, /tmp und /home dürfen auf jeden Fall auf eigenen Partitionen liegen. Bei /boot ist es teilweise sogar zwingend wenn der Bootloader das Dateisystem von / nicht kennt. /tmp kann heutzutage oft ein /tmpfs sein, also praktisch auch eine eigene "Partition". /var (oder mindestens /var/log u.ä.) muss eine eigene sein, wenn / read-only gemountet werden soll.

Um das von KP97 genannte Problem mit unterschiedlichen config-Files in /home zu vermeiden, lege ich in /home keine eigenen Dateien an. Die packe ich (sinngemäß) nach /srv/pdf, /srv/rechnungen, ... und /srv bekommt eine Partition. Auf einem Server erst recht, weil die Daten dort wirklich unabhängig von Distri/Release/etc sein sollten.

Außerdem versuche ich, nur primäre Partitionen zu verwenden, weil man dann eine verloren gegangene Partionstabelle leichter wieder herstellen kann. Ein swapfile sollte genauso gut wie eine swap-Partition sein, wenn man es möglichst kurz nach der Installation in fester Größe anlegt (mit dd). Dann ist es nicht fragmentiert und muss im Betrieb nicht vergrößert werden.

Ein verwandtes Thema: stretch legt per Default in /bin, /sbin und /lib nur noch symlinks auf /usr/xxx an:
https://www.debian.org/devel/debian-ins ... 6/20161112
https://lwn.net/Articles/670071/

Unabhängig vom eigentlichen Auslöser des Problems ist es ein systemd-Bug, hier fehlen Fehler-Abfrage und -Meldung.