Hallo Peter, hallo Leute, Am Freitag, 4. Mai 2012 schrieb Peter Huyoff:
Genau diese Meldungen stehen auf der Konsole #8, bevor man die YAST-Meldung mit "OK" bestätigt. Das System läuft in diesem Zustand stundenlang stabil weiter! Auch dmesg liefert genau diese Meldungen.
Was genau verstehst Du unter "läuft stabil weiter"? Hast Du tatsächlich auf dem System gearbeitet (was?) oder war der Rechner "nur" angeschaltet und hatte Langeweile?
Ich habe denn die Yast-Meldung bestätigt und sofort wieder auf Konsole #2 geschaltet und wieder dmesg gestartet.
es kamen noch 4 oder 5 erfolgreiche acpid-Meldungen, sofort danach. Das System lief noch ca 30s, dann blockierte es wieder. In der Zeit hatte ich noch ein paar Mal dmesg gestartet, aber weitere Meldungen kamen nicht mehr. In /var/log/messages haben es die acpi-Meldungen nicht mehr geschafft.
Mounte mal alle Partitionen zusätzlich mit der Option "sync" - mit etwas Glück landet dann etwas mehr auf der Festplatte. (Ansonsten hilft auch ein Bildschirmfoto mit der Digitalkamera, um die letzten Meldungen aus dmesg festzuhalten.) Statt dmesg kannst Du auch mal nachsehen, ob auf Konsole 10 (oder gibt es bei der zweiten Stufe der Installation die Fehlermeldungen auf einer anderen Konsole?) irgendwas auffälliges auftaucht.
Vermutlich haben alle Kernel ab einer bestimmten Version ein Problem mit meiner Maschine (Chipsatz Intel i840), denn auch die Debian-Installation fror ja ein!
Ein Kernel-Problem ist eine wahrscheinliche Erklärung. Immerhin hast Du einen Vorteil: Du kannst das Problem mit YaST reproduzieren. Warum das ein Vorteil ist? Das Verhalten von YaST ist vorhersagbar - wenn ein Entwickler das Ende des YaST-Logs sieht, kann er anhand des Codes nachvollziehen, was als nächstes gemacht wird und es dann nicht mehr ins Log geschafft hat. Boote bitte mal mit der Bootoption [1] manual=1 Mit etwas Glück [2] führt das dazu, dass YaST sich das Laden jedes Kernelmoduls einzeln bestätigen lässt - sprich: das Problem lässt sich leichter eingrenzen. Falls das nicht geht, hilft vielleicht ein kleiner Hack ;-) (unter der Annahme, dass das Problem durchs Laden eines Kernelmoduls ausgelöst wird) mv /sbin/modprobe /sbin/modprobe.orig Dann erstellst Du mit $EDITOR ein neues /sbin/modprobe (Vorsicht: ungetestet, könnte also Syntaxfehler enthalten) --- Beginn --- #!/bin/bash echo "MODPROBE CALLED - $@" | logger -t MODPROBE sync sleep 5 sync sleep 5 /sbin/modprobe.orig "$@" retval=$? echo "MODPROBE RESULT $retval - $@" | logger -t MODPROBE exit $retval --- Ende --- Dann noch ausführbar machen: chmod +x /sbin/modprobe Dass mit diesem Hack jeder modprobe-Aufruf 10 Sekunden dauert und in /var/log/messages mitgeloggt wird, muss ich wohl nicht näher erklären, oder? ;-) (könnte also auch das Booten extrem langsam machen, wenn Du rebootest und obiges Script im Einsatz ist) Ich kann Dir jetzt schon versprechen, dass Du einen Bugreport aufmachen "darfst" - die Frage ist nur noch, wie viele Leute fürs Eingrenzen des Problems benötigt werden ;-) Gruß Christian Boltz [1] gefunden auf http://en.opensuse.org/openSUSE:Report_a_YaST_bug [2] eigentlich[tm] ist der Parameter für die erste Stufe der Installation gedacht. Ich hoffe einfach mal, dass er in der zweiten Stufe auch funktioniert ;-) -- Ratti? Darf ich? Darf ich? Darf ich? Darf ich? Kannst du mir das "offiziell" forwarden? Ich bekomm Lust diesem "jeff"-"coola-hacka"-Kerl nicht nur das ein oder andere RfC um die Ohren zu hauen, der ist ja nicht nur ignorant sondern glatt lernresistent! [David Haller in suse-linux] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org