[gelöst] Bootvorgang unterbrochen
[gelöst] Bootvorgang unterbrochen
Hallo,
ich habe hier ein seltsames Problem, bei dem ich nicht weiter weiß.
Ich baue meinen Kernel mittels make-kpkg mit Vorlage der zuletzt funktionierenden Konfig selbst.
Dabei ist mir das hier behandelte Problem beim Sprung von 2.6.32.7 auf 2.6.32.8 aufgefallen. Also seit 32.8 besteht es, ich war nur zu faul mich dem anzunehmen.
Und zwar stoppt der Bootvorgang viele male einfach und kann nur durch Betätigung irgend einer Taste fortgesetzt werden.
Dabei scheint es kein Muster zu geben, das auf ein bestimmtes Modul oder Skript etc. schliessen lässt. Dieses "Anhalten" beginnt schon bevor das Root FS gemountet wird und reicht bis kurz vor den Start des X Login Managers.
Erkennen kann ich es daran, dass der Kursor aufhört mit blinken. Dabei kann er aktiv oder erloschen stehen bleiben. Erst nach Betätigung einer beliebigen Taste beginnt er weiter zu blinken und der Startprozess läuft weiter ... bis zum nächsten "Halt". Eine hohe CPU Belastung scheint es währenddessen nicht zu geben, auch die HDD LED bleibt dunkel.
Mir scheint, das sich diese "Stops" immer an den selben Stellen befinden. Da es über den gesamten Bootvorgang verteilt ca. 20 sein sollten, habe ich mir diese Stellen aber nicht gemerkt.
Mit dem 2.6.32.7 wird sauber bis zum Login durch gestartet, auch jetzt noch.
Mit entsprechen vielen Tastendrücken startet das System letztendlich und läuft dann auch normal ohne Auffälligkeiten. Aber nervig und unpraktisch ist dieser Effekt schon.
Die wenigen Unterschied der beiden Kernel Konfigs habe ich mit diff auf NoPaste [1] geladen.
Könnte eine dieser Einstellungen solch ein Verhalten bewirken? Wozu?
Was fällt euch noch dazu ein?
System beinhaltet ein Gigabyte GA-MA790XT-UD4P, 4 GB Arbeitsspeicher und Phenom X4 810 mit Debian Lenny und genannten Kernel Versionen auf amd64 optimiert.
Ich bedanke mich für hilfreiche Ideen oder gar Lösungen.
[1] 34604
ich habe hier ein seltsames Problem, bei dem ich nicht weiter weiß.
Ich baue meinen Kernel mittels make-kpkg mit Vorlage der zuletzt funktionierenden Konfig selbst.
Dabei ist mir das hier behandelte Problem beim Sprung von 2.6.32.7 auf 2.6.32.8 aufgefallen. Also seit 32.8 besteht es, ich war nur zu faul mich dem anzunehmen.
Und zwar stoppt der Bootvorgang viele male einfach und kann nur durch Betätigung irgend einer Taste fortgesetzt werden.
Dabei scheint es kein Muster zu geben, das auf ein bestimmtes Modul oder Skript etc. schliessen lässt. Dieses "Anhalten" beginnt schon bevor das Root FS gemountet wird und reicht bis kurz vor den Start des X Login Managers.
Erkennen kann ich es daran, dass der Kursor aufhört mit blinken. Dabei kann er aktiv oder erloschen stehen bleiben. Erst nach Betätigung einer beliebigen Taste beginnt er weiter zu blinken und der Startprozess läuft weiter ... bis zum nächsten "Halt". Eine hohe CPU Belastung scheint es währenddessen nicht zu geben, auch die HDD LED bleibt dunkel.
Mir scheint, das sich diese "Stops" immer an den selben Stellen befinden. Da es über den gesamten Bootvorgang verteilt ca. 20 sein sollten, habe ich mir diese Stellen aber nicht gemerkt.
Mit dem 2.6.32.7 wird sauber bis zum Login durch gestartet, auch jetzt noch.
Mit entsprechen vielen Tastendrücken startet das System letztendlich und läuft dann auch normal ohne Auffälligkeiten. Aber nervig und unpraktisch ist dieser Effekt schon.
Die wenigen Unterschied der beiden Kernel Konfigs habe ich mit diff auf NoPaste [1] geladen.
Könnte eine dieser Einstellungen solch ein Verhalten bewirken? Wozu?
Was fällt euch noch dazu ein?
System beinhaltet ein Gigabyte GA-MA790XT-UD4P, 4 GB Arbeitsspeicher und Phenom X4 810 mit Debian Lenny und genannten Kernel Versionen auf amd64 optimiert.
Ich bedanke mich für hilfreiche Ideen oder gar Lösungen.
[1] 34604
Zuletzt geändert von cirrussc am 08.11.2011 20:12:53, insgesamt 1-mal geändert.
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
- Saxman
- Beiträge: 4233
- Registriert: 02.05.2005 21:53:52
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: localhost
Re: Bootvorgang unterbrochen
Eine Idee hab Ich jetzt nicht direkt woran das liegt.
Aktivier doch mal das bootlog und schau dir z.b mal mit bootchart wo die Hänger denn sind.
Vielleicht erkennst du ja irgendeinen Schuldigen.
Aktivier doch mal das bootlog und schau dir z.b mal mit bootchart wo die Hänger denn sind.
Vielleicht erkennst du ja irgendeinen Schuldigen.
"Unix is simple. It just takes a genius to understand its simplicity." - Dennis Ritchie
Debian GNU/Linux Anwenderhandbuch | df.de Verhaltensregeln | Anleitungen zum Review und zum Verfassen von Wiki Artikeln.
Debian GNU/Linux Anwenderhandbuch | df.de Verhaltensregeln | Anleitungen zum Review und zum Verfassen von Wiki Artikeln.
Re: Bootvorgang unterbrochen
Teste das doch einfach einmal, indem du diese beim neueren Kernel deaktivierst und wenn die Probleme damit behoben sind, kannst du ja noch testen, welche Option dieses Verhalten bewirkt.cirrussc hat geschrieben:Könnte eine dieser Einstellungen solch ein Verhalten bewirken?
http://cateee.net/lkddb/web-lkddb/FRAME_POINTER.html
http://cateee.net/lkddb/web-lkddb/KALLSYMS_ALL.html
http://cateee.net/lkddb/web-lkddb/LATENCYTOP.html
http://cateee.net/lkddb/web-lkddb/STACKTRACE.html
http://cateee.net/lkddb/web-lkddb/STRICT_DEVMEM.html
An KALLSYMS_ALL wird es eher nicht liegen.
Gruß,
Daniel
Re: Bootvorgang unterbrochen
Ok, danke.
Das werde ich mal probieren müssen, die Optionen abschalten und neu kompilieren.
Was ich aber noch unerwähnt gelassen habe, als ich den 2.6.30 in der mache hatte, da bootete er das erste mal normal durch. Und ich dachte schon, das Problem sei im Kernel behoben, doch seit dem zweiten Boot mit diesem Kernel war es wieder da
Komische Sache das, ich werde weiter forschen.
Das werde ich mal probieren müssen, die Optionen abschalten und neu kompilieren.
Was ich aber noch unerwähnt gelassen habe, als ich den 2.6.30 in der mache hatte, da bootete er das erste mal normal durch. Und ich dachte schon, das Problem sei im Kernel behoben, doch seit dem zweiten Boot mit diesem Kernel war es wieder da
Komische Sache das, ich werde weiter forschen.
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
Re: Bootvorgang unterbrochen
Bei meinem 2.6.33.3 mit config 2.6.32-5 ist von den fünfen auch nur STACKTRACE und STRICT_DEVMEM aktiviert,
beim Booten damit bis jetzt keine Probleme.
Wie sieht es in Emulation aus?
Plattenkabel abziehen? Platten tauschen?
(Vom 2.6.32-3 -> 2.6.32-4 wurden in debian viele IDE-Treiber zu PATA,
das muß ja einen Anlaß haben, eventuell Kerneländerungen beim vanilla->debian?)
Kombination von beiden oben, nur den Kernel+initrd von usb/CD/floppy, ganz ohne Platten.
beim Booten damit bis jetzt keine Probleme.
Wie sieht es in Emulation aus?
Plattenkabel abziehen? Platten tauschen?
(Vom 2.6.32-3 -> 2.6.32-4 wurden in debian viele IDE-Treiber zu PATA,
das muß ja einen Anlaß haben, eventuell Kerneländerungen beim vanilla->debian?)
Kombination von beiden oben, nur den Kernel+initrd von usb/CD/floppy, ganz ohne Platten.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: Bootvorgang unterbrochen
Ist zwar schon lange her, aber viel hat sich nicht geändert. Vor kurzem habe ich mir mal den aktuellen Vanilla 2.6.36 gebaut. Dabei habe ich komplett auf den alten ATA Stack verzichtet und nur die neuen libATA aktiviert. Geladen wird davon das Modul pata_atiixp. Jedenfalls sind die Haltepunkte jetzt an anderer Stelle
Irgendwie habe ich mich mit diesem komischen Effekt arrangiert.
Irgendwie habe ich mich mit diesem komischen Effekt arrangiert.
Wie, was emulieren?rendegast hat geschrieben:Wie sieht es in Emulation aus?
Erfolglos.rendegast hat geschrieben:Plattenkabel abziehen? Platten tauschen?
Das habe ich allerdings noch nicht probiert.rendegast hat geschrieben:Kombination von beiden oben, nur den Kernel+initrd von usb/CD/floppy, ganz ohne Platten.
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
Re: Bootvorgang unterbrochen
kernel und initrd auf ein image packen und das mit kvm starten,cirrussc hat geschrieben: Wie, was emulieren?
also Abstraktion von der realen Hardware.
make-kpkg bastelt doch auch ein Paket mit debug-Symbolen -> Schrittweise Ausführung?
Eventuell ist ja dieses debug-image "hereingerutscht", und das ist der Grund für die Stops?
Außerdem gibt es ja noch 2.6.34.7 und 2.6.35.8.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-
- Beiträge: 1581
- Registriert: 01.05.2004 13:21:26
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DE
Re: Bootvorgang unterbrochen
Ich bin mir nicht ganz sicher, aber ich glaube kurzzeitig war das bei meiner Kiste hier auch mal der Fall. Da das bei dir in rc-Phase auftritt, wäre das vielleicht der erste Ansatzpunkt. Es gibt da auch einen älteren bug-report, wo dieses Verhalten auch beschrieben wird. Dort ist wohl als Ursache eine falsche Konfiguration von sysvinit bzw. insserv zu lesen.
ciao, storm
ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */
Re: Bootvorgang unterbrochen
Mit KVM habe ich mich noch nicht beschäftigt.rendegast hat geschrieben:kernel und initrd auf ein image packen und das mit kvm starten,
also Abstraktion von der realen Hardware.
Also mal klassisch, per make bauen?make-kpkg bastelt doch auch ein Paket mit debug-Symbolen -> Schrittweise Ausführung?
Eventuell ist ja dieses debug-image "hereingerutscht", und das ist der Grund für die Stops?
Die betreffenden Initskripte sind bei mir unangetastet, also auch kein CONCURRENCY aktiviert. Insserv ist auch gar nicht installiert.storm hat geschrieben:Es gibt da auch einen älteren bug-report, wo dieses Verhalten auch beschrieben wird. Dort ist wohl als Ursache eine falsche Konfiguration von sysvinit bzw. insserv zu lesen.
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
Re: Bootvorgang unterbrochen
qemu kann auch ein System auf der lokalen Platte emulieren. Mit der Option "-snapshot" bleibt das Dateisystem unangetastet.cirrussc hat geschrieben:Wie, was emulieren?rendegast hat geschrieben:Wie sieht es in Emulation aus?
Täuschung ist das Silikon der Postmoderne.
Re: Bootvorgang unterbrochen
ich dachte erstmal nur an eine Prüfung, ob nicht beim Installieren das/ein dbg-Paket dazugekommen ist.cirrussc hat geschrieben: Also mal klassisch, per make bauen?
(jedoch müßten die Möglichkeiten des linux-image...dbg...deb ja wohl auch eingeschaltet werden?)
oder irgendwelche zusätzlichen (und aktiv überwachten) debug-Optionen, als Bsp. mein 2.6.36-ala-debian:
Code: Alles auswählen
$ cat /boot/config-2.6.36 | egrep -i "dbg|debug" | grep -v "^#"
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_SLUB_DEBUG=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_PM_DEBUG=y
CONFIG_WIMAX_DEBUG_LEVEL=8
CONFIG_CB710_DEBUG_ASSUMPTIONS=y
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_SCSI_DEBUG=m
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_MLX4_DEBUG=y
CONFIG_B43LEGACY_DEBUG=y
CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_USB_SERIAL_DEBUG=m
CONFIG_INFINIBAND_MTHCA_DEBUG=y
CONFIG_INFINIBAND_IPOIB_DEBUG=y
CONFIG_OCFS2_DEBUG_MASKLOG=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_DLM_DEBUG=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_SCHED_DEBUG=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_RODATA=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
das habe ich erst gemerkt, als mir meine 2GB-Build-RAMdisk vollgelaufen ist.
(Meine einzigen "debug-Symbole" bisher waren Stop-echos in Skripten.
Aber Programme (kernel?) reagieren ähnlich? Hangeln sich von debug-Marke zu debug-Marke?
Das wäre dem von Dir beschriebenen Verhalten ähnlich.)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: Bootvorgang unterbrochen
Also so ein Paket wird bei mir nicht gebaut, deshalb auch nicht installiert.rendegast hat geschrieben:ich dachte erstmal nur an eine Prüfung, ob nicht beim Installieren das/ein dbg-Paket dazugekommen ist.
Habe mir auch schon überlegt, ob da vllt. irgend eine neue Debug Option aktiv ist. Wie gesagt hatte ich aber immer nahezu die selbe Config
Hier jedenfalls mal die grep Ausgabe:
Code: Alles auswählen
# cat /boot/config-2.6.36-1000hz | egrep -i "dbg|debug" | grep -v "^#"
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_SLUB_DEBUG=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_PNP_DEBUG_MESSAGES=y
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_DEBUG_KERNEL=y
CONFIG_SCHED_DEBUG=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
Nein überhaupt nicht. Wie gesagt nur beim Booten (und vor dem mount des Root-FS) und danach läuft er makellos.rendegast hat geschrieben:(Meine einzigen "debug-Symbole" bisher waren Stop-echos in Skripten.
Aber Programme (kernel?) reagieren ähnlich? Hangeln sich von debug-Marke zu debug-Marke?
Das wäre dem von Dir beschriebenen Verhalten ähnlich.)
Qemu schwirrte mir auch schon im Gedanken ... allerdings habe ich einen angepassten Kernel (Chipsatz usw.), der wird sicher in keiner VM laufen.AspeLin hat geschrieben:Debianqemu kann auch ein System auf der lokalen Platte emulieren. Mit der Option "-snapshot" bleibt das Dateisystem unangetastet.
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
Re: Bootvorgang unterbrochen
Ich habe genau diesen Kernel jetzt in einer Squeeze Installation auf einer anderen Partition installiert und gestartet. Scheint ohne diesen Effekt zu laufen.
Also am Kernel alleine wird's nicht liegen ...
Also am Kernel alleine wird's nicht liegen ...
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
Re: Bootvorgang unterbrochen
Da sich nach allen erdenklichen Versuchen und selbst nach einem Upgrade auf Squeeze (keine Neuinstallation) nichts geändert hat und ich mich sowieso schon daran gewöhnt hatte, habe ich das quasi aufgegeben. Der Bootprozess hing wie gesagt an sich ständig ändernden Stellen und musste durch betätigen einer beliebigen Taste wieder an geschubst werden.
Ich habe aber vor knapp drei Wochen ein BIOS Update von dem F8 Beta auf ein finales F8 gemacht. Seit dem ist er immer anstandslos komplett durchgestartet, ohne einen der bekannten Hänger.
Ich gehe davon aus, dass sich das Problem wohl damit erledigt hat. Ob es nun am neuen BIOS oder an den zwangsläufig neu gesetzten (DMI und Konfig wird ja beim Update gelöscht) Einstellungen lag, kann ich nicht sagen.
Ich habe aber vor knapp drei Wochen ein BIOS Update von dem F8 Beta auf ein finales F8 gemacht. Seit dem ist er immer anstandslos komplett durchgestartet, ohne einen der bekannten Hänger.
Ich gehe davon aus, dass sich das Problem wohl damit erledigt hat. Ob es nun am neuen BIOS oder an den zwangsläufig neu gesetzten (DMI und Konfig wird ja beim Update gelöscht) Einstellungen lag, kann ich nicht sagen.
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl