Verständnisfrage zur Variiable EXTRAVERSION

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
Benutzeravatar
Pix
Beiträge: 275
Registriert: 31.01.2003 14:22:21

Verständnisfrage zur Variiable EXTRAVERSION

Beitrag von Pix » 07.05.2004 11:50:21

Hallo,

es gibt die Variable EXTRAVERSION im Makefile. Mit dieser Variable kann sich der (selbe) Kernel in verschiedenen Versionen verwalten.

Nach einem "make modules_install" findet man im Verzeichnis /lib/modules die Module zum entsprechenen Kernel.
So weit so gut.

Meine Fragen:
1.
Hat die Variable direkten Einfluss auf die Kernelerstellung selbst?
Meines Erachtens geht es doch nur darum, dass der Kernel die entsprechenden Module unter /lib/modules/2.4.x-xxx findet. Aber der Kernel selbst, bleibt doch von der Varible völlig unbeeinflusst.
Richtig?

2.
Wie findet der Kernel seine entsprechenden Module aus dem Verzeichnis /lib/modules/2.4.x-xxx heraus?

3.
Welchen Einfluss bzw. welche Rolle spielt die Datei modules.conf dabei?
In dieser Datei werden doch nur die Parameter für die Module festgelegt, aber mehr nicht.
Anmerkung: bei mir wird diese Datei sowieso nicht ausgewertet.
Bei einer neuen Kernelerstellung bzw. Modulerstellung bleibt diese Datei völlig unangetastet.
Warum?

Hintergrund:
die Meldung 'unresolved sysmbols'
Das heisst ja, dass der Kernel seine entspr. Module nicht finden kann.
Aber warum?

Irgendwie ist das 'Rad' bei mir nicht rund. Bruchstücke was die einzelnen Teile machen sind klar, aber das Verständnis für das grosse Ganze fehlt.

Kann mir jemand auf die Spünge helfen?

Vielen Dank Dirk

Benutzeravatar
zyta2k
Beiträge: 2446
Registriert: 14.03.2003 09:18:00
Kontaktdaten:

Re: Verständnisfrage zur Variiable EXTRAVERSION

Beitrag von zyta2k » 07.05.2004 15:40:18

Pix hat geschrieben: Hintergrund:
die Meldung 'unresolved sysmbols'
Das heisst ja, dass der Kernel seine entspr. Module nicht finden kann.
Aber warum?

Code: Alles auswählen

depmod -ae 
hast du /lib/modules/kernel-foo/ gelöscht, vor dem make modules_install ? Drüber installieren ist nicht immer okey ;)

/boot/vmlinuz auch durch die neue Version ersetzt ?

Benutzeravatar
sebas
Beiträge: 419
Registriert: 15.01.2004 19:02:29
Wohnort: Nijmegen / NL
Kontaktdaten:

Re: Verständnisfrage zur Variiable EXTRAVERSION

Beitrag von sebas » 07.05.2004 15:43:21

Pix hat geschrieben:Hallo,
1. Hat die Variable direkten Einfluss auf die Kernelerstellung selbst?
Meines Erachtens geht es doch nur darum, dass der Kernel die entsprechenden Module unter /lib/modules/2.4.x-xxx findet. Aber der Kernel selbst, bleibt doch von der Varible völlig unbeeinflusst.
Richtig?
Sie hat insofern Einfluss auf die Kernelerstellung, als dass der Kernel natuerlich selber Bescheid weiss, wie man ihn genannt hat. (Siehe /proc/sys/osrelease, z.B.), Die Module werden also in /lib/modules/`uname -r`/ gesucht.
2. Wie findet der Kernel seine entsprechenden Module aus dem Verzeichnis /lib/modules/2.4.x-xxx heraus?
Siehe man modprobe, viel deutlicher koennte ich es nicht ausdruecken.
3. Welchen Einfluss bzw. welche Rolle spielt die Datei modules.conf dabei?
In dieser Datei werden doch nur die Parameter für die Module festgelegt, aber mehr nicht.
Anmerkung: bei mir wird diese Datei sowieso nicht ausgewertet.
Bei einer neuen Kernelerstellung bzw. Modulerstellung bleibt diese Datei völlig unangetastet.
Warum?
In modules.conf kann man das Verhalten von modprobe und depmod beeinflussen, z.B. Modulaliase angeben, Parameter angeben, die beim Laden des Modules beachtet werden muessen, und angeben, unter welchen Umstaenden das Modul automatisch geladen werden soll.
Hintergrund:
die Meldung 'unresolved sysmbols'
Das heisst ja, dass der Kernel seine entspr. Module nicht finden kann.
Aber warum?
Es heisst, dass im Kernel nicht alle benoetigten Abhaengigkeiten erfuellt sind, aber nicht notwendigerweise, dass Module nicht gefunden werden konnten. Eventuell gibt's Versionskonflikte (kann bei Binarytreibern schonmal vorkommen), man hat vergessen benoetigte Module vorher zu laden, oder sonstige Fehler im Code oder beim Compilieren.
Magic is always the best solution -- especially reliable magic.

Antworten