Hallo,
der boot-Vorgang bleibt bei meinem Notebook Fujitsu Siemens Lifebook E2010 häufig hängen. Es tut sich dann nichts mehr, Notebook muss abgeschaltet werden. Es ist die Stelle, an der der DMA-Mode der Festplatte und des DVD-Laufwerks eingestellt wird. Die Ursache kann aber auch an anderer Stelle liegen.
Bei Suse Linux kann man einstellen, dass die einzelnen Vorgänge des boot-Vorgangs mit “yes” bestätigt werden müssen. Wenn ich dies tue, läuft der boot-Vorgang immer einwandfrei durch, wenn nicht, dann läuft er manchmal durch manchmal nicht.
Außerdem kann man die Paralellität der boot-scripte abschalten. Dies habe ich getan, bringt aber für mein Problem nichts.
Ich vermute, dass hier ein Problem der Reihenfolge der einzelnen boot-Vorgänge vorliegt. Auch wenn ich die boot.msg und boot.omsg vergleiche, sehe ich Unterschiede. BTW: Auch bei erfolgreichen boot-Vorgängen unterscheiden sich die boot.msg Dateien, es scheint dem Zufall überlassen zu sein, was protokolliert wird und was nicht,
Es ist mir aber noch nicht gelungen, etwas Signifikantes zu finden. Darum die Frage an die Community: Hat vielleicht jeamnd eine Idee, woran das Verhalten liegen kann und vielleicht sogar eine Lösung?
Danke im Voraus,
Reinhard.
Bin jetzt mit den SuSE Distris nicht so vertraut.. Aber wenn du sagst, es ist wahrscheinlich an der Stelle, an der DMA gesetzt wird, dann solltest du überprüfuen, ob “hdparm”, das dazu verwendet wird, auch die richtigen Flags setzt.
Mit “hdparm -I /dev/” kannst du checken, welche Features Deine Festplatte unterstützt, und welche aktiviert sind. Dazu noch die Datei “/etc/hdparm” vergleichen, dort werden die ermittelten Einstellungen dauerhaft (für den Systemstart) aktiviert.
Lg,
Oliver
Hallo Oliver!
Danke für den Hinweis. Es scheint aber mit hdparm alles ok zu sein. Ich habe, da ja das booten häufig auch funktioniert und wenn ich einstelle, jeden Schritt des Bootvorgangs zu bestätigen, das booten immer funktioniert, den Verdacht, dass es mit der Parallelität und damit mit der Reihenfolge der Ausführung der boot-scripten zu tun hat.
Wen’s interessiert: Die Bestätigung der Ausführung der einzelnen boot-scripten kann in der Datei /etc/init,d/boot eingestellt werden. Am Anfang dieses scripts PROMPT_FOR_CONFIRM=”yes” setzen. Die Parallelität kann mit RUN_PARALLEL=”no” abgeschaltet werden (jedenfalls interpretiere ich das script so).
Ich bin mir auch nicht sicher, ob der Totalabsturz wirlich in script boot.idedma passiert oder ob es ein anderer Vorgang ist, der im Hintergrund gleichzeitig abläuft.
Gibt es die Möglichkeit, die Protokollierung der Vorgänge zu verbessern?
Gruß, Reinhard.
Eine Reihe vielleicht trivialer Vorschläge: die HD schon auf fehlerhafte Sektoren geprüft? Welches Dateisystem ist denn eingestellt? ReiserFS? Welche Version? Schon den RAM getestet und an den Kabeln gewackelt (ebenfalls ein unwahrscheinlicher aber nicht völlig auszuschließender Grund)?
Du könntest auch mal probehalber in der /etc/inittab einen anderen Runlevel als initdefault einstellen, das grenzt dann zumindest schonmal den Suchbereich ein.
Und: ist das ein neu auftretendes Verhalten, oder ist die 9.3 frisch installiert? Dann lohnt es sich manchmal die Installation zu wiederholen (mit ggf. geputzter DVD oder von den CDs).
Zwecks Protokollierung kannst Du meiner Erinnerung nach die Dokumentations”tiefe” in einem der yast-Module einstellen.
Gruß
BEnjamin
Hab jetzt nicht wirklich nen Tip, hatte aber schon öfters ein ähnliches Problem: Wenn an meinem Notebook beim booten Netzwerkdienste, wie NTP-Client und/oder das Updatetool (YOU) gestartet wurden, ich aber kein Netzwerk angeschlossen hatte, blieb mein Notebook and der Stelle “hängen”.
Ich habe die betreffenden Dienste dann im initscript deaktiviert.