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
[gelöst] Kernel panic not syncing bei stretch/sid, stable bp
-
segmentationfault
- Beiträge: 104
- Registriert: 13.02.2011 07:24:43
-
segmentationfault
- Beiträge: 104
- Registriert: 13.02.2011 07:24:43
Re: [gelöst] Kernel panic not syncing bei stretch/sid, stabl
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
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
- Beiträge: 104
- Registriert: 13.02.2011 07:24:43
Re: [gelöst] Kernel panic not syncing bei stretch/sid, stabl
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
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
Re: [gelöst] Kernel panic not syncing bei stretch/sid, stabl
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.segmentationfault hat geschrieben:Dann wäre interessant bei welcher Konstellation / ab welcher Konstellation der Fehler wieder auftritt.
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
- Beiträge: 104
- Registriert: 13.02.2011 07:24:43
Re: [gelöst] Kernel panic not syncing bei stretch/sid, stabl
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
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
Re: [gelöst] Kernel panic not syncing bei stretch/sid, stabl
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).segmentationfault hat geschrieben:Root, boot, var, usr, usr/lib, usr/local, opt, srv, tmp und home
/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.
Beware of programmers who carry screwdrivers.