Mailinglist Archive: opensuse-de (5499 mails)
| < Previous | Next > |
Re: Problem bei Kernel-Update 2.4.21-144 mit Nforce2
- From: Thomas Hertweck <Thomas.Hertweck@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 01 Jan 2004 14:24:55 +0100
- Message-id: <3FF41FA7.1090605@xxxxxxxxxxxxxxxxxxxx>
Hallo Joerg!
Bitte lerne, Emails ordentlich zu quoten - was Du produziert hast,
nennt sich TOFU (Text Oben, Fullquote Unten) und macht Threads auf
Mailinglisten unuebersichtlich und quasi nicht mehr durchschaubar.
Bitte gewoehne Dir eine andere Art des Zitierens an, siehe dazu auch
http://learn.to/quote/.
Jörg wrote:
> [...]
> Einziger Stolperstein: Directory
> /lib/modules/2.4.21-override-athlon/kernel/drivers/net fehlt.
>
> Also Korrektur der dilletantischen SUSE-Doku (nicht geprüft bzw. nicht
> up-to-date, ich bin wie gesagt sauer,
> dass das was in der Doku steht, offenbar nie ausprobiert wurde):
>
> Vor Schritt 4 (geht sicherlich noch eleganter, bin kein Profi):
> mkdir /lib/modules/2.4.21-override-athlon/kernel
> mkdir /lib/modules/2.4.21-override-athlon/kernel/drivers
> mkdir /lib/modules/2.4.21-override-athlon/kernel/drivers/net
Das override-Verzeichnis ist zum Funktionieren des Modules nicht
wirklich erforderlich, das Anlegen der Verzeichnisse haettest Du Dir
so gesehen sparen koennen. Das override-Verzeichnis ist eine SuSE
Eigenheit! SuSE hat inzwischen das Kernel-Release in den Namen
aufgenommen (z.B. 2.4.21-99-athlon -> 99 = Release-Number) - mit
jedem kleinen Bugfix (Patch) aendert sich aber diese Nummer, und
externe Module muessten jedesmal neu compiliert werden, selbst bei
nur minimalen Aenderungen am Kernel, da sich der Module-Pfad
gaendert hat. Deswegen gibt es das override-Verzeichnis, in dem
externe Module abgelegt werden koennen. Es wird _zuerst_ in diesem
Verzeichnis nach einem entsprechenden Modul gesucht (durch die
modutils) und dann in dem regulaeren /lib/modules/`uname -r`/. Das
heisst, Module im override-Verzeichnis haben Vorrang - dadurch kann
SuSE nun Patches einspielen und die Release-Nummer erhoehen, ohne
dass externe Module extra neu compiliert werden muessen. Das geht
natuerlich nur so lange gut, wie das Modul im override-Verzeichnis
wirklich noch zum gepatchten Kernel passt. Module im
override-Verzeichnis werden _nicht_ automatisch geloescht - ist ein
Modul dort also veraltet, dann kann es nicht geladen werden und kann
u.U. sogar zu einem Kernel-Crash fuehren, selbst wenn ein korrektes
Modul im regulaeren Module-Verzeichnis dagewesen waere. Dieses
Feature(?) des override-Verzeichnisses von SuSE halte ich fuer
potentiell sehr gefaehrlich und fehlertraechtig! Es ist die Aufgabe
des Systemadministrators, dieses Verzeichnis zu verwalten und evtl.
vorhandene veraltete Module zu entfernen. Ich wuerde dieses
Verzeichnis immer komplett leer lassen, denn nur dann ist man auf
der sicheren Seite - allerdings eben zu dem Preis, dass vielleicht
externe Kernel-Module oefters neu compiliert werden muessen...
> [TOFU geloescht]
Gruesse,
Thomson
Bitte lerne, Emails ordentlich zu quoten - was Du produziert hast,
nennt sich TOFU (Text Oben, Fullquote Unten) und macht Threads auf
Mailinglisten unuebersichtlich und quasi nicht mehr durchschaubar.
Bitte gewoehne Dir eine andere Art des Zitierens an, siehe dazu auch
http://learn.to/quote/.
Jörg wrote:
> [...]
> Einziger Stolperstein: Directory
> /lib/modules/2.4.21-override-athlon/kernel/drivers/net fehlt.
>
> Also Korrektur der dilletantischen SUSE-Doku (nicht geprüft bzw. nicht
> up-to-date, ich bin wie gesagt sauer,
> dass das was in der Doku steht, offenbar nie ausprobiert wurde):
>
> Vor Schritt 4 (geht sicherlich noch eleganter, bin kein Profi):
> mkdir /lib/modules/2.4.21-override-athlon/kernel
> mkdir /lib/modules/2.4.21-override-athlon/kernel/drivers
> mkdir /lib/modules/2.4.21-override-athlon/kernel/drivers/net
Das override-Verzeichnis ist zum Funktionieren des Modules nicht
wirklich erforderlich, das Anlegen der Verzeichnisse haettest Du Dir
so gesehen sparen koennen. Das override-Verzeichnis ist eine SuSE
Eigenheit! SuSE hat inzwischen das Kernel-Release in den Namen
aufgenommen (z.B. 2.4.21-99-athlon -> 99 = Release-Number) - mit
jedem kleinen Bugfix (Patch) aendert sich aber diese Nummer, und
externe Module muessten jedesmal neu compiliert werden, selbst bei
nur minimalen Aenderungen am Kernel, da sich der Module-Pfad
gaendert hat. Deswegen gibt es das override-Verzeichnis, in dem
externe Module abgelegt werden koennen. Es wird _zuerst_ in diesem
Verzeichnis nach einem entsprechenden Modul gesucht (durch die
modutils) und dann in dem regulaeren /lib/modules/`uname -r`/. Das
heisst, Module im override-Verzeichnis haben Vorrang - dadurch kann
SuSE nun Patches einspielen und die Release-Nummer erhoehen, ohne
dass externe Module extra neu compiliert werden muessen. Das geht
natuerlich nur so lange gut, wie das Modul im override-Verzeichnis
wirklich noch zum gepatchten Kernel passt. Module im
override-Verzeichnis werden _nicht_ automatisch geloescht - ist ein
Modul dort also veraltet, dann kann es nicht geladen werden und kann
u.U. sogar zu einem Kernel-Crash fuehren, selbst wenn ein korrektes
Modul im regulaeren Module-Verzeichnis dagewesen waere. Dieses
Feature(?) des override-Verzeichnisses von SuSE halte ich fuer
potentiell sehr gefaehrlich und fehlertraechtig! Es ist die Aufgabe
des Systemadministrators, dieses Verzeichnis zu verwalten und evtl.
vorhandene veraltete Module zu entfernen. Ich wuerde dieses
Verzeichnis immer komplett leer lassen, denn nur dann ist man auf
der sicheren Seite - allerdings eben zu dem Preis, dass vielleicht
externe Kernel-Module oefters neu compiliert werden muessen...
> [TOFU geloescht]
Gruesse,
Thomson
| < Previous | Next > |