Dies ist die Übersetzung von Decibels' UDEV Primer ins Deutsche. Autor des Originaldokumentes ist David Babcock (alias Decibels), an dieser Stelle herzlichen Dank, zum einen für dieses großartige Tutorial, zum anderen für die schnelle Antwort auf meine Anfragen ;). Für die Aktualität der Übersetzung kann nicht immer garantiert werden, daher gilt im Zweifelsfalle der Inhalt des Originaldokumentes.
Des Weiteren habe ich mir die Freiheit genommen hier und da kleinere Veränderungen am Text vorzunehmen (für einige
Redewendungen gibt es z.B. einfach keine deutschen Entsprechungen).
Sollte der geneigte Leser Fehler entdecken, möge er sie bitte an webmaster[at]athemis[dot]de melden.
Dokumentenversion: 1.3
Datum: 06.04.2004
Verfasser der Übersetzung: Alexander Minges (@themis)
| I. | Inhalt |
|---|
| 1. | Vorwort |
|---|
| 1.1 | Letzte Änderungen am Primer |
|---|---|
| 1.2 | Was ist UDEV |
| 2. | Schritte zum Aufsetzen von UDEV |
|---|
| 2.1 | Kernelkonfiguration |
|---|
| 2.1.1 | mm-sources-2.6.3_rc1-mm1 Beispiel |
|---|
| 2.2 | Installation von UDEV |
|---|---|
| 2.3 | Hotplug |
| 2.4 | Erstellen von /sys |
| 2.5 | Fstab |
| 2.6 | /lib/udev-state.tar.bz2 |
| 2.7 | Konfiguration bei altem Baselayout |
| 2.7.1 | /etc/init.d/halt.sh |
|---|---|
| 2.7.2 | /sbin/rc |
| 2.8 | Konfiguration bei neuem Baselayout |
|---|
| 2.8.1 | Devfs or Udev (mit devices.tar.bz2) |
|---|---|
| 2.8.2 | Devfs oder Udev (ohne devices.tar.bz2) |
| 2.8.3 | Udev (mit devices.tar.bz2; ohne Devfs) |
| 2.8.4 | Udev (ohne devices.tar.bz2; ohne Devfs) |
| 2.9 | /dev/null und /dev/console bei purem UDEV System |
|---|---|
| 2.10 | NVIDIA-Treiber |
| 2.11 | Konfiguration LILO/GRUB |
| 2.11.1 | Beispiel LILO |
|---|---|
| 2.11.2 | Beispiel GRUB |
| 2.12 | Problemgeräte |
|---|
| 2.12.1 | NVIDIA-Treiber |
|---|---|
| 2.12.2 | PPP-Gerät |
| 2.12.3 | Mäuse, Mäuse, Mäuse |
| 2.13 | Neustart des Systems |
|---|
| 3. | Sonstige Probleme |
|---|
| 4. | Links |
|---|
| 5. | Ausschnitt aus "How To Write UDev Rules" |
|---|
Viele aufregenden Dinge sind bisher betreffend UDEV geschehen. Aufgrund mehrerer Verbesserungen ist es nun möglich ein pures UDEV System zu betreiben. Einige Geräte wurden noch nicht für Sysfs portiert, so dass man in diesen Fällen einen Work-Around benutzen muss. Ansonsten hat man zwei Möglichkeiten: Aufsetzen einer puren UDEV Systems und Verwenden der Work-Arounds, ODER das Benutzen des Gentoo Standard-Setups, welches eine device.tar.bz2-Datei verwendet, um /dev zu füllen. Näheres dazu, wenn wir zum eigentlichen Setup kommen. Die aktuellste Information ist, dass es immernoch etwa 162 KernelGeräte gibt, welche noch für Sysfs portiert werden müssen. Mein Scanner begann erst kürzlich unter UDEV zu funktionieren (wird als USB Kamera erkannt, aber arbeitet). Mittlerweile funktioniert für mich alles.
Falls Sie bereits UDEV installiert haben, möchten Sie vielleicht DSD's Guide on Writing UDev Rules lesen. Ein Verweis befindet sich in den Links am Ende.
Zuerst eine kleine Vorbereitung. Was geschieht mit Devfs im 2.6er Kernel? Direkt aus dem Munde der Kernelentwickler:
| Note that devfs has been obsoleted by udev, http://www.kernel.org/pub/linux/utils/kernel/hotplug/ It has been stripped down to a bare minimum and is only provided for legacy installations that use its naming scheme which is unfortunately different from the names normal Linux installations use. //Übersetzung\\ Beachte, dass devfs durch udev ersetzt wird. http://www.kernel.org/pub/linux/utils/kernel/hotplug/ Es wurde auf das absolute Minimum beschränkt und wird nur für Installationen angeboten, die sein Namensschema unterstützen, welches sich unglücklicherweise von jenem unterscheidet, das normale Linuxinstallationen verwenden. |
1.3: Hinweise, die sich durch Kernelversionen >=2.6.4 ergeben eingepflegt (betrifft CONFIG_DEVPTS_FS)
1.2: Änderungen, welche sich durch >=udev-021 ergeben eingepflegt
1.1a: Fehler, die bei der Fehlerbehebung entstanden sind behoben, Links hinzugefügt
1.1: Verschiedene Rechtschreib- und Tippfehler behoben.
Im Groben gesprochen ist UDEV ein Ersatz für DEVFS im User-Space unter Verwendung von Sysfs und /sbin/hotplug. Es erstellt und entfernt Einträge in /dev, basierend auf der aktuellen Systemkonfiguration. Dies erreicht es durch Überwachen der von /sbin/hotplug generierten Ereignisse im System und Auslesen von Informationen zu diesen Ereignissen aus dem Sysfs.
UDEV arbeitet ausschließlich im User-Space, unter Benutzung von /sbin/hotplug Rufen, welche der Kernel tätigt, wann immer ein Gerät zum Kernel hinzugefügt oder entfernt wird. Die Namensgebung und Zugangsberechtigungen werden im User-Space ausgeführt.
Einige Links zu weiterführenden Informationen. (Werde weitere hinzufügen, im Moment nur ein wenig Zusammengewürfeltes)
http://ftp.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
Ihre erste Frage ist wahrscheinlich: Wie bekomme ich UDEV zum Laufen? Dies ist leichter als Sie vielleicht vermutet haben, außer Sie haben noch nie einen Kernel kompiliert, aber das ist etwas, was ich Ihnen überlasse, da es nicht Thema dieses Tutorials ist.
Wie oben erwähnt benötigen Sie zur Installation und Konfiguration den 2.6er Kernel. Die beste Wahl der zu benutzenden Kernel sind: >mm-sources-2.6.1-mm3 (im Moment benutze ich 2.6.3_rc1-mm1), >gentoo-dev-sources-2.6.1 oder >development-sources-2.6.2. Beachten Sie das Größer-Als-Zeichen und besorgen Sie einen Kernel, der neuer ist. UDEV wird mit einigen niedrigeren Kernelversionen arbeiten, aber es wurden Verbesserungen getätigt, so dass der Erfolg mit neueren Kerneln größer sein wird. Der wichtige Teil der Konfiguration wird unten gezeigt. Beachten Sie auch: Sie können noch immer DEVFS in den Kernel kompilieren und beim Booten zwischen DEVFS udn UDEV wählen, glauben Sie also nicht Sie dürften DEVFS nicht hineinkompilieren um UDEV zu benutzen! Anmerkung: DEVFS nicht zum automatischen Mounten beim Booten konfigurieren! Zumindest ab baselayout-1.8.6.13-r1 wird dann die "nomount" Option im Bootloader ignoriert und somit versucht Devfs zu laden, egal welche Optionen Sie in Ihrer neuen /etc/conf.d/rc-Datei haben. Ihr System wird nicht booten und bei "checking root filesystem" hängen bleiben. Allersings ist das Dateisystem keinesfalls beschädigt. Zum Beheben müssen Sie von irgendwoher (z.B. LiveCD) Ihr System per chroot betreten, die Option Automatically Start Devfs at boot deaktivieren und den Kernel neu kompilieren. Eventuell müssen Sie diesem sogar ein make mrproper voranstellen. Ich habe dies auf die harte Art gelernt.
Es gibt einige Optionen, welche nicht während menuconfig auftauchen, daher sollten Sie .config ansehen. Wenn Sie diese Datei überprüfen wollen, sollte sie aussehen wie nachfolgend gezeigt. Außerdem kann bei einigen Kerneln CONFIG_HOTPLUG an anderer Stelle erscheinen, als in General Setup. Sie sollten ein "grep" nach dem Objekt in .config durchführen, nach dem Sie suchen und anschließend zurück zu menuconfig gehen um es entsprechend zu setzen.
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_HOTPLUG=y
#
# File systems
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set <--- Sie können auch "Y" wählen
CONFIG_DEVPTS_FS=y Setzen Sie auf keinen Fall "Devfs to load Automatically at Boot"!
# CONFIG_DEVPTS_FS_XATTR is not set CONFIG_DEVPTS_FS existiert ab Kernel 2.6.4 nicht mehr und ist standardmäßig aktiv
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
|
Sie können, wenn Sie wollen, noch immer DEVFS (CONFIG_DEVFS_FS) in den kernel kompilieren, aber beachten Sie die bereits ausgesprochenen Warnungen oberhalb. Falls Sie sich dafür entscheiden, gibt es einige Bootoptionen für Lilo oder Grub, die an späterer Stelle eingebracht werden, welche es erlauben zwischen UDEV und DEVFS zu wechseln. Beachten Sie bitte, dass DEVFS entschlackt wurde. Beachten Sie bitte auch, dass wenn Sie unter Benutzung von DEVFS Änderungen vornehmen und rebooten, diese dann von UDEV nicht übernommen werden. Der einzige Weg den Gerätestatus in UDEV zu speichern ist /lib/udev-state/devices.tar.bz2 in der standardmäßigen Gentoo UDEV Installation zu benutzen. Falls Sie ein pures UDEV System verwenden (z.B. ohne devices.tar.bz2), werden keine Änderungen gespeichert, dies läuft alles dynamisch ab. Sie können aber Regeln zur Geräteerstellung zu /etc/udev/udev.rules hinzufügen.
Danach: emerge udev Installieren Sie mindestens Version 017, ältere Versionen funktionieren auch, aber damit läufen Sie eher in Gefahr Probleme zu bekommen. Folglich ist die neuere Version stets zu bessere Wahl. UDEV besitzt als Abhängigkeiten des Weiteren sysfsutils und hotplug, diese werden auch installiert, falls sie auf Ihrem System nicht verfügbar sind. Momentan ist die aktuelle Version der sysfsutils sysfsutils-0.4.0 und das bereits seit einer ganzen Weile.
Hinzufügen von hotplug zum Boot Run-Level: rc-update add hotplug boot. Anmerkung: Sie möchten vielleicht überprüfen, ob hotplug nicht bereits für den Standard-Run-Level (default run-level) registriert ist. Dies können sie mit: rc-update -s erreichen, welches eine Liste ähnlich der folgenden generieren sollte (Liste hier gekürzt):
| bash-2.05b# rc-update -s alsasound | boot hdparm | default hostname | boot hotplug | default |
Zum Entfernen benutzen Sie: rc-update del hotplug default
Anscheinend erstellt Gentoo nun automatisch den /sys Ordner im Stammverzeichnis um das Sysfs darauf einzuhängen. Zumindest tut es dies auf Neuinstallationen, eventuell auch auf Systemen die nach UDEV migrieren. Am Besten überprüfen Sie, ob /sys in / (Stammverzeichnis) erstellt wird und richten es ggf. manuell ein: mkdir /sys
Auch handhabt Gentoo mittlerweile das Einhängen von devpts und sys. Daher müssen Sie keinerlei Eintrag dahingehend in /etc/fstab vornehmen, diese Aufgabe hat das /sbin/rc Script übernommen. Den Status können Sie mit df -a überprüfen. Ich hatte keine Probleme mit entsprechenden Einträgen in fstab, falls es Ihnen anders ergehen sollte, können sie diese Einträge aber auch ohne Bedenken entfernen. Sollten Sie Probleme mit nicht eingehängtem devpts oder sysfs haben, oder nicht in der Lage sein eine Konsolensitzung zu öffnen, liegt es wahrscheinlich an anderen Dingen, als an UDEV oder den fstab-Einträgen.
| Note that devfs no longer manages /dev/pts! If you are using UNIX98 ptys, you will also need to enable (and mount) the /dev/pts filesystem (CONFIG_DEVPTS_FS). |
An diesem Punkt denken Sie vielleicht, Sie haben UDEV, Sysfs und Hotplug installiert und sind soweit fertig, aber leider isst dem NICHT so. Bis nicht das Sysfs eingehängt, /dev im Ramfs eingehängt und Hotplug gestartet sind, funktioniert UDEV im Grunde nicht. Sie werden zwar Änderungen in /sys sehen, aber das System selbst wird mit diesen Informationen nichts anfangen können.
Eine Datei, die Sie sich vielleicht ansehen wollen ist devices.tar.bz2 in /lib/udev-state. Hier wird der aktuelle Status von /dev aus dem Ramfs festgehalten, wenn Sie den Rechner herunterfahren und beim Booten wiederhergestellt.
Geht das Speichern des /dev-Status' nicht gegen den Geist von UDEV? UDEV ist als dynamisches Dateisystem gedacht, welches nur Geräte auf dem System erstellt, wenn dies auch nötig ist, z.B. wenn Ihr Scanner nicht angeschlossen ist, brauchen Sie auch keine Gerätedatei dafür, also wird auch keine erstellt. Wenn sie ihn aber anschließen, erstellt UDEV die entsprechende Dastei. Wird der Status von /dev gespeichert wird diese Gerätedatei aber nach dem nächsten Booten wieder vorhanden sein, sogar, wenn der Scanner nicht angeschlossen ist. Der Grund, weshalb dies vorerst so gehandhabt wird/wurde ist, dass UDEV zu Beginn nur die elementarsten Gerätedateien dynamisch zu generieren in der Lage war, also Geräte wie block devices (Festplatten), tty, usw. UDEV hat sich seit dem weiterentwickelt und hat ein hohes Maß an Funktionalität erreicht. Daher ist es nun möglich ein pures UDEV Sytem laufen zu lassen. Es gibt zwar einige, wenige Probleme, aber hierfür gibt es Work-Arounds.
Sehr bald wird wahrscheinlich Gentoo die Datei devices.tar.bz2 entfernen, wenn die Entwicklung UDEVs weiter vorangeschritten ist. Augenscheinlich rückt dieser Punkt immer näher.
Stellen Sie durch etc-update sicher, dass Sie die alten Konfigurationsdateien durch die neueren ersetzen. Falls Sie dies nicht tun, wird der aktuelle /dev-Status nicht in /lib/udev-state/devices.tar.bz2 abgelegt. Auch wenn Sie die Verwendung eines puren UDEV Sytems planen müssen Sie die Konfigurationsdateien aktualisieren, da ansonsten die nötigen Scriptdateien fehlten.
Falls Sie mit dem Standardsetup von Gentoo betreffend UDEV zufrieden sind, können Sie diesen Abschnitt überspringen. Früher oder später müssen Sie diese entscheidung so oder so nicht mehr treffen. Um ein pures UDEV Sytem zum Laufen zu bringen, editieren Sie bitte die entsprechenden Scripts wie unten gezeigt.
Falls Sie >=baselayout-1.8.6.13-r1 benutzen müssen Sie /etc/init.d/halt.sh und /sbin/rc nicht, wie unten gezeigt editieren, sondern eine andere Datei. Beachten Sie dazu den nächsten Unterabschnitt. Benutzen Sie eine ältere Version von baselayout, folgen Sie bitte den Anweisungen zum Editieren der beiden Dateien.
Wenn Sie die blau markierten Teile (als root!) mit ## auskommentieren halten Sie das System davon ab, den /dev-Status in der devices.tar.bz2-Datei abzulegen. Der entsprechende Teil des Scripts befindet sich recht zu Beginn desselben.
# We need to properly terminate devfsd to save the permissions
if [ -n "`ps --no-heading -C 'devfsd'`" ]
then
ebegin "Stopping devfsd"
killall -15 devfsd &>/dev/null
eend $?
elif [ ! -e /dev/.devfsd -a -e /dev/.udev ]
then
ebegin "Saving device nodes"
##cd /dev
##try tar -jclpf "/tmp/devices-$$.tar.bz2" *
##try mv -f "/tmp/devices-$$.tar.bz2" /lib/udev-state/devices.tar.bz2
eend 0
fi
|
Hier müssen Sie (als root!) nur eine Zeile editieren, auch diese ist hier blau markiert und muss mit ## auskommentiert werden. Diese Änderung hält das System davon ab, devices.tar.bz2 beim Booten auszulesen.
# Fix weird bug where there is a /dev/.devfsd in a unmounted /dev
mymounts="$(awk '($3 == "devfs") { print "yes"; exit 0 }' /proc/mounts)"
if [ -e "/dev/.devfsd" -a "${mymounts}" != "yes" ]
then
rm -f /dev/.devfsd
fi
if [ "${udev}" = "yes" ]
then
ebegin "Mounting ramfs at /dev"
try mount -n -t ramfs none /dev
eend $?
ebegin "Configuring system to use udev"
einfo " Populating /dev with device nodes..."
##try tar -jxpf /lib/udev-state/devices.tar.bz2 -C /dev
populate_udev
if [ -e /proc/sys/kernel/hotplug -a -x /sbin/hotplug ]
then
einfo " Using /sbin/hotplug for udev management..."
elif [ -e /proc/sys/kernel/hotplug ]
then
einfo " Setting /sbin/udev as hotplug agent..."
echo "/sbin/udev" > /proc/sys/kernel/hotplug
else
ewarn " Kernel was not compiled with hotplug support!"
fi
eend 0
# Create problematic directories
mkdir -p /dev/{pts,shm}
# Same thing as /dev/.devfsd
touch /dev/.udev
|
Mit dem neuen baselayout-1.8.6.13-r1 müssen Sie /etc/conf.d/rc anstelle der beiden oben genannten Dateien editieren. Dies sind die relevanten Teile (ausgehend von den Standardeinstellungen):
# Set to "yes" if you want to save /dev to a tarball on shutdown
# and restore it on startup. This is useful if you have a lot of
# custom device nodes that udev do not handle/know about.
# (ONLY used by UDEV enabled systems!)
RC_DEVICE_TARBALL="yes"
# Set to "yes" if you want devfsd to start upon bootup. This is
# the default for Gentoo.
# Set to "no" only if you understand the full implications. A
# number of files may need to be altered (i.e. /etc/inittab,
# /etc/fstab, etc.).
# Also note that it does _NOT_ start for UDEV enabled systems,
# even if RC_DEVFSD_STARTUP="yes" ...
RC_DEVFSD_STARTUP="yes"
|
Nach der Methode "Versuch und Irrtum" finden Sie hier die Möglichkeiten, wie Sie die Optionen in dieser Datei editieren müssen:
Standardeinstellung. Sie können mit dieser Einstellung zu Devfs oder Udev booten. Falls Sie denselben Kernel für beides benutzen möchten, stellen Sie sicher, die richtigen Bootparameter zu verwenden (siehe weiter unten).
RC_DEVICE_TARBALL="yes" RC_DEVFSD_STARTUP="yes"
Die nächste Möglichkeit liest nicht devices.tar.bz2 aus, ermöglicht aber weiterhin das Booten wahlweise in Devfs oder Udev. Auch hier werden die korrekten Bootparameter benötigt.
RC_DEVICE_TARBALL="no" RC_DEVFSD_STARTUP="yes"
Die letzte Möglichkeit beinhaltet das Benutzen von Udev mit oder ohne devices.tar.bz2 aber ohne die Möglichkeit in Devfs zu booten.
RC_DEVICE_TARBALL="yes" RC_DEVFSD_STARTUP="no"
RC_DEVICE_TARBALL="no" RC_DEVFSD_STARTUP="no"
Nach dem Einführen dieser Mengen an Variablen kann ich es kaum noch erwarten, dass Devfs endlich verschwindet, damit es nicht länger zur Wahl stehen muss ;)
Ist dies eine neue Installation eines puren UDEV Systems, oder falls ein Fehler der Art: "WARNING: Unable to open an initial console." auftritt, führen Sie die nachfolgenden Schritte aus. Letzterer Fehler tritt auf, da vor dem Starten von UDEV bereits /dev/null und /dev/console benötigt werden, diese aber noch nicht existieren, da UDEV noch nicht gestartet wurde. Beide Gerätedateien werden daher statisch verlinkt in /dev benötigt, zumindest bis zum jetzigen Zeitpunkt:
| cd /dev mknod -m 660 console c 5 1 mknod -m 660 null c 1 3 |
Dadurch werden /dev/console und /dev/null manuell angelegt.
Benutzen Sie >=nvidia-kernel-1.0.5336-r1 und >=nvidia-glx-1.0-5336-r1. Diese Treiber funktionieren mit udev/sysfs, und
ermöglichen so, im gegensatz zu früheren Treiberversionen, das Starten des X Servers. Ich hatte bisher keine Probleme mit ihnen.
Falls Sie diese Versionen nicht installieren können oder wollen, beachten Sie die Hinweise im Abschnitt "Problemgeräte".
Seit udev-021 gibt es die ausführbare Datei /sbin/udevstart. Sollten die entsprechenden Geräte
in /dev nicht erstellt werden, obwohl der korrekte Treiber verwendet wird und/oder es mit
früheren Versionen von udev einwandfrei funktionierte, beachten Sie bitte die Problemsektion weiter unten.
Das Letzte, was Sie editieren müssen sind die Konfigurationsdateien von LILO oder Grub. (Beachten Sie die ProblemGerätesektion vor dem Neustart!).
Falls Sie DEVFS nicht in den Kernel kompiliert haben, sind Sie bereits bereit zum Neustart. Es gibt nichts, dass Sie an ihrem Bootloader ändern müssten. Haben Sie aber DEVFS (Haben Sie auch "Devfs automatically load at Boot" aktiviert? Wenn ja, deaktivieren Sie dies und kompilieren Sie den Kernel neu. Letzte Warnung!) in den Kernel kompiliert stehen in der Tat Änderungen an Gentoo wird standardmäßig versuchen DEVFS zu laden, selbst wenn UDEV installiert ist. Daher folgende Optionen:
# Udev system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooUDEV"
append = "gentoo=nodevfs ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
|
# Devfs system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooUDEV"
append = "gentoo=noudev ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
|
# Udev system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooUDEV"
append = "gentoo=nodevfs ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
# Devfs system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooDEVFS"
append = "gentoo=noudev ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
|
Bootparameter analog zu den LILO Beispielen.
title=Gentoo UDEV
root (hd0,0)
kernel (hd0,0)/bzImage-2.6.3-rc1-mm1 root=/dev/hda3 gentoo=nodevfs
|
Falls Sie Ihren Kernel ohne DEVFS-Unterszützung kompiliert haben, später aber DEVFS benutzen wollen, kompilieren SIe den Kernel mit DEVFS neu und ändern Sie die Konfiguration Ihres Bootloaders entsprechend (siehe oben). UDEV und DEVFS können nicht gleichzeitig betrieben werden. Noch einmal: Kompilieren Sie unter keinen Umständen "Automatically load Devfs at Boot" in den Kernel!
Editieren der devices.tar.bz2: Einige Personen wählen die Standardkonfiguration von UDEV unter Gentoo und ändern einfach die devices.tar.bz2 dahingehend ab, dass dort nur noch Gerätedateien enthalten sind, die nicht automatisch von UDEV generiert werden. Dies stellt eine Option für Geräte wie /dev/null oder /dev/console dar. Benutzen Sie hierfür z.B. ein Programm wie Ark, ein anderes grafisches Packtool oder die Kommandozeile. Ich persönlich habe devices.tar.bz2 einfach in mein Heimverzeichnis verschoben, alles unnötige in der Datei gelöscht und danach wieder zurückverschoben, bzw. die bestehende Datei in /lib/udev-state damit ersetzt. Stellen Sie aber hierbei sicher, dass Sie die Scripts nicht dahingehend modifiziert haben, devices.tar.bz2 nicht zu benutzen! Belassen Sie also z.B. RC_DEVICE_TARBALL in /etc/conf.d/rc bei "yes"
Nvidia-kernel-1.0.5336-r1 und nvidia-glx-1.0.5336-r1 arbeiten unter udev/sysfs. Nebenbei ist es eine Standardprozedur die Nvidiamodule zu /etc/modules.autoload.d/Ihr_Kernel hinzuzufügen. Falls Sie also die oben genannte Version einsetzen und X startet aufgrund fehlender /dev/nvidia# nicht, stellen Sie sicher, dass die Module zum Autoload hinzugefügt wurden. Falls Sie X trotzdem nicht zum arbeiten bewegen können, versuchen Sie dies:
Sie können die Gerätedateien manuell in /dev einfügen. Eine Möglichkeit ist es, Folgendes in /etc/conf.d/local.start einzufügen:
| mknod -m 660 /dev/nvidia0 c 195 0 mknod -m 660 /dev/nvidia1 c 195 1 mknod -m 660 /dev/nvidiactl c 195 255 |
Ich bin mir nicht sicher, wieviele Gerätedateien benötigt werden. Ich habe nur zwei generiert und keinerlei Probleme damit. Wenn UDEV plötzlich anfängt die Gerätedateien selst zu generieren, oder Sie zur oben genannten Treiberversion wechseln, wird beim Booten ein Fehler erscheinen, der besagt, dass die Gerätedateien bereits existieren. Sie können die drei eingefügten Zeilen dann aus /etc/conf.d/start.local wieder entfernen.
Wenn Sie nvidia-kernel-1.0.5336-r1 installieren und der Fehler "Error: API mismatch: the NVIDIA kernel module is version 1.0.4480, but this X module is version 1.0.5336. Please be sure that your kernel module and all NVIDIA driver files have the same version" erscheint, stellen Sie sicher, dass in /lib/modules/Ihr_Kernel//video nur ein Nvidia-Modul existiert, nämlich nvidia.ko im Falle von nvidia-kernel-1.0.5336-r1. Sollte dort noch ein anderes sein (z.B. nvidia.o), löschen Sie es. Wird das Problem dadurch nicht behoben, unemergen Sie sämtliche Versionen von nvidia-driver und emergen Sie NUR nvidia-driver-1.0.5336-r1.
Seit udev-021 gibt es eine neue, ausführbare Datei /sbin/udevstart. Seit dieser Version werden keinerlei Gerätedateien mehr für Nvidia Geräte und nur eine einzige für ALSA erzeugt. Falls Sie X nicht starten können, führen Sie als root folgendes aus:
| /sbin/udevstart |
Dadurch werden die Gerätedateien angelegt. Anschließend können Sie sich als
Benutzer anmelden und X starten.
Alternativ zum manuellen Ausführen des Befehls können Sie ihn auch am Anfang der Datei
/etc/conf.d/local.start einfügen.
Dies scheint eines der Geräte zu sein, das noch zu Sysfs portiert werden muss, daher können Sie auch keine UDEV-Regel erstellen um die Gerätedatei zu erstellen. Sollte Sie /dev/ppp brauchen, müssen Sie es manuell erstellen, z.B. durch Hinzufügen zur local.start wie bei den Nvidia-Treibern (siehe oben). Oder aber Sie ändern wie bereits beschrieben /lib/udev-state/devices.tar.bz2 entsprechend ab. Zum Benutzen der local.start-Methode fügen Sie dort folgende Zeilen ein:
| mknod -m 660 /dev/ppp c 108 0 |
Dieser Abschnitt ist für all diejenigen, deren Maus unter UDEV nicht funktioniert. Es ist wirklich kein Problem von UDEV, das Problem liegt eher in der Art und Weise, wie Sie zuvor Ihre Maus konfiguriert haben. UDEV hat (momentan) 4 Gerätepfade, welche für Mäuse benutzt werden können:
| /dev/input/mice /dev/input/mouse0 (außerdem mouse1, mouse2, usw. je nach Anzahl, mouse0 ist die erste Maus) /dev/misc/psaux (per symbolischen Link zu /dev/psaux) |
Welchen auch immer Sie benutzen, (z.B. mouse#, mice oder psaux), stellen Sie sicher, dass Ihre /etc/X11/XF86Config-4 oder XF86Config zum korrekten Gerätepfad verweist. Sie können auch den Pfad in /etc/udev/udev.rules ändern, müsen dan aber bei jedem Update von Udev diese Änderungen erneut anbringen. Daher ist es besser die XF86Config-4/XF86Config zu editieren.
Sie sollten nun in der Lage sein Ihr System neuzustarten. Beim Booten sollten Sie dies hier sehen:
| mounting sysfs at /sys mounting ramfs at /dev configuring system to use udev populating /dev with device nodes using /sbin/hotplug for udev management |
Es gibt einige, andere Problemstellungen, welche in den Foren gesichtet wurden:
DSD's Guide on how to Write Udev Rules: Schreiben von UDEV-Regeln
Im Moment existiert ein sehr gutes Thema zu UDEV in den Gentoo Foren: Thema im Gentoo Forum
Das Schreiben von UDev Regeln stellt sich als recht einfach heraus. Ich habe ein Gerät ausgesucht, dass erst seit kurzem unter UDEV funktioniert: meinen Microtek Scanner.
Ich weiß, dass mein Scanner in /dev auf /dev/sg0 liegt. Ich kann auch tail-f /var/log/syslog benutzen, wenn Debug in Hotplug eingeschaltet ist um Folgendes zu erhalten:
| Feb 25 09:16:17 Decibels' default.hotplug[18643]: arguments (scsi_generic) env (OLDPWD=/ DEVPATH=/class/scsi_generic/sg0 ... |
Unter Berücksichtigung dieser Informationen suchte ich die besten, sich nicht verändernden Merkmale heraus:
| bash-2.05b# find | grep sg0 ./class/scsi_generic/sg0 ./class/scsi_generic/sg0/device ./class/scsi_generic/sg0/dev ./cdev/major/sg0 |
Basierend auf dieser Ausgabe gab ich ein:
| bash-2.05b# udevinfo -a -p /sys/class/scsi_generic/sg0 |
und erhielt:
| device '/sys/class/scsi_generic/sg0' has major:minor 21:0 looking at class device '/sys/class/scsi_generic/sg0': SYSFS{dev}="21:0" follow the class device's "device" looking at the device chain at '/sys/devices/platform/host0/0:0:0:0': BUS="scsi" <------ Nahm dieses Merkmal ID="0:0:0:0" SYSFS{detach_state}="0" SYSFS{type}="6" SYSFS{device_blocked}="0" SYSFS{queue_depth}="1" SYSFS{scsi_level}="3" SYSFS{vendor}=" " SYSFS{model}="Scanner V6UPL " <----- Nahm auch dieses Merkmal. Ja, die Leerzeichen sind KEIN Fehler. SYSFS{rev}="1.00" SYSFS{online}="1" looking at the device chain at '/sys/devices/platform/host0': BUS="" ID="host0" SYSFS{detach_state}="0" looking at the device chain at '/sys/devices/platform': BUS="" ID="platform" SYSFS{detach_state}="0"# |
OK, nun sehen wir uns an, wie man daraus eine UDEV-Regel erstellen kann. Folgendes wird zu /etc/udev/udev.rules hinzugefügt (getestet, die Leerzeichen bei der Modellbezeichnung können ausgelassen werden):
# Microtek Scanner
BUS="scsi", SYSFS{model}="Scanner V6UPL", NAME="%k", SYMLINK="scanner"
|
Ich weiß, dass mein XSane Backend micortek2.conf in /etc/sane.d ist. Es sucht nach einem SCSI-Gerät, also fügte ich den Symlink zu /dev/scanner an. Zwei gestartete Scanprogramme ließen mir nun die Wahl zwischen /dev/sg0 und /dev/scanner, also funktionierte alles.
Oben Genanntes ist hauptsächlich eine Art Übung, letztlich wird z.B. nur ein Symlink von /dev/scanner zu /dev/sg0 erstellt. In anderen Fällen möchten Sie vielleicht mit multiplen Geräten arbeiten und UDEV zwischen ihnen unterscheiden lassen. Für weitere Details lesen Sie bitte DSD's Guide. Mein nächstes Ziel ist es, /dev/sg0 mit /dev/scanner zu ersetzten, aber das ist Arbeit für einen anderen Tag...
Wird fortgesetzt...