neuer Kernel startet nicht :(

[chr|s]

Hallo,

versuche gerade mir wegen dem Ati-Grafiktreiber einen neuen Kernel zu installieren. Mit
meinem 2.6.21 gehts ja wegen der Paravirt-Option nicht.

Problem ist, dass egal welchen kernel ich nehme, die Kiste einfach nicht startet. In grub auswählen,
enter drücken, es kommt noch die Ausgabe von grub und dann wars das. Schwarzer Bildschirm und
nichts geht mehr.
Dabei ist es auch völlig egal, ob ich den kernel per apt-get hole oder selbst kompiliere. Habe den 2.6.22,
2.6.21 und 2.6.19 versucht, alle ohne Erfolg.

Und leider keine Ahnung woran es liegen könnte.

Habe mir vor einiger Zeit vmware installiert und dabei ziemliche Probleme gehabt wegen dem Kernel-modul.
Zwischendurch hatte ich auch mal einen fehlgeschlagenen Versuch mit xen. Kann gut sein, dass ich dabei
was zerschossen hab, nur was ?

Mein bisheriger 2.6.21-686-bigmem funktioniert derweil einwandfrei, nur auf einen anderen Kernel wechseln geht partout nicht.

Hat jemand ideen ?

Vielen Dank schon mal

[cirrussc]

Hi,

lädt er wirklich nicht mehr oder ist nur ein Invalider Wert für den Frambuffer angegeben?
Poste mal bitte deine /boot/grub/menu.list.

Gruß cirrussc

[chr|s]

er bootet wirklich nix, das system steht komplett, num lock z.B. reagiert nicht.
Aber trotzdem hier die menu.lst

Edit KBDACLLS : Menu.lst entfernt und nach Nopaste verschoben. Bitte beachte Punkt 2.6 der Verhaltensregeln.

[frodo]

Moin, Moin

mal ein Schuss ins Blaue.

Ändere doch mal den VGA-Wert

Code: Alles auswählen

vga = 0x317

Grüße

[chr|s]

nope das wars auch nicht.
Aber ich glaube auch nicht so recht, dass es an der Auflösung liegt, weil die Kiste komplett hängt und überhaupt gar nichts anzeigt. Nicht mal Streifen oder ein verzerrtes Bild.

[frodo]

Moin, Moin

Mein bisheriger 2.6.21-686-bigmem funktioniert derweil einwandfrei, nur auf einen anderen Kernel wechseln geht partout nicht.

Also wenn dein 2.6.21-686-bigmem funktioniert glaube ich nicht das da war grawierendes zerschossen wurde.


Hast du die Kernel von grundauf neu konfiguriert oder ein make oldconfig

# Dateisystem, Chipsatz, SATA fest einkompiliert? ( Spreche aus eigener Erfahrung )


Post doch mal ein

Code: Alles auswählen

lspci -v

und deine Kernel Config.


Grüße

[chr|s]

In der kernel-config hab ich nichts geändert, einfach den standard übernommen.
Aber im Moment will ich auch keinen vanilla-kernel, sondern einfach nur den
vorkompilierten 8.6.22-686-bigmem vom debian-repository.

hier mal lspci -v:

Edit KBDACLLS : lspci -v entfernt und nach Nopaste verschoben. Bitte beachte Punkt 2.6 der Verhaltenregeln.

[Smokey87]

Hi,

ich habe das gleiche Problem mit dem Kernel > 2.6.21. Den 2.6.23-1 Kernel habe ich mittels "make oldconfig" erfolgreich kompiliert und mit "make-kpkg" ein deb-Package erstellt. Hat alles wunderbar geklappt, bis es an's booten ging. Nachdem Grub den neuen Kernel geladen hat, dauert es so ca. 1-2 Minuten und dann kommt die Fehlermeldung:

Code: Alles auswählen

ata1.00: failed to set xfermode (err_mask = 0x4)

Nach dem ich Google dazu befragt habe, fand ich u.a. den Hinweis, in die menu.lst bei den Kerneloptionen die Option "irqpoll" hinzuzufügen. Lieder half das bei mir auch nix. Laut der Kernel-Mailinglist soll dieser Patch das Problem lösen, bei mir leider nicht.

Anscheinend haben Kernel > 2.6.21 Probleme mit meinem SATA-Controller (Intel 82801FR/FRW). Lieder habe ich bis jetzt keine Lösung für dieses Problem gefunden und benutze deshalb noch den 2.6.21-Kernel. Hat von euch jemand noch eine Idee. Bin für Ratschläge dankbar!

@ chr|s: Ich hatte das Problem mit der Paravirt-Option ebenfalls und habe sie notgedrungen beim 2.6.21 Kernel ausgeschaltet. Funktioniert klasse! Hier ein Link zur Lösung http://www.debiantutorials.org/talkitup ... 28.msg2738

[chr|s]

@smokey87:
wir haben leider nicht das selbe Problem, da ich auch ältere Kernel nicht booten kann. Auch nicht einen selbstkompilierten 2.6.21 !
Lustigerweise ist der einzige der geht mein per apt-get seit langem installierter 2.6.21.
Alles andere will nicht.

[chr|s]

Problem gelöst durch Linux-Neuinstallation

[storm]

Na toll, du hast das Problem gelöst. Aber in typischer Windows-Manier. Du weisst jetzt nix über die Ursache des Problems und somit wirst du möglicherweise wieder irgendwann vor der Entscheidung stehen, die Partition plattzumachen um neu zu installieren. Damit hilfst du dir doch nicht. Auch ist anderen Usern nicht geholfen. Nur für das nächste Mal: geh den Problemen auf den Grund, das schafft Wissen und es fühlt sich auch viel besser an! *g
Ein paar Tips:

• Falls du einen zweiten (Linux-)Rechner in der Nähe hast, kannst du mit zwei Methoden versuchen, die Meldungen des unwilligen Rechners auf dem anderen darzustellen. Möglicherweise siehst du noch eine Beschwerde des Kernels, bevor er den weiteren Betrieb einstellt. Das ist einerseits die serielle Konsole, bei dem ein Nullmodem-Kabel zwischen den zwei Rechnern die Verbindung herstellt. Dem zu bootenden Kernel muss noch eine Option mitgegeben werden, auf dem zweiten Rechner ist minicom zu starten. Etwas ausführlicher ist das unter [1] beschrieben. Die zweite Methode ist ähnlich, nur das in diesem Fall das Netzwerk zum Einsatz kommt. Das ganze heisst dann netconsole, leider ist die bei den fertigen kernel-Paketen nur als Modul vorhanden (schlecht, da sie so früh wie möglich im boot-Prozess auftauchen sollte). Mehr unter [2] oder [3]. Beide Methoden können sicherlich nicht garantieren, dass du den Fehler zu Gesicht bekommst.
  
  Ohne einen zweiten Rechner sind noch andere Möglichkeiten vorhanden, wie den Problemen auf den Grund gegangen werden kann. Zum Beispiel mit einem minmalen, sicheren Kernel starten, d.h. es wird schon ein Kernel verwendet, der zum Absturz führt, allerdings klammert man alle (bekannten) kritischen Punkte aus. Sei es, indem im BIOS beispielsweise alles Unnötige ausgeschaltet oder auf sichere Werte* gesetzt wird. Weiterhin gibt es einige, bekannte Schwachstellen die mit Hardware zusammenhängen, die aber über kernel-Parameter beim Start beeinflusst werden können. Typische Kandidaten sind acpi (power-managment) oder die ganze Gruppe der Interrupt-Techniken (apic, PCI/PCIe). Den ganzen Sack an möglichen Optionen für die Module beschreibt die Datei kernel-parameters.txt, die sich im Subordner Documentation der Kernel-Quellen befindet.
  
  Vorhergehende Probleme: wenn du der Meinung bist, dass mit den vorhergehenden Spielereien mit xen/vmware irgendetwas im System beschädigt wurde, dann solltest du auch an dieser Stelle nachforschen, ob dass für die Probleme verantwortlich ist. Das gilt auch den ATI-Treiber. Wurden vielleicht wichtige Dateien gelöscht oder überschrieben, sind von der Installation/Deinstallation noch logs vorhanden, die auf Probleme hinweisen. Wenn ein neuer Kernel (per apt) installiert wurde, hat apt/dpkg sich eventuell beschwert. Wenn ein neuer Kernel selbst gebaut wurde, ging das Kompilieren problemlos, konnte das Paket ohne Probleme erstellt werden.
  
  Jeder halbwegs begeisterte Linux-Anwender hat wenigstens eine Live-Distribution - etwa Knoppix - in Reichweite. Die sind für das Testen von Hardware-Erkennung und -betrieb viel wert. Bootet diese ohne Probleme oder geht das auch nur im failsafe-Modus? Zur Not tut es auch ein debian-Installations-Medium oder ähnliches.

Es gibt noch ein paar mehr Punkte, die in die Liste rein könnten, aber einerseits steigt der Anspruch erheblich an und andererseits lassen sich mit den obigen Punkten IMHO schon eine ganze Menge Probleme eingrenzen.


* sichere Werte: ein Beispiel, dass ich selbst erlebt hab. Hier ist in Bezug auf das Board ähnliche Hardware am laufen (nvidia nForce) und die unterstützt unter anderem auch DDR2-800. Es sind auch Riegel dieser Kategorie verbaut. Bisher war im BIOS der vollautomatische Betrieb eingestellt, d.h. man muss nichts einstellen, Speichertimings und -frequenzen werden auf optimale Werte eingestellt. Nur ist das weit unter dem, was Board und Speicher eigentlich kann. Da ich Wert darauf lege, dass die Technik auch das tut, was ich erwarte, hab ich im BIOS eben mal höhere Frequenzen entsprechend dem Speicher eingestellt. Das war zu Zeiten eines 2.6.22.9 und lief ohne Probleme, der Gewinn war - sagen wir mal marginal. Als dann 2.6.23 released wurde, hab ich wie üblich gleich einen neuen Kernel gebaut und gestartet. Der lief keine 24h und fror irgendwann nicht nachvollziehbar ein. Natürlich hab ich weiterhin versucht, die Ursache rauszufinden. Manchmal bootete der Kernel und lief wieder ein paar Stunden problemlos, andermal ging er schon während des Bootens fest. Die auftauchenden Fehlermeldungen (oopses) waren zwar immer irgendwie aus dem Bereich ATA (Platten, Laufwerke) und irq-handling, allerdings nie wirklich die gleiche Ursache. Selbst das Abschalten der kritischen Punkte wie apic oder acpi brachte keine Besserung. Dann fiel mir der Speicher wieder ein und ich hab alles zurückgesetzt auf optimales (automatisches) Setup - weg war das Problem. Daraus zieh ich zwei Schlüsse: 1) der Kernel ist nicht das Problem, er triggert es nur. Möglicherweise liegt das am neuen Scheduler (der macht sich auch anderweitig bemerkbar). 2) meine überwiegend schlechte Meinung zu nvidia (ok, der Board-Hersteller hat auch seinen Anteil dran) behalte ich bei, die HW kann eben nicht, was vom Hersteller versprochen wurde. In Zukunft mach ich einen Bogen drum, auch wenn es bei anderen vielleicht nicht besser aussieht.


ciao, storm


[1] http://www.brueck-computer.de/index2.ph ... 403&link=1
[2] http://km.fargonauten.de/blog/nils/2007 ... netconsole
[3] http://www.coraid.com/support/cln/CLN-H ... 01s09.html