2.6.24.7 Bootprobleme [gelöst]

[confusion]

Guten Abend,
ich habe mir gerade einen 2.6.24.7-ner Kernel kompiliert. Nach dem Neustart und Auswahl des Kernels im Grub hängt sich das System beim Booten auf. Zu Erst ca. 1 Minute bei folgender Fehlermeldung:

Code: Alles auswählen

clocksource tsc unstable (delta = -399012296 ns)

Dann geht es weiter und er steht bei folgender Meldung:

Code: Alles auswählen

Begin: Waiting for root file system... ...

Nach 2 weiteren Minuten warten ist dann hier komplett Schluß:

Code: Alles auswählen

/bin/sh: can't access tty; job control turned off
(initramfs)

Danach geht es gar nicht mehr weiter...
Das Problem mit clocksource tsc unstable hatte ich auch, als ich mit dem 2.6.24-Image von "Etch and a Half" gebootet habe.
Hat jemand eine Lösung für das Problem? In einem Thread habe ich den Tipp gefunden, beim booten dem Kernel clocksource=acpi_pm mitzugeben, dass hat aber auch nicht geholfen

MfG

confusion

[cirrussc]

Hi,

du hast sicherlich vergessen, die initrd zu bauen und auch vom grub laden zu lassen:

Code: Alles auswählen

mkinitramfs -o /boot/initrd-$(uname -r) $(uname -r)
update-grub

CONFIG_CRAMFS=y sollte im Kernel gebaut sein.

[confusion]

Ne, dass habe ich gemacht. Hab den Kernel mit kernel-package erzeugt und als Parameter initrd mit übergeben...
Der nötige Eintrag war auch in Grub vorhanden...

Ich habe gerade nochmal das Paket von "Etch and a Half" installiert und genauer hingeschaut: Der Bootprozess sieht genauso aus wie oben beschrieben... Also habe ich anscheinend nicht allzuviel falsch gemacht =).

Der Prozessor ist ein Intel Atom falls das weiterhilft, aber das hat ja bestimmt nichts damit zu tun, dass er die Partition gar nicht findet....

Ich bin ratlos

[KBDCALLS]

Hi,


CONFIG_CRAMFS=y sollte im Kernel gebaut sein.

CRAMFS wird schon seit Kernel 2.6.13 bei Debian nicht mehr verwendet.

[cirrussc]

CAMFS wird schon seit Kernel 2.6.13 bei Debian nicht mehr verwendet.

Ohh ja stimmt, das ist schon veraltet.


@Confusion
Die atoms sind glaub ich normale i686.
Du hast bestimmt etwas Elemetares vergessen, in der config.
Er kann das root FS nicht mounten.
IDE Treiber drinen?
FS Treiber?
Was hast du denn für Hardware (lspci)?

[confusion]

Kann gut sein, dass ich was wichtiges vergessen habe, aber ich weiß ja nicht was... Ist ja auch nicht schlimm, sollte es so sein, aber was mich stutzig macht ist, dass das offizielle 2.6.24-Image aus dem Paketarchiv (Etch and a Half) genau den selben fehlerhaften Bootverlauf hat...

[KBDCALLS]

Hab gerade mal folgendes gefunden.

Veruche mal das mal als Bootparameter

Code: Alles auswählen

clocksource=pit

Das Problem ist anscheinend weit verbreitet.

[confusion]

Hat die Clocksource den überhaupt was mit dem nicht gefundenen root-file-system zu tun?
Wenn nicht dann ist der schlimmere Fehler, der das System nicht booten lässt, doch an einer anderen Stelle zu suchen...

Das mit der Clocksource ist störend, aber es wäre ja zumindest einmal schön, wenn sich das System danach booten lässt =).

Ich werde es gleich in meiner Mittagspause einmal probieren...

[KBDCALLS]

Es ist doch etwas seltam das auch der Originalkernel Probleme bekommt.

[confusion]

Auf meinem Desktop-Rechner funktionieren beide Kernel einwandfrei...
Woran könnte es den liegen, wenn das root-file-system nicht gemountet oder gefunden werden kann?

[KBDCALLS]

Muß man mal sehen, woran es liegt. Es könnte zu Beispiel ein Treiber fehlen, oder möglicherweise sogar einer zuviel sein. Aber funktioniert es denn mit der Änderung oder immer noch nicht ?

[cirrussc]

Das ist wirklich Kurios, was hast du denn nun genau für Hardware lspci (eventuell von Live-CD)?
Dumme Frage: aber bist du dir auch wirklich sicher, den originalen Kernel gestartet zu ja haben?

[KBDCALLS]

Clocksource dürfte das eigentlich auch nicht versursachen. Damit ich zukünftig derartigen Problemen aus dem Wege gehe , habe ich die fstab und die menu.lst kommplett auf uuids umgestellt. Ausgenommen CD/DVD, Brenner und Floppy. Zumal ich eine Festplatte nur manchmal angeschlossen habe. Und sich dadurch die Laufwerksnamen verschieben.

[confusion]

Ich habe gestern abend mal den 2.6.25.10 probiert und dort auch wieder ein Problem beim booten gehabt.
Das Clocksource-Problem tritt dort zwar auch auf, aber der Bootvorgang bleibt an dieser Stelle nicht hängen.
Ich glaube das Problem hängt damit zusammen, dass ich die .config meines 2.6.18 Kernels genommen habe und mit der Grundlage die anderen Kernel konfiguriert habe. In einem anderen Thread in diesem Forum, wo ein ähnliches Bootproblem beschrieben wird (http://www.debianforum.de/forum/viewtopic.php?p=597842), habe ich dann gelesen, dass der SATA-Treiber explizit ausgewählt werden muss. Das würde meiner Meinung nach auch erklären, warum er beim Booten das root-file-system nicht findet...

Ich bin gerade auf der Arbeit und kann daher keine Error-Logs posten oder das Ganze testen...
Wenn ich nachher zu Hause bin werde ich das Ganze mal durchspielen und die Ergebnisse mitteilen =).

[KBDCALLS]

IIch glaube das Problem hängt damit zusammen, dass ich die .config meines 2.6.18 Kernels genommen habe und mit der Grundlage die anderen Kernel konfiguriert habe. In einem anderen Thread in diesem Forum, wo ein ähnliches Bootproblem beschrieben wird

Das das in die Hose geht das war zu erwarten. Vor allem wenn SATA im Spiel ist. Das Problem gibt es schon seint Version 2.6.19. Da hat ma das ganze IDE und SATA System umgestrickt. Die PATA Treiber sind doppelt vorhanden. Wer will kann wählen SATA ist komplett aus den SCSI Zweig verschwunden, da waren sie vorher angesiedelt, und sind dann komplett ins ata Vereichnis gewandert. Da findet man auch die neuen PATA Treiber.Debian hats erstmal bei den alten gelassen. Während UBUNTU die neuen nutzt. Mit der Konsequenz das sämliche Laufwerke als sdx erscheinen. hdx gibt es dann nicht mehr. Zumindest bei Festplatten.

[confusion]

Und was mach ich da nun am besten?

[KBDCALLS]

Um solchen Widrigkeiten aus dem Weg zu gehen habe ich schon länger die fstab und auch die menu.lst auf uuid umgestellt. Auch hat Grub eine minimale shell mit der man nach dem Kerrnel oder auch einer anderen Datei suchen kann. Und dann könnte man Knoppix oder ähnliches booten un die Dateien passend abändern.

[confusion]

Schon beim 2.6.18 wurde meine HDD als sdx und nicht als hdx erkannt... Mit den uuids hatten die Boot-Probleme also nichts zu tun...
Ich habe den Kernel jetzt nocheinmal mit Sata unterstüzung kompiliert und es klappte auf Anhieb =)

Danke für die Hilfe

MfG

confusion

[confusion]

Btw hab' ich gerade Lenny installiert und kann nicht booten wegen oben dem selben Problem =)

[urnenmann]

@ confusion

ich hatte das selbe problem nach dem upgrade auf etchnhalf.
siehe hier http://debianforum.de/forum/viewtopic.php?f=33&t=90467
bei mir hat geholfen als bootparameter nohz=off in die menu.list zu schreiben.
vielleicht hilft es dir auch.
das problem besteht scheinbar ab kernel 2.6.24
hat wohl was mit tickless-kernel zu tun, sowas wie ein energiesparmodus für den prozessor
siehe auch hier:
http://www.golem.de/0704/51728.html

oder hier: http://www.unixboard.de/vb3/showthread.php?t=35439

ist für x86_64 prozessoren scheinbar erst ab 2.6.24 aktiviert für x86 schon ab 2.6.21

wenn es ein intel atom diamondville prozessor ist, hat er ja auch 64 bit unterstützung und fällt unter diese problematik...

probier es mal aus mit dem bootparameter

gruss urnenmann

[ah966]

Hallo zusammen,

hatte auch Bootprobleme.

Auf einem Server ist Debian Etch 4.0r3 installiert, habe dann den 2.6.24er Kernel über aptitude installiert, standardmäßig wird ja der 2.6.18er benutzt.
Während des Startvorgangs bleibt er ebenfalls im (initramfs) stehen.
Das Problem:
Bei der Kernel-Installation wird die /boot/grub/menu.lst umgeschrieben, der neue Kernel mit eingetragen.
Allerdings, und das verstehe ich nicht, wird auf die falsche Platte verwiesen.
Der Parameter

Code: Alles auswählen

root=

zeigt normalerweise bei mir auf sda2 (sda1 ist /boot) und nach der Installation verweist das Ganze auf sdb2, AUCH beim "alten" 2.6.18er Kernel, da damit ja auch nicht mehr gestartet werden kann.
Eine entsprechende Änderung in der menu.lst behebt das Problem - das System startet wieder.

Weiß jemand, woher die Infos über die Geräte herkommen, die in der menu.lst eingetragen werden?
Irgendwo ist doch etwas verstellt worden, sdb2 existiert bei mir nämlich gar nicht...

EDIT: OK, hab's gefunden: In der /boot/grub/device.map steht's (falsch) drin. Wer hat das da reingetan? Und warum?

[habakug]

Hallo!

Du solltest einen eigenen Thread eröffnen (siehe Forumsregeln).
Zwischendurch kannst du, wenn in der /etc/kernel-img.conf steht:

Code: Alles auswählen

postinst_hook = update-grub
postrm_hook   = update-grub

die Manpage von "update-grub" lesen. Dann weisst du sicher mehr.

Gruß, habakug