Kernel 2.6.12 - Compilier- und Konfigurationsprobleme

leppenraub · 28. August 2005

Hallo zusammen,

Bin gerade am Kernelbacken und habe dafür die Quellen vom 2.6.12-ct-1-Image als Grundlage genommen, ebenso dessen .config

Selbst ohne Änderungen an der Konfiguration, Neukompilieren und Installation, bleibt mir beim Booten das System hängen mit

Code

cannot open /dev/console
Kernel panic... usw.

Mein VDR besitzt zwei Platten, eine ATA am Primary-IDE-Controller und eine SATA im Kompatibilitäts-Modus (unter 2.4 als /dev/hdc)
Seltsamerweise erkennt er mir diese Platten beim Boot mit dem selbst gebackenen 2.6.12-Kernel als "sda" und "sdb" ?!?!

Mit dem gleichen System bootet das (per apt-get gezogene) kernel-image-2.6.12-ct-1 anstandslos. Daher finde ich das Verhalten höchst merkwürdig, sollte doch eigentlich das gleiche Abbild sein, oder?

Gruß, leppenraub

leppenraub · 30. August 2005

Hat keiner 'ne Idee? Ich komm' nicht weiter....

reibuehl · 30. August 2005

Hast Du mal kontrolliert, ob du die richtige initrd verwendest? Ausserdem könnte sowas auch an dem unterschied in den Disk bezeichnungen liegen. Probier mal per Grub den Boot-Parameter root=/dev/... auf das device zu setzen, unter dem der neue Kernel die Platte findet. Verwendest Du make-kpkg zum Kernel bauen? Wenn nicht, probier mal folgendes:

.config des ct-Kernels ins Kernel Source Verzeichnis kopieren, dann einmal make menuconfig und ohne Änderungen wieder mit exit raus. Dann "make-kpkg clean" und make-kpkg --revision=custom.1.0 kernel_image

Das erzeugt dann ein kernel_image*.deb das mit dpkg -i installiert werden kann. Dabei wird dann auch die initrd korrekt erzeugt und LILO bzw. Grub richtig konfiguriert.

Gruß,
Reiner.

leppenraub · 30. August 2005

Hallo Reiner,

Vielen Dank, dass Du Dich meiner erbarmst...

Zitat

Original von reibuehl
.config des ct-Kernels ins Kernel Source Verzeichnis kopieren, dann einmal make menuconfig und ohne Änderungen wieder mit exit raus. Dann "make-kpkg clean" und make-kpkg --revision=custom.1.0 kernel_image

hatte ich schon versucht, aber ohne "make-kpkg clean". Trotzdem habe ich nochmal ganz frisch angesetzt und zwar:
- 2.6.12-ct-1 source und image de- und installiert
- Quellen entpackt
- ln -s [...] linux auf dieses Verzeichnis
- Entsprechende config-2.6.12-ct-1 von /boot/ nach /usr/src/linux/.config kopiert
- make menuconfig
- beendet ohne Abspeichern
- make-kpkg clean -arch i386 (mit Architektur, sonst Fehler)
- make-kpkg --revision=custom.1.0 -arch i386 kernel_image
- dpkg -i kernel-image[bla, bla].deb
- keine initrd da, daher mkinitrd -o /boot/initrd-2.6.12 2.6.12
- in lilo alles eingetragen, einmal lilo aufgerufen
- Neustart - Gleiches Problem....

(ich glaube, die initrd packt er mit, wenn man make-kpkg die Option --initrd mitgibt - hatte ich aber auch schon versucht)

Zitat

Original von reibuehl
Probier mal per Grub den Boot-Parameter root=/dev/... auf das device zu setzen, unter dem der neue Kernel die Platte findet.

Das habe ich dann auch gemacht: root=/dev/sda2 - Tadaaa! er bootet! Aber das kann's doch nicht sein, oder?

Gruß, leppenraub

reibuehl · 31. August 2005

Klasse das es jetzt doch funktioniert. Allerdings verwundert mich doch, das Du --arch i386 angeben mußt. Ich hab in der letzten Zeit einige Versionen des 2.6.12.3 Kernel gebaut und musste diesen Parameter nie verwenden. Kann es sein, daß die c't Sourcen nichts taugen? Nach meinen bisherigen Erfahrungen mit dem nachbauen der c't Kernel währe das durchaus nicht ungewöhnlich. Ich hab es bisher nämlich noch nie geschaft, einen c't Kernel anhand des config Files und des c't Source Packets erfolgreich nachzubauen. Wenn Du die Möglichkeit haßt, kann ich nur empfehlen, auf Standard-Kernel oder die -mm Variante von Andrew Morton zu wechseln. So gut die ctvdr auch ist, der Kernel-Bereich war immer undurchsichtig und meiner Meinung nach vermurkst. Teilweise fehlen dinge wie VESA-FB oder DMA, dann kompiliert das Zeug nicht in unveränderter Konfiguration... usw.

Gruß,
Reiner.

leppenraub · 31. August 2005

Zitat

Original von reibuehl
Kann es sein, daß die c't Sourcen nichts taugen?

Das glaube ich langsam auch...

Zitat

Original von reibuehl
Wenn Du die Möglichkeit haßt, kann ich nur empfehlen, auf Standard-Kernel oder die -mm Variante von Andrew Morton zu wechseln.

Muss ich bei den Standardkerneln viel konfigurieren, damit der VDR läuft? Bei einigen Einstellungen habe ich schlichtweg Null-Peilung und das läuft dann auf "try-'n'-error"-Methodik hinaus.

Gruß, leppenraub

reibuehl · 31. August 2005

Zitat

Muss ich bei den Standardkerneln viel konfigurieren, damit der VDR läuft?

Also ich musste nur die LIRC Module separat bauen. Das geht aber ganz einfach wenn Du mit "apt-get install lirc-modules-source" die notwendigen Sourcen installierst. Das Packet legt ein lirc-modules.tar.bz2 nach /usr/src, das Du dort nur auspacken und mit "dpkg-reconfigure lirc-modules-source" konfigurieren musst. Im Kernel-Source genügt dann ein "make-kpkg --revision=custom.1.0 modules_image" um ein zum Kernel passendes LIRC deb Packet zu bauen. Die im 2.6.12.3 enthaltenen DVB Module haben mit meiner Technotrend FF 1.6 DVB-S Karte prima funktioniert. Wenn Du etwas exotischere Hardware wie DXR3 o.ä. hast, kann dies natürlich anderst sein. Als Ausgangspunkt für die Kernel-Konfig kannst Du ja mal die von der c't versuchen, ich würde aber auf jeden Fall erst mal ein make oldconfig drüberlaufen lassen und dann mit make menuconfig möglichst alle Optionen auf Plausibilität kontrollieren.

Gruß,
Reiner.

leppenraub · 1. September 2005

Hallo Reiner,

Danke für die Tips für LIRC, die werde ich demnächst noch brauchen...

Gestern hab' ich's mit einem Standard-Kernel 2.6.12.6 versucht - läuft einwandfrei mit hda2! Die DVB-Unterstützung habe ich allerdings in der Konfiguration aktivieren müssen (habe nicht die ct-.config gewählt) und momentan läuft der Framebuffer noch nicht.

Sollte man eigentlich vor jedem "make-kpkg kernel_image" ein "make-kpkg-clean" machen? Und wenn ja, warum?

Das mit der Architektur-Angabe finde ich nun auch seltsam, 'man make-kpkg' sagt:
"If you are not cross compiling, the architecture is determined automatically." Ist cross-compiling das gleichzeitige Backen verschiedener Architekturen? Mache ich das etwa?

...und noch eine kleine Frage: Was muss man tun, um z.B. eine separate Kernel-Version zu backen, so wie 2.6.12-ct-1? Unter menuconfig/General gibt es zwar ein Eingabefeld für die Version, in die ich probeweise "-lep-1" eintrug, ist das alles?

Gruß, leppenraub

reibuehl · 1. September 2005

Zitat

Sollte man eigentlich vor jedem "make-kpkg kernel_image" ein "make-kpkg-clean" machen? Und wenn ja, warum?

Da bin ich mir selber nicht so sicher. Du solltest es auf jeden Fall machen, wenn Du was am config File änderst. Dabei werden nämlich die Dependency Files gelöscht und nacher neu erstellt, so dass alles "sauber" ist.

Zitat

Das mit der Architektur-Angabe finde ich nun auch seltsam, 'man make-kpkg' sagt:
"If you are not cross compiling, the architecture is determined automatically." Ist cross-compiling das gleichzeitige Backen verschiedener Architekturen? Mache ich das etwa?

Ich vermute mal, dass bei dem vermurksten Source Tree was in dem Bereich der Architektur-Erkennung schief geht. Hast Du eine 64-Bit Architektur oder sowas? Das könnte evtl. zu solchen Ergebnissen führen.

Zitat

...und noch eine kleine Frage: Was muss man tun, um z.B. eine separate Kernel-Version zu backen, so wie 2.6.12-ct-1? Unter menuconfig/General gibt es zwar ein Eingabefeld für die Version, in die ich probeweise "-lep-1" eintrug, ist das alles?

Da gibt es zwei Möglichkeiten: Du kannst den gewünschten String direkt im Toplevel Makefile unter EXTRAVERSION eintragen (so mache ich das immer) oder dem make-kpkg mit der Option --append_to_version übergeben. Die von Dir erwähnte Möglichkeit mit dem Eintrag im config File hat bei mir nicht richtig Funktioniert, da make-kpkg sie bei mir bei kernel_image und modules_image unterschiedlich behandelt hat und die Module dann nicht mehr zum Kernel gepasst haben. Die Methode mit dem Eintrag im Makefile hat den Vorteil, das man nicht jedesmal die make-kpkg option angeben muss - ist echt nervig wenn man 20 Minuten kompiliert und dann feststellt, das man die Option vergessen oder sich vertippt hat

Gruß,
Reiner.

leppenraub · 4. September 2005

Hi,

Zitat

Original von reibuehl

Da bin ich mir selber nicht so sicher.

Ich hätte mir denken können, das der Compiler nur die Teile neu compiliert, welche geändert wurden und der Linker die nicht aktualisierten Teile hinzufügt. Konnte dies allerdings selbst verifizieren, bei Änderung von Parametern im config-File ändert sich am Ergebnis nichts, wenn nicht vorher ein make-kpkg clean gemacht wurde.

Zitat

Ich vermute mal, dass bei dem vermurksten Source Tree was in dem Bereich der Architektur-Erkennung schief geht. Hast Du eine 64-Bit Architektur oder sowas? Das könnte evtl. zu solchen Ergebnissen führen.

64Bit? ne, ne! Muss die Architektur auch bei den 2.6.12.6-Sourcen angeben, sonst läuft da nichts.

Die Sache mit der EXTRAVERSION hat super funktioniert.

Zwischenzeitlich habe ich auch die .config der ct-Variante auf die neuen Quellen angewandt, doch dann zeigt sich der gleiche Fehler. Mir scheint fast, als wäre diese config vermurkst.

Letzendlich konnte ich einen Kernel backen, mit dem der VDR gelaufen ist, auch die LIRC-Module haben anstandslos getan. Doch nach undefinierbarer Laufzeit stellt sich der folgende Fehler ein:

Code

Losing too many ticks!  
TSC cannot be used as a timesource.  
Possible reasons for this are:  
You're running with Speedstep,  
You don't have DMA enabled for your hard disk (see hdparm),
Incorrect TSC synchronization on an SMP system (see dmesg).
Falling back to a sane timesource now.

DMA meiner Platten war definitiv nicht aktiviert und "hdparm -d1 /dev/hdx" funktioniert bei Kernel 2.6 ja nicht mehr. Irgendwo fand ich, daß man den richtigen Chipsatz einbinden muss, doch irgendwie kam ich dahingehend auf keine Lösung.

Gruß, leppenraub

reibuehl · 4. September 2005

Zitat

64Bit? ne, ne! Muss die Architektur auch bei den 2.6.12.6-Sourcen angeben, sonst läuft da nichts.

Das wundert mich. Musste ich noch nie... komisch???

Wegen des beschriebenen Fehlers "loosing too many ticks" kannst Du mal schauen, ob das deaktivieren des CPU Frequency Scaling (Power management options -> CPU Frequency scaling) hilft. Bei Desktop Rechnern macht das eh nicht so viel sinn.

Wenn Du willst kannst Du mir Deine .config und eine Hardwarebeschreibung (CPU, Mainboard, Chipsatz, etc) ja mal per PM schicken, dann werf ich mal einen Blick drauf.

Gruß,
Reiner.

Kernel 2.6.12 - Compilier- und Konfigurationsprobleme

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema