squeeze Eigenbaukernel (gelöst)

[guennid]

Also, ich habe ein minimalistisches squeeze mit X aufgesetzt. mit dem standard-kernel 2.6.32.5 läuft alles soweit, einschließlich X

Ich hatte einen Eigenbaukernel 2.6.31. Mit dessen config wollte ich mir (auf einem lenny-System) einen aktuelleren bauen (2.6.35.10, vanilla). Das funktioniert nicht: Die Kompilation der Module läuft, soweit ich sehe, problemlos durch, aber das ganze endet regelmäßig mit dieser Fehlermeldung:

Code: Alles auswählen

net/ipv6/netfilter/ip6table_filter.c:113: internal compiler error: Speicherzugriffsfehler
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.3/README.Bugs> for instructions.
make[4]: *** [net/ipv6/netfilter/ip6table_filter.o] Fehler 1
make[3]: *** [net/ipv6/netfilter] Fehler 2
make[2]: *** [net/ipv6] Fehler 2
make[1]: *** [net] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.35.7'
make: *** [debian/stamp/build/kernel] Fehler 2

Der aktuellste kernel, den ich ohne Fehler (unter lenny!) bauen kann, ist 2.6.32.7. Aber der scheint auf dem squeeze-System nur ohne X zu funktionieren. Solange ich auf der konsole bleibe, scheint alles in Ordnung zu sein, sobald ich aber X mit startx starte, kommt zwar noch die gui hoch, einschließlich Mauszeiger, aber die gui ist eingefroren. Nur noch Stecker ziehen geht. Ich habe keine Ahnung, was da los ist. Kompilieren auf dem squeeze-System möchte ich vermeiden, da es sich um Uralt-Hardware (P1, 144 Mb Speicher) handelt, auf der die Kompilation mind. 24 Stunden läuft.

Warum kann ich unter lenny keinen kernel > 2.6.32 kompilieren?
Warum friert X bei Verwendung meines Eigenbaukernels 2.6.32.7 ein?
Würde es Sinn machen, den kernel (2.6.35.10) in einer VM mit squeeze als Gast zu kompilieren?

Grüße, Günther

[rendegast]

Als walkaround könntest Du ipv6 deaktivieren.



Auf kernel.org ist 2.6.35.10 noch nicht richtig aufgeführt,
auch auf dem Mirror de.kernel.org noch nicht zu bekommen,
versuche es daher mit dem 2.6.35.9.

Von welcher config gehst Du aus?
lenny 2.6.26 oder squeeze 2.6.32?

Der 2.6.32-29 (squeeze / lenny-backports) verwendet schon Patches bis hoch zum 2.6.35.


Die Module radeon / ixxx hängen stark mit der Version von Xorg / DRM zusammen,
Xorg...log?

... Uralt-Hardware (P1, 144 Mb Speicher) handelt, auf der die Kompilation mind. 24 Stunden läuft.

distcc, und alle Jobs auf dem entfernten Rechner ausführen.


----------------
Der patch 2.6.35.9 besteht für ip6table_filter.c nur aus einem "printk" -> "print_err".

[guennid]

versuche es daher mit dem 2.6.35.9

Mach ich.

Von welcher config gehst Du aus? lenny 2.6.26 oder squeeze 2.6.32?

Weder noch. Woher die config ursprünglich stammt, weiß ich nicht mehr (wahrscheinlich 2.6.8 )
Sie wurde ursprünglich per make defconfig gebaut, auf den Schleppi angepasst und hat bisher noch mit jedem kernel-upgrade auf dieser hardware funktioniert.

Was mir eben aufgefallen ist:
Mit dem 32er squeeze-standard-kernel richtet udev in /dev/disk die beiden Unterverzeichnisse by-id und by-uuid ein. Darin befinden sich links auf /dev/hda*
Nit dem 35.10er gibt's nur by-id, und das ist leer bis auf einen link auf's CDROM! udev erkennt meine Platten nicht.

Um die Sache schrittweise anzugehen: Man kann unter lenny einen kernel bauen, der für squeeze werkeln soll? (Kompiler-Version?)

Grüße, Günther

[rendegast]

Man kann unter lenny einen kernel bauen, der für squeeze werkeln soll? (Kompiler-Version?)

Ja, die squeeze-kernel sind mit gcc-4.3 gebaut, die 2.6.32-backports auch.
Auch kannst Du den Kernel auf dem neuen System erstellen und dann auf dem alten einspielen,
das benötigt eventuell noch Pakete aus den backports.
(Beim einfachen Betrieb des 2.6.32-bpo auf dem lenny benötige ich aber bis jetzt nur
linux-image, linux-headers, linux-kbuild, linux-base, firmware-linux-free.)
EDIT, sorrie, das "große/schnelle" ist ja das "alte", das "kleine/langsame" das "neue".

Sie wurde ursprünglich per make defconfig gebaut, auf den Schleppi angepasst und hat bisher noch mit jedem kernel-upgrade auf dieser hardware funktioniert.

Trotzdem solltest Du nach einem menuconfig mit dieser config die erstellte Version vergleichen vorher/nachher.

Was mir eben aufgefallen ist:
Mit dem 32er squeeze-standard-kernel richtet udev in /dev/disk die beiden Unterverzeichnisse by-id und by-uuid ein. Darin befinden sich links auf /dev/hda*
Nit dem 35.10er gibt's nur by-id, und das ist leer bis auf einen link auf's CDROM! udev erkennt meine Platten nicht.

Dann verwende die config des backports als neue Vorlage.






-------------------------------------

Code: Alles auswählen

net/ipv6/netfilter/ip6table_filter.c:113: internal compiler error: Speicherzugriffsfehler

Seltsam, da an dieser Stelle nur

Code: Alles auswählen

...
module_init(ip6table_filter_init);
module_exit(ip6table_filter_fini);

Eventuell Probleme beim Herunterladen/Entpacken/Patchen? ZBsp. md5:

10eebcb0178fb4540e2165bfd7efc7ad linux-2.6.34.tar.bz2
a9c6e019fc50b910987ffeec3a1cd742 patch-2.6.35.gz
dc86b0290b19305b5dff9c12cbf23fc5 patch-2.6.35.9.gz

-------------------------------------
Wegen der firmware der vanilla-Kernel (wenn zBsp das radeon-Modul deshalb Probleme machen sollte),
zBsp. kernel-package packt sie nach /lib/firmware/kernelversion/.
(Wobei ich es bis jetzt noch nicht nötig hatte zu prüfen,
ob der jeweilige Kernel das auch verwendet oder nur auf /lib/firmware/ zugreift.)

Aber zumeist identisch:

Code: Alles auswählen

:/lib/firmware$ diff -rq radeon/ 2.6.36/radeon/
Nur in radeon/: CEDAR_me.bin.
Nur in radeon/: CEDAR_pfp.bin.
Nur in radeon/: CEDAR_rlc.bin.
Nur in radeon/: CYPRESS_me.bin.
Nur in radeon/: CYPRESS_pfp.bin.
Nur in radeon/: CYPRESS_rlc.bin.
Nur in radeon/: JUNIPER_me.bin.
Nur in radeon/: JUNIPER_pfp.bin.
Nur in radeon/: JUNIPER_rlc.bin.
Nur in radeon/: R600_rlc.bin.
Nur in radeon/: R700_rlc.bin.
Nur in radeon/: REDWOOD_me.bin.
Nur in radeon/: REDWOOD_pfp.bin.
Nur in radeon/: REDWOOD_rlc.bin.

[guennid]

distcc kannte ich noch nicht. habe mir in der Zwischenzeit einiges angelesen. Aber lohnt der Aufwand, mich da rein zu knien? Das Hin- und Herschieben des Kompilates ist ja kein Problem.

Dann verwende die config des backports als neue Vorlage

Ich nöchte einen möglichst schlanken kernel, z.B. ohne initrd. Wenn ich, wie vorgeschlagen, vorgehe, kann ich doch auch auch gleich beim Standard-Kernel bleiben.
Zu frische hardware dürfte ja kaum das Problem sein

Grüße, Günther

[rendegast]

Ich nöchte einen möglichst schlanken kernel, z.B. ohne initrd.

<->

als neue Vorlage

'make menuconfig'?

kann ich doch auch auch gleich beim Standard-Kernel bleiben.

Wenn er funktioniert?

[guennid]

Sagte ich doch, dass der funktioniert.

Wie kommst du eigentlich auf "firmware"? Da fällt mir noch was auf: Es gibt kein /lib/firmware/2.6.35.10.

Grüße, Günther

[rendegast]

Wie kommst du eigentlich auf "firmware"? Da fällt mir noch was auf: Es gibt kein /lib/firmware/2.6.35.10.

Ich habe ja auch geschrieben, daß kernel-package das erstellt.
Falsche oder fehlende firmware ist ein möglicher Grund für fehlerhaftes Treiberverhalten,
jedoch wird auf Deinem P1 wohl auch keine firmware-benötigende Hardware sein?
ZBsp radeon ab R100 (7000er).



EDIT, sorrie, das "große/schnelle" ist ja das "alte", das "kleine/langsame" das "neue".
Da die kernel 2.6.33 - 36 auf meinem squeeze scheinbar problemlos kompilieren,
ist distcc dann doch die passende Lösung?
Resp.

Würde es Sinn machen, den kernel (2.6.35.10) in einer VM mit squeeze als Gast zu kompilieren?

Wäre ja ein Job, der voll von den Virtualisierungsfunktionen der Hardware des lenny-Systems profitiert (falls vorhanden).



Heruntergeladenen Quellen kontrolliert?
Dateien sind stimmig, zBsp.:
http://git.kernel.org/?p=linux/kernel/g ... /netfilter
http://git.kernel.org/?p=linux/kernel/g ... e_filter.c
?





--------------
Beim Ausgehen von der squeeze-Standardkonfig empfehle ich, CONFIG_DEBUG_INFO abzuschalten:

Code: Alles auswählen

:/boot$ grep -i "debug.*info" conf*
config-2.6.26-2-686-bigmem:# CONFIG_DEBUG_INFO is not set
config-2.6.26-2-xen-686:# CONFIG_DEBUG_INFO is not set
config-2.6.32-5-686-bigmem:CONFIG_DEBUG_INFO=y
config-2.6.32-5-xen-686:CONFIG_DEBUG_INFO=y

(ist beim Bauen ein Speicherfresser, braucht mehr als 2GB Plattenplatz,
da war meine RAM-Disk (Build-Verzeichnis) zuende
(leider funktioniert kernel-package nicht mit einem Build-Verzeichnis))

[guennid]

So, die kernel-sourcen von 2.6.35.9 sind heruntergeladen (lahmes Internet). ich probiere jetzt mal neu zu kompilieren, mit meiner alten alten config. Wie gesagt: ich benötige auf dem Spielzeug eigentlich keinen neueren kernel, ich hätt' gern lediglich einen schlankeren. Und wenn schon kompiliert werden soll, warum dann nicht die spurcen eines neueren nehmen.

Die Prüfsummen werde ich auch noch checken. Habe aber wenig Hoffnung, dass da ein Fehler zu finden wäre. Ich hab das jetzt schon mehrfach mit verschiedenen sourcen und verschiedenen lenny-Systemen gehabt, dass die Kompilation neuerer kernel (> 2.6.32.7) mit Fehlern abbrach.

Bevor wir hier noch länger im Nebel stochern: Kann es nicht sein, dass das Hauptproblem wieder mal mit udev zusammenhängt: Keine Platten-Devices eingerichtet beim selbstgebauten 2.6.32.7.

Grüße Günther

[detix]

Für einen schlankeren Kernel solltest du auch localmodconfig nicht außer Acht lassen:
viewtopic.php?f=33&t=116004
oder hier:
http://www.linux-community.de/Internal/User-Blogs...

[guennid]

So, die Kompilierabbrüche hab ich jetzt im Griff. Ich wusste doch, da war was, und das hatten wir schon mal, rendegast, und noch nicht mal vor allzu langer Zeit! Aber ich hab's einfach wieder vergessen. Ich habe dem lenny jetzt kernel-package aus squeeze verpasst. Jetzt sollte an dieser Front Ruhe sein. Aber warum richtet udev bei dem Eigenbaukernel keine Plattendevices mehr ein. Da fehlt was im kernel, aber was.

Ich bin bei meinen Recherchen auf etwas bei gentoo gestoßen, weiß aber nicht, ob das weiter hilft. Ein erster Versuch, damit den kernel zu konfigurieren führte zu einem Hänger beim Booten.

[edit:]
So, die Platte ist mit allen Partitionen wieder da. Der gentoo-Vorschlag:

Code: Alles auswählen

< > ATA/ATAPI/MFM/RLL support  --->

ist für debian wohl nicht angemessen (habe ich das falsch verstanden?). Ich habe den Eintrag wieder aktiviert, und kann jetzt auf die Platten zugreifen.

Das Problem, das X einfriert, besteht nach wie vor.

Grüße, Günther

[guennid]

Muss das nochmal hochspülen. Mit dem squeeze-Standard-Kernel 2.6.32.5 läuft mein X, ohne dass ich Fehler bemerke, mit meinem Eigenbaukernel 2.6.35.9 (mit dessen Ausgangs-config ich bisher [sarge bis lenny] keine Probleme mit X hatte) friert X beim Start sofort ein. Nichts geht mehr.

Was hat sich da in der kernel-Konfiugration, den xserver betreffend, zwischen lenny und squeeze geändert? Welche Module des standard-kernels könnte ich auf Vorhandensein in meinem eigenen prüfen?

Grüße, Günther

[rendegast]

Das ist müßig,
ein schrittweises Vorgehen.

Verwende die config des 2.6.32-5 -> menuconfig -> Änderungen auftetreten? -> kompilieren -> testen ->funktioniert?
Dann schrittweise die config des 2.6.35 zurückbauen in Richtung der config Deines 'sarge-lenny',
und immer wieder vergleichen->kompilieren->testen.
(Also ausgehend vom positiv bis zum Fehler)

Stelle die config Deines 'sarge-lenny' doch mal nach nopaste.
In 2 Versionen: bevor und nachdem sie mal mit menuconfig des 2.6.35.9 abgespeichert wurde.

[guennid]

Ist das nicht ZU umständlich bei den Tausenden Möglichkeiten? Wenn es, so wie ich es vorhabe, nicht sinnvoll sein sollte, dann wäre es doch wahrscheinlich einfacher, wieder mit defconfig anzufangen. Und das wäre mühsam genug, Ich weiß doch beispielsweise nicht mehr wie ich vor Jahren die initrd losgeworden bin.

Bei dem alten Schätzchen ist ja nicht mehr als Platte, GraKa, CDROM, PCMCIA.

Grüße, Günther

[rendegast]

Das systematische Vorgehen habe ich Dir aufgezeigt.

Ich weiß doch beispielsweise nicht mehr wie ich vor Jahren die initrd losgeworden bin.

Code: Alles auswählen

$ cat /boot/config-2.6.26-2-686-bigmem | grep -i initrd
CONFIG_BLK_DEV_INITRD=y

Auf "is not set" setzen, und einmal 'make menuconfig'.

[guennid]

CONFIG_BLK_DEV_INITRD

"is not set" wird nicht ausreichen, Die root-Partition muss fest in den kernel, zumindest war das mal so. Was sonst noch zu beachten ist, weiß ich jetzt nicht mehr. Aber das ist jetzt auch nicht so wichtig.

Ich stelle mal drei configs nach nopaste: eine 2.6.26er Eigenbau deren kernel läuft mit lenny, die des 2.6.32.5er squeeze-Standard und die des zuletzt kompilierten 2.6.35.9er Eigenbau, abgeleitet vom 2.6.26.3er, mit dem in squeeze alles bis auf den Xserver arbeitet.

Ein xorg.0.log vom eingefrorenen X (hoffentlich) habe ich auch noch. (Ich hatte das log komplett geleert, den Schleppi neu gebootet und x gestartet.) Die letzten Zeilen:

Code: Alles auswählen

SELinux: Disabled on system, not enabling in X server
(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
(EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
(EE) GLX: could not load software renderer
(II) GLX: no usable GL providers found for screen 0
(II) config/udev: Adding input device PS/2 Generic Mouse (/dev/input/mouse0)
(II) No input driver/identifier specified (ignoring)

[cosmac]

hi,

der (EE)AIGLX-Fehler könnte daran liegen, dass libgl1-mesa-dri nicht installiert ist. Aber X sollte trotzdem laufen.

Kann es sein, dass beim Eigenbau-Kernel der udevd nicht gestartet wird (bzw. abstürzt), aber beim Standard-Kernel läuft? Dann wäre das der Unterschied, jedenfalls für ein X ohne xorg.conf. Oder hast du die Treiber "kbd" und "mouse" jetzt in der xorg.conf drin? Dann hab' ich nichts gesagt.

[guennid]

Kann es sein, dass beim Eigenbau-Kernel der udevd nicht gestartet wird (bzw. abstürzt)

Ich trau mich das ja hier nicht laut zu sagen, sonst krieg ich wieder eins auf die Mütze , aber das ist meine Vermutung von Anfang an. Wie prüf ich das?

Grüße, Günther

[edit:] xserver-*-mouse und *-kbd sind nicht installiert. Das X läuft z.Z. ohne xorg.conf (wenn's läuft!)

[cosmac]

Code: Alles auswählen

ps ax | grep udev

oder

Code: Alles auswählen

pstree

[guennid]

Die Ausgaben von ps ax sind im Wesentlichen identisch:

2.6.32.5 (X läuft):

Code: Alles auswählen

  192 ?        S<s    0:01 udevd --daemon
  763 ?        S<     0:00 udevd --daemon
  766 ?        S<     0:00 udevd --daemon

2.6.35.9 (X läuft nicht):

Code: Alles auswählen

  945 ?        S<s    0:04 udevd --daemon
 1460 ?        S<     0:00 udevd --daemon
 1461 ?        S<     0:00 udevd --daemon

aber ich kenn das nicht.

pstree ist nicht vorhanden.


Grüße, Günther

[cosmac]

naja, immerhin läuft er. pstree macht ungefähr dasselbe wie ps ax, gehört also nicht auf ein spartanisches System

In der Eigenbau-2.6.35.9-Kernel-config ist mir eins aufgefallen: "CONFIG_INPUT_EVDEV ist not set", das wäre einen Versuch wert, ich glaube, das wird für alle Eingabegeräte unter X gebraucht.

[guennid]

Bingo, Herr cosmac!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!, war 'ne schwere Geburt!!!!


Wenn du mal in die Marburger Gegend kommst, geb ich ein Bier aus!

Warum ging das bis lenny ohne?

Und da habakug uns jetzt alle auffordert, als beta-Tester für squeeze zu fungieren , wäre vielleicht anzuraten, dass das bei "make oldconfig" eingepflegt wird.

Wenn du noch Zeit hättest, mal über die neue config zu schauen. wäre ich sehr dankbar. Ich hab' da einiges wegen des ata/sata-Gewürges an in "device drivers" rumgespielt. Wäre schön, wenn ich da Überflüssiges wieder entfernen könnte.

Grüße, Günther

[cosmac]

Warum ging das bis lenny ohne?

weil X früher eigene Treiber verwendet hat. Das war ursprünglich eine praktische Lösung, aber wenn man das System als ganzes sieht, ist es sauberer, alle Treiber im Kernel zu haben. Schön langsam arbeitet man darauf hin.

Und da habakug uns jetzt alle auffordert, als beta-Tester für squeeze zu fungieren , wäre vielleicht anzuraten, dass das bei "make oldconfig" eingepflegt wird.

keine Ahnung, ob "oldconfig" für solche Anpassungen gedacht ist. Ich glaube eher nicht, weil dann auch für Server-Kernel plötzlich dieses Modul gebaut würde.

ata/sata-Gewürge

meinten Sie: "wunderbare neue libata"?
warum hast du die denn jetzt rausgenommen (CONFIG_ATA is not set), hab ich die configs verwechselt? O.K., wenn es läuft, was will man mehr, aber sogar Debian hat den Umstieg schon vor einiger Zeit geschafft

Das muss ich mir nochmal viel genauer anschauen. Dazu noch eine Frage: hast du echte SCSI-Geräte?

Wenn du mal in die Marburger Gegend kommst, geb ich ein Bier aus!

Danke, gerne, aber hab ich noch nicht verdient

[guennid]

keine Ahnung, ob "oldconfig" für solche Anpassungen gedacht ist. Ich glaube eher nicht, weil dann auch für Server-Kernel plötzlich dieses Modul gebaut würde.

Jeder, der den Eigenbaukernel seines Desktop-Systems von lenny auf squeeze updaten will, wird in diese Falle laufen.

warum hast du die denn jetzt rausgenommen (CONFIG_ATA is not set), hab ich die configs verwechselt?

Nö, du nicht, aber ich. Die hier sollte die aktuelle sein (CONFIG_ATA=y). Ich werd noch völlig meschugge bei dieser Kompilierorgie.

Was das ata/sata Gewürge angeht. Schau dir mal den gentoo-link an. Da wird empfohlen

Code: Alles auswählen

< > ATA/ATAPI/MFM/RLL support (DEPRECATED)  --->

Und wenn ich nicht schon ganz wirr im Kopf bin, war das einer der Gründe, warum es bei mir nicht funktionierte, ich habe das wieder aktiviert, obwohl ich nach deren Empfehlung auch unter

Code: Alles auswählen

<*> Serial ATA and Parallel ATA drivers  --->

einiges aktiviert habe.

Die ide-Platte ist bei mir nach wie vor hda.

Grüße, Günther