selbstkompilierter Kernel 2.6.20, Kernel panic

[langhans]

Hallo,

zur Zeit habe ich den vorkompilierten Kernel 2.6.18-3-686 am laufen. Dieser kennt aber meine Netzwerkkarte RTL 8169 nicht. Deshalb habe ich mich entschlossen, einen neuen Kernel zu kompilieren.
Habe mir die Quellen des 2.6.20 er Kernels geholt, und nach einigem Zeitaufwand und vielen Versuchen endlich übersetzt bekommen (war bisher noch nie so dramatisch wie diesesmal).
Wenn ich jetzt den neuen Kernel boote bekomme ich folgende Fehlermeldung:

Code: Alles auswählen

...
VFS: Cannot open root device "sda1" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Daraufhin habe ich in /boot/grub/menu.lst nachgeschaut. Da steht folgendes:

Code: Alles auswählen

title		Debian GNU/Linux, kernel 2.6.20
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.20 root=/dev/sda1 ro 
savedefault

title		Debian GNU/Linux, kernel 2.6.18-3-686
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.18-3-686 root=/dev/sda1 ro 
initrd		/boot/initrd.img-2.6.18-3-686
savedefault

Beim 2.6.18 er Kernel ist auch /dev/sda1 angegeben, da funktioniert es. Warum beim 2.6.20 er Kernel nicht? Was habe ich falsch gemacht?

Mein Prozessor ist ein Core 2 Duo, die Festplatte eine SATA-Disk. Übrigens benutze ich Grub das erste mal; habe früher immer mit lilo gearbeitet.

Gruß langhans

[nepos]

Hast du denn den neuen Kernel korrekt gebaut? Sprich, Treiber für den Plattencontroller usw fest im Kernel?

[langhans]

Die Kernelconfiguration wird auch immer komplizierter und umfangreicher. Verstanden habe ich nicht alles. Folgendes habe ich eingestellt:

Code: Alles auswählen

# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m

...
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_TGT=m
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

...
#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=y
CONFIG_SATA_AHCI=m
CONFIG_SATA_VIA=y

Gibt es denn zu den fertig kompilierten Kernels auch die .config - Files? Da funktioniert schonmal was und man kann mit den Einstellungen spielen.

[nepos]

Also, deinen Angaben oben nach hast du die Treiber als Module gebaut. Damit das klappt, müsstest du dir eine entsprechende initrd bauen, wie es auch für die Debian-Kernels der Fall ist. Oder du baust wie gesagt die Treiber fest in den Kernel, dann erübrigt sich das...

Die Debian-Kernel-Pakete legen normal unter /boot/ ihre Konfigurationsfiles ab, mit denen sie gebaut wurden. Für den 2.6.18er Kernel sollte dies /boot/config-2.6.18 sein. Das kannst du als Basis für den neuen Kernel nutzen.
Allerdings musst du hier aufpassen, da in den neuesten 2.6er Kernels einiges geändert wurde und die Konfiguration nicht 1:1 übernehmbar ist.

[langhans]

Hi nepos,
ich habe jetzt diese config Datei als Vorlage genommen, und einige Module fest eingebunden. Der Fehler ist aber immer noch der gleiche.
Aus Verzweiflung habe ich auch probiert, die Quellen des 2.6.18 er Kernels mit den Einstellungen der /boot/config-2.6.18 (ohne Änderungen) zu übersetzen, dies klappt auch nicht. Die Übersetzung wird gleich abgebrochen mit der Meldung

Code: Alles auswählen

  CC      init/do_mounts.o
In file included from init/do_mounts.c:12:
include/linux/nfs_fs.h: In function ‘nfs_caches_unstable’:
include/linux/nfs_fs.h:230: error: ‘struct nfs_inode’ has no member named ‘data_updates’
make[2]: *** [init/do_mounts.o] Fehler 1
make[1]: *** [init] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.18.3'

Auch schmiert mir mein Rechner manchmal beim kompilieren ab, oder der Compiler bringt ne Fehlermeldung, die jedoch nicht mehr kommt wenn ich neu boote und nochmal übersetze. Komme mir schon langsam vor wie bei M$.
Scheinbar habe ich ein riesen Brett vorm Kopf.

[uljanow]

Welche gcc-version benutzt du und wie baust du den kernel?

[langhans]

Betriebssystem: etch
Compiler: gcc 4.1

Den Kernel baue ich so:

Code: Alles auswählen

make xconfig
make-kpkg kernel_image --revision=angepasst.1
dpkg --install linux-image-2.6.20_angepasst.1_i386.deb

Bei den 2.4 er Kernels hat das immer einwandfrei geklappt.

[debdog]

Hi langhans,

also mal abgesehen vom Kernelbau, Du bist sicher, daß die RTL 8169 nicht mit dem 2.16.18 dabei ist? Welche Meldung bringt denn ein modprobe r8169?

Habe erst vor kurzem den Kernel in der 2.6.16, .18 und .20 Version gebaut, aber die Realtek-Chips haben nie Probleme gemacht. Trotzdem bin ich an (potentiellen) Problemen diesbezüglich interessiert, man weiss ja nie was noch so alles auf einen zukommt

Grüsse debdog

[langhans]

Hallo debdog,
habe eine Pause gemacht mit dem Kernelübersetzen, da ich nicht weitergekommen bin.

Inzwischen habe ich das Modul r8196 in die /etc/modules eingetragen. Es wurde wohl immer zu spät geladen. Mit der Netzwerkverbindung klappt es jetzt einigermaßen. Manchmal kann ich nach dem booten nicht ins Internet gehen. Nachdem ich ein "/etc/init.d/networking restart" gemacht habe geht es wieder.

Das Übersetzen der Kernelquelllen krieg ich aber immer noch nicht hin. Ich habe nun probiert, die einzelnen Schritte, wie im debiananwenderhandbuch angegeben, auszuführen. Beim "make modules" bekomme ich folgende Fehlermeldung

Code: Alles auswählen

  CC [M]  fs/ntfs/aops.o
  CC [M]  fs/ntfs/attrib.o
fs/ntfs/attrib.c: In function ‘ntfs_attr_vcn_to_lcn_nolock’:
fs/ntfs/attrib.c:345: internal compiler error: Speicherzugriffsfehler
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.
The bug is not reproducible, so it is likely a hardware or OS problem.
make[2]: *** [fs/ntfs/attrib.o] Fehler 1
make[1]: *** [fs/ntfs] Fehler 2
make: *** [fs] Fehler 2

Ach ja, ich habe die Quellen vom 2.6.20 er Kernel übersetzt.

Gruß
langhans

[brummer]

moin
vieleicht solltest du den 2.6.20 auch mit initrd erstellen

Code: Alles auswählen

fakeroot make-kpkg kernel_image -initrd --revision=angepasst.1 kernel_image
fakeroot make-kpkg kernel_image -initrd --revision=angepasst.1 kernel_headers

gruß brummer

[gms]

Das ist ein "internal compiler error" oder anders ausgedrückt: Wenn das Problem reproduzierbar ist, ist es höchst wahrscheinlich ein Bug im gcc, wenn nicht, dann ist das ein Hardware- (z.B.RAM) oder OS Problem

fs/ntfs/attrib.c:345: internal compiler error: Speicherzugriffsfehler

Wenn das Problem also reproduzierbar ist, dann gibt es folgende potentielle Workarounds:
1) andere GCC Version verwenden
2) ntfs Support im Kernel ausschalten ( der Fehler tritt beim erstellen vom ntfs auf )
3) mit Compilersettings herumprobieren und hoffen den Fehler zu beseitigen
4) einen Bugreport abschicken und auf die Fehlerbehebung (oder zumindest Fehleranalyse) warten, siehe dazu:

Code: Alles auswählen

Please submit a full bug report, 
with preprocessed source if appropriate. 
See <URL:http://gcc.gnu.org/bugs.html> for instructions. 
For Debian GNU/Linux specific bug reporting instructions, 
see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>. 
The bug is not reproducible, so it is likely a hardware or OS problem.

@brummer
mit der initrd hat das Problem nichts zu tun, die kommt erst später ins Spiel

Gruß
gms

[brummer]

hallo gms
du hast ja recht, allerdings ist später manchmal früher

Habe mir die Quellen des 2.6.20 er Kernels geholt, und nach einigem Zeitaufwand und vielen Versuchen endlich übersetzt bekommen (war bisher noch nie so dramatisch wie diesesmal).
Wenn ich jetzt den neuen Kernel boote bekomme ich folgende Fehlermeldung:

s/ntfs/attrib.c:345: internal compiler error: Speicherzugriffsfehler

diese fehler treten auch bei falschen .config daten auf, ich hab mich mit diesem "FEHLER" auch lange rumgeschlagen und soweit ich weiß läuft der 2.6.20 nich mehr ohne initrd, daher meine vermutung das langhans den kernel der zuerst kompiliert hat hätte nutzen können, wenn er mit initrd erstellt worden währe.


gruß brummer

[nepos]

Wenn du mehr mit NTFS machen willst und Etch nutzt, dann würde ich den Kram im Kernel ganz lassen und mir NTFS-3G installieren.

[gms]

s/ntfs/attrib.c:345: internal compiler error: Speicherzugriffsfehler

diese fehler treten auch bei falschen .config daten auf

falsch, die falschen .config Daten können zwar auch zu Fehlern führen, wenn diese aber zu einem "internal compier" Fehler führen, dann ist das ein Compiler-Bug

ich hab mich mit diesem "FEHLER" auch lange rumgeschlagen und soweit ich weiß läuft der 2.6.20 nich mehr ohne initrd

falsch, auch der 2.6.20 kann, wenn er richtig konfiguriert wurde, ohne initrd booten.

daher meine vermutung das langhans den kernel der zuerst kompiliert hat hätte nutzen können, wenn er mit initrd erstellt worden währe.

ist zwar eine gewagte Vermutung, aber einen Versuch wäre es sicherlich wert

Gruß
gms

[langhans]

Erstmal danke für die vielen Antworten.
Ich habe nun versucht, den Kernel mit

Code: Alles auswählen

fakeroot make-kpkg kernel_image --initrd --revision=angepasst.1 kernel_image

zu übersetzen, habe aber wieder eine Fehlermeldung bekommen:

Code: Alles auswählen

  CC [M]  drivers/atm/firestream.o
  CC [M]  drivers/atm/lanai.o
  CC [M]  drivers/atm/he.o
*** glibc detected *** free(): invalid pointer: 0x086f1790 ***
drivers/atm/he.c: In function ‘he_start’:
drivers/atm/he.c:1020: internal compiler error: Abgebrochen
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.
The bug is not reproducible, so it is likely a hardware or OS problem.
make[3]: *** [drivers/atm/he.o] Fehler 1
make[2]: *** [drivers/atm] Fehler 2
make[1]: *** [drivers] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.20'
make: *** [debian/stamp-build-kernel] Fehler 2

Es scheint wirklich ein Fehler im gcc zu sein. Dann müßte dieser Fehler aber auch bei anderen auftreten, denn ich bin sicherlich nicht der Einzige, der den Kernel 2.6.20 unter etch übersetzt. Heute morgen habe ich auch mein OS aktualisiert, um sicher zu gehen, daß u.a. der neue gcc installiert ist.
Gruß
langhans

[gms]

Hast du die jetzt an der Konfiguration etwas verändert ?
a) Wenn ja, dann überprüfe bitte, ob der Fehler nach einem "make-kpkg clean" und einem neuerichen Start von "make-kpkg --initrd --revision=angepasst.1 kernel_image" wieder an der gleichen Stelle auftritt:

Code: Alles auswählen

drivers/atm/he.c:1020: internal compiler error: Abgebrochen

also in der Datei "drivers/atm/he.c" und der Zeile 1020

b) Wenn nein, dann ist der erste Fehler "fs/ntfs/attrib.c:345: internal compiler error: Speicherzugriffsfehler" nicht reproduzierbar und du hast wahrscheinlich wirklich ein Hardware Problem ( z.B defektes RAM )

Gruß
gms

[langhans]

@gms:
ein fehlerhaftes RAM habe ich auch schon vermutet, zumal die Übersetzung wirklich jedesmal an einer anderen Stelle hängen bleibt. Macht man kein "make clean" vorher, übersetzt er weiter und nach ca. 7 - 8 maliger Unterbrechnung hat man dann einen fertigen kernel. Daß der jetzt nicht bootet liegt wahrscheinlich an falschen config - Einstellungen.
Eventuell liegts auch an der Festplatte, da der neue Kernel keine /dev/sda1 findet. Ich hatte aber auch schonmal das Problem, daß der Rechner (nicht der aktuelle) immer wieder mal hängen blieb und nach langwieriger Fehlersuche sich herausstellte, daß das Netzteil ab und zu Aussetzer hatte.
Nun werde ich mich an die Hardware machen und hoffe auf einen baldigen Erfolg. Ich berichte dann wenn ich den Fehler gefunden habe.

Nochmal Danke.
Gruß
langhans

[brummer]

moin

ich hab ja herzlich gelacht als ich heute morgen diesen tread anschaute.

brummer hat folgendes geschrieben:

Zitat:
s/ntfs/attrib.c:345: internal compiler error: Speicherzugriffsfehler

diese fehler treten auch bei falschen .config daten auf

falsch, die falschen .config Daten können zwar auch zu Fehlern führen, wenn diese aber zu einem "internal compier" Fehler führen, dann ist das ein Compiler-Bug

nun, dann hab ich wohl meine Hardware wie auch den compiler repariert, indem ich einen anderen kernel verwendet habe. Mir war es nicht möglich den 2.6.20-rt5 wie auch den rt8 unter einem 2.6.20-rc2-rt3 kernel zu compilieren. Ich habe genau diese fehlermeldungen erhalten wie von langhans beschrieben. Keine probs sind bei gleicher .config unter einem 2.6.19.1-rt11 aufgetreten. Es lag augenscheinlich an einer fehlerhaften config des verwendeteten Kernels. Aber es is ja trotzdem ne gute iddee mal den staub aus dem lüfter zu pusten.

brummer hat folgendes geschrieben:

ich hab mich mit diesem "FEHLER" auch lange rumgeschlagen und soweit ich weiß läuft der 2.6.20 nich mehr ohne initrd

falsch, auch der 2.6.20 kann, wenn er richtig konfiguriert wurde, ohne initrd booten.

nun diese .config würde mich schon interessieren, der 2.6.20 mit SATA suport und ohne initrd
vieleicht kannst du die ja mal hier posten, ich bin ja am lernen was linux angeht und bin für neue Ideen aufgeschlossen

Macht man kein "make clean" vorher, übersetzt er weiter und nach ca. 7 - 8 maliger Unterbrechnung hat man dann einen fertigen kernel.

langhans hast du den jetzt verwendeten kernel auch so erstellt ? Ich meine man kann schon die ein oder andere warnung beim build ignorieren, aber soweit einen abruch zu ignorieren würd ich nich gehen.

brummer

[gms]

nun diese .config würde mich schon interessieren, der 2.6.20 mit SATA suport und ohne initrd
vieleicht kannst du die ja mal hier posten, ich bin ja am lernen was linux angeht und bin für neue Ideen aufgeschlossen

von deiner Aufgeschlossenheit ist nicht viel zu bemerken und dein fehlendes Verständnis für diese Zusammenhänge ist auch offensichtlich:

Mir war es nicht möglich den 2.6.20-rt5 wie auch den rt8 unter einem 2.6.20-rc2-rt3 kernel zu compilieren. Ich habe genau diese fehlermeldungen erhalten wie von langhans beschrieben. Keine probs sind bei gleicher .config unter einem 2.6.19.1-rt11 aufgetreten. Es lag augenscheinlich an einer fehlerhaften config des verwendeteten Kernels.

aber mach dich nur weiter lustig (über mich), das stört mich nicht wirklich.

Deinen Wissensdurst nach meiner .config möchte ich aber stillen:
2.6.20: http://nopaste.debianforum.de/5200
2-6-20-rc5: http://nopaste.debianforum.de/5201

Leider habe ich auf diesem Firmen-PC nicht den RT Patch eingespielt, auf meinem privaten Laptop habe ich aber auch den 2.6.20-rc6 mit dem rt-Patch (und ohne fehlerhafter .config ) bauen können:
http://www.debianforum.de/forum/viewtop ... t=realtime
( die einzigen Probleme waren auf den properitären nvidia-Treiber zurückzuführen )

Gruß
gms

[brummer]

moin gms

entschuldige bitte wenn ich den eindruck erweckt habe mich über dich lustig gemacht zu haben, das war nicht meine absicht, ich wollte lediglich daraufhinweisen das nicht umbedingt compiler oder hardware für diese meldung verantwortlich sein müssen. Ich wollte dir auch deine Kompetenz nicht absprechen, mit deiner .config hab ich wieder was gelernt, das ist mein ziel, welches ich aber ohne hinterfragung sicher nicht erreiche. vieleicht kann ja auch langhans was mit deiner .config anfangen.
trotz allem sehe ich die sache vieleicht nicht so ernst wie du und bewahre mir ein schmunzeln auch nach deinem letzten post.

denne brummer

[gms]

ich wollte lediglich daraufhinweisen das nicht umbedingt compiler oder hardware für diese meldung verantwortlich sein müssen.

ein Compiler übersetzt Sourcecode in Assemblercode, der anschließend vom Assembler in Maschinencode umgewandelt werden kann.
Je nachdem welche Kernelsourcen übersetzt werden, oder mit welcher .config diese Kernelsourcen übersetzt werden, erhält der Compiler (vom Precompiler) einen anderen Input. Der Compiler sollte aber mit jedem beliebigen Input zurechtkommen und im Fehlerfall eine sprechende Fehlermeldung ( mit der Zeilennummer und Fehlerbeschreibung ) zurückliefern.
Natürlich kann ein Hardwareproblem (RAM), oder ein OS-Bug, das Verhalten des Compilers beeinflußen und einen "internal-compiler" Fehler hervorrufen.
Wird das Verhalten aber nicht von außen negativ(!) beeinflußt, dann handelt es sich bei dem "internal-compiler" Fehler um einen Compiler-Bug. Diese Fehler sind mit dem gleichen(!) Input ( Precompiler-Output ) immer reproduzierbar.

Im Umkehrschluß, wenn der Fehler (mit gleichem Input) nicht reproduzierbar ist ( wie bei "langhans" ), dann muß der Compiler von außen negativ beeinflußt worden sein und es ist von einem Hardwareproblem oder OS-Bug auszugehen.

Ändere ich das Verhalten des Compilers, indem ich ihm einen anderen Input liefere ( andere Kernelversion, oder andere .config ) so sagt das selbstverständlich überhaupt nichts über diesen Fehler aus!

dieser Hinweis ist dir also nicht geglückt:

ich wollte lediglich daraufhinweisen das nicht umbedingt compiler oder hardware für diese meldung verantwortlich sein müssen.

und repariert hast du auch nichts:

nun, dann hab ich wohl meine Hardware wie auch den compiler repariert, indem ich einen anderen kernel verwendet habe.

du hast lediglich einen Workaround für DEIN Problem gefunden

trotz allem sehe ich die sache vieleicht nicht so ernst wie du und bewahre mir ein schmunzeln auch nach deinem letzten post.

mir geht es hier um das gepostete Problem, welches nicht, nur weil der Fehler vielleicht mit einer anderen .config nicht auftritt, als gelöst betrachtet werden sollte.

Gruß
gms

[brummer]

auch mir gehts um die lösung, nicht um einen Workaround.

dieser Hinweis ist dir also nicht geglückt:
Keine probs sind bei gleicher .config unter einem 2.6.19.1-rt11 aufgetreten.
Es lag augenscheinlich an einer fehlerhaften config des verwendeteten Kernels.

oder von einem OS-Bug auszugehen, darauf wollte ich hinaus.
wenn ich dann noch lese wie langhans mit einem compilerabbruch umgeht, drängt sich diese vermutung ja auf. (sorry langhans, aber wie erwähnt würd ich nich so weit gehen und das ignorieren und einfach weitermachen, hierbei können dir fehlerquellen entsehen die du nie mehr in den griff bekommst)

gruß brummer

[gms]

oder von einem OS-Bug auszugehen, darauf wollte ich hinaus.

sind wir jetzt erstmalig einer Meinung ?
Aber nichts anderes habe ich doch in meinem ersten Posting hier behauptet:

Das ist ein "internal compiler error" oder anders ausgedrückt: Wenn das Problem reproduzierbar ist, ist es höchst wahrscheinlich ein Bug im gcc, wenn nicht, dann ist das ein Hardware- (z.B.RAM) oder OS Problem

Sogar bevor du mit der "falschen .config" und der Behauptung, der 2.6.20 funkt nicht mehr ohne initrd, angefangen hast:

diese fehler treten auch bei falschen .config daten auf, ich hab mich mit diesem "FEHLER" auch lange rumgeschlagen und soweit ich weiß läuft der 2.6.20 nich mehr ohne initrd

Mit der ".config" entscheidest du übrigens nur, welche Kernel-Features (und damit auch welche Kernel-Bugs) in den erstellten Kernel ( inklusive Module ) hinein kommen und welche nicht. Eine "falsche .config" gibt es daher eigentlich nur in dem Sinn, daß du zuwenig oder zuviele Features einbaust. Solange du nämlich nicht weist, welches Feature diesen Kernel-Bug auslöst, wirst du Probleme bekommen, beim Erstellen einer "richtigen .config"

Du hattest auch, im Gegensatz zu "langhans", deine Problem mit einem RC Kernel, der noch dazu mit einem höchst experimentellen rt-Patch gepatcht war, der sich oft auch täglich ändert. Diese "Augenscheinlichkeit" ist daher auch nicht wirklich nachvollziehbar:

Es lag augenscheinlich an einer fehlerhaften config des verwendeteten Kernels.

Gruß
gms

[langhans]

@brummer

langhans hast du den jetzt verwendeten kernel auch so erstellt ? Ich meine man kann schon die ein oder andere warnung beim build ignorieren, aber soweit einen abruch zu ignorieren würd ich nich gehen.

wenn ich dann noch lese wie langhans mit einem compilerabbruch umgeht, drängt sich diese vermutung ja auf. (sorry langhans, aber wie erwähnt würd ich nich so weit gehen und das ignorieren und einfach weitermachen, hierbei können dir fehlerquellen entsehen die du nie mehr in den griff bekommst)

Den jetzigen Kernel habe ich nicht selbst erstellt, ging ja nicht. Keine Angst brummer, normalerweise ignoriere ich auch keinen Abbruch, ich wollte aber mal sehen, was dabei heraus kommt.

Habe am Wochenende die Speicherchips überprüft; da steckten 2 Riegel mit jeweils 1GB DDR II drin. Habe nur einen dringelassen, neu gebootet und den Kernel übersetzt; und das für jeden Riegel getrennt. Mit keinem RAM funktionierte der Compilerdurchlauf. Die .config-Datei habe ich dazu natürlich nicht verändert.
Dabei habe ich entdeckt, daß auf meinem Mainboard auch noch Steckplätze für DDR I - Speicherriegel drauf sind. In diese habe ich das RAM aus meinem alten Rechner reingesteckt. Danach konnte ich den Kernel problemlos übersetzen und booten.
Während ich dies schreibe läuft der Rechner mit dem neu übersetzten Kernel 2.6.20. Die hänger, die mein Rechner in letzter Zeit hatte treten auch nicht mehr auf.
Das war wirklich ein Fehler am RAM, obwohl diese Chips neu waren. Vielleicht vertragen diese sich auch nicht mit dem Mainboard; im Handbuch dazu steht aber nichts.
Jetzt kann ich mich endlich dran machen, den Kernel an meine Hardware anzupassen.
Danke an das Forum für die informative Diskussion.
Gruß langhans

[mikelm]

Hallo,

ich weiß ja nicht wie der Stand beim Kernelbauen bei euch ist. Ich hatte mir auch den 2.6.20 übersetzt. Mit oldconfig aus dem 2.6.27 die alten Werte übernommen. Auch kernelpanic mit der gleichen Fehlermeldung. Die SATA Treiber (hier Nvidia) waren als Modul drin und nicht fest einkompiliert.
Wurde wohl falsch übernommen. Jetzt läufts aber, auch ohne initrd.

Michael