Kurz vor Ostern 2005 zeigte mir mein Portage plötzlich, aber denoch nicht
unerwartet an, daß es gerne einen 2.6er Kernel installieren möchte und
zwar ohne das ich irgendwelche Veränderungen an meinen Portage Einstellungen
vorgenommen hatte (~x86, etc.).
Grund genug auf dieser Seite alle bekannten Problemchen beim Umstieg
auf die neue Kernelversion zu sammeln und informative Links zu diesem
Thema vorzustellen.
Am Ende der Seite gibt es einige Links, die wirklich sehr gut beschreiben,
wie man umsteigt bzw. entsprechende Hilfestellung geben.
Am Ende der Seite im Abschnitt Links finden sich ausgezeichnete Seiten
zum Thema Installation und Einrichtung von UDEV. Ergänzend sei hier auf
einige Punkte hingewiesen.
Gelegentlich fehlen bestimmte devices unter UDEV, da das entsprechende
Kernelmodul noch nicht geladen ist. Beispielsweise /dev/ppp, solange
modprobe ppp oder modprobe pppoe als root nicht aufgerufen wurde. Am
Einfachsten man trägt die benötigten Module in die Datei
/etc/modules.autoload.d/kernel-2.6 ein. Die Module werden beim Start
direkt geladen und UDEV legt die entsprechenden devices an.
Bei einigen devices müssen die Rechte angepasst werden. Beispielsweise
hat ein Benutzer, der mit kisdnwatch oder kadslwatch die
Verbindungsstatistik aus /dev/capi20 auslesen will, keine Berechtigung
dazu. Um die Rechte zu verändern legt man unter
/etc/udev/permissions.d/ eine neue Datei an, die lexikallisch vor der
Standarddatei 50-udev.permissions steht.
Dort gibt man die gewünschten Berechtigungen wie folgt an:
#name:user:group:mode
capi*:root:tty:0666
mixer:root:audio:0666
Die obigen Einträge führen dazu, da sowohl /dev/mixer, als auch
/dev/capi* devices world readable und writable sind und damit auch
ein normaler User darauf zugreifen kann. Hier sollte allerdings auch auf
Sicherheitsaspekte Rücksicht genommen werden und gut überlegt werden
welche Berechtigungen man vergibt.
Ab der Version 050 von udev werden die Berechtigungen nicht mehr in
einer separaten Datei vergeben, sondern im rules file integriert
(/etc/udev/rules.d/50-udev.rules).
Beispiel:
Um das Device /dev/capi20 anstatt der Gruppe root, der Gruppe dialout zuzuordnen
ersetzt man
KERNEL=“capi“, NAME=“capi20″, SYMLINK=“isdn/capi20″
KERNEL=“capi*“, NAME=“capi/%n“
durch
KERNEL=“capi“, NAME=“capi20″, SYMLINK=“isdn/capi20″, GROUP=“dialout“
KERNEL=“capi*“, NAME=“capi/%n“, GROUP=“dialout“
Mit OWNER funktioniert das genauso.
Die linux-headers haben die größten Probleme bereitet, sie
verhinderten das sich die Kernelmodule des nvidia-Treibers und des
fcdsl-Treibers übersetzen liesen.
Schuld daran war ein fehlender Link oder eine fehlende Datei (genau
weiß ich es nicht).
Beheben kann man das Problem aber durch einen symbolischen Link
cd /usr/src/linux/asm
ln -sf /usr/src/linux/asm/mach-default/irqvectors.h irq_vectors.h
Danach läuft wieder alles einwandfrei.
Die Fehler zeigen sich durch einen Abbruch beim Kompilieren der Programme
und einer Fehlermeldung, die besagt NR_IRQS oder ähnlich sei nicht definiert
bzw. eine bestimmte Header-Datei (.h) wird nicht gefunden.
Funktioniert haben bei mir die Treiber mit der 7xxx Kennung, die sich
mit ACCEPT_KEYWORDS=’~x86′ emerge nvidia-kernel nvidia-glx installieren
lassen.
Zusätzlich zum fcdsl Treiber muss man die capi4k-tils neu installieren,
ansonsten verlief der Update für die DSL Karte schmerzfrei.
emerge capi4k-utils
FCDSL_CARDS=“fcdsl“ emerge fcdsl
Nach dem Update auf 2.6 findet X11 die Maus nicht mehr. Daran ist das
neue UDEV schuld. Standardmäßig befindet sich die Maus jetzt
unter /dev/input/mice. Also in /etc/X11/xorg.conf einfach /dev/psaux
oder /dev/mouse0 durch /dev/input/mice ersetzen, dann geht es wieder.
kmix (gelöst)
Nach dem Upgrade stürzt kmix einige Sekunden nach dem Start wieder
ab (SIGSEGV). Nach update auf alsa-headers und alsa-lib v1.09 funzt es wieder.
pppd / capi
Die ppp Kernelmodule werden nicht automatisch geladen, erst nach einem
modprobe pppoe (dsl-like), kann man darauf zugreifen.
Beim Starten von kadslwatch/kisdnwatch als Benutzer (nicht root) kommt
der Fehler /dev/capi20 keine Berechtigung. Behoben werden kann dies
durch eine differenzierte Rechtevergabe mit UDEV (s. oben).
UDEV Guide
The complete GentooLinux 2.6 migration guide
UDEV Primer
Writing udev rules