Gentoo Logo

Gentoo udev Leitfaden

Inhalt:

1.  Was ist udev?

Das /dev Verzeichnis

Wenn Linuxbenutzer in der Gegenwart von Menschen, die glauben, dass Linux eine Art von Virus oder Kaffeesorte ist, über Hardware auf Ihrem System reden, dann werden Äußerungen wie "slash dev slash foo" mit Sicherheit für seltsame Blicke sorgen. Aber für den versierten User (und damit sind auch Sie gemeint) ist die Verwendung von /dev/hda1 nur eine schnelle Art, um zu erklären, dass wir über die erste Partition am Primary Master IDE reden. Oder etwa nicht?

Wir alle wissen, was eine Geräte(device)datei ist. Einige wissen auch, warum Gerätedateien, wenn wir einen genaueren Blick auf sie werfen (indem wir ls -l in /dev ausführen) besondere Nummern haben. Aber was wir immer für gegeben ansehen, ist, dass die Primary Master IDE Festplatte als /dev/hda bezeichnet wird. Sie mögen es nicht so sehen, aber das ist ein grundlegender Designfehler.

Denken sie an Hotplug Geräte wie USB, IEE1394, hot-swappable PCI... was ist das erste Gerät? Und für wie lange? Wie werden die anderen Geräte benannt, wenn das erste verschwindet? Wie wird das laufende Transaktionen beeinflussen? Wäre es nicht lustig, wenn der Druckauftrag plötzlich von Ihrem superneuen Laserdrucker auf Ihren fast toten Matrix Drucker verschoben würde, weil Ihre Mutter beschlossen hat den Stecker des Laserdruckers herauszuziehen, welcher leider der erste Drucker war?

Hier kommt udev ins Spiel. Die Ziele des udev Projekts sind sowohl interessant als auch nötig:

  • Läuft im userspace
  • Erstellt/entfernt dynamisch Gerätedateien
  • Liefert konsequente Benennung
  • Liefert ein user-space API

Um diese Funktionen zu liefern wird udev in drei unterschiedlichen Projekten entwickelt: namedev, libsysfs und natürlich udev.

namedev

Namedev erlaubt es Ihnen, Geräte separat vom udev Programm zu benennen. Dies erlaubt flexible Benennungsrichtlinien und Namensschemata, entwickelt von verschiedenen Körperschaften. Dieses Subsystem zur Gerätebenennung liefert ein Standardinterface, das udev benutzen kann.

Momentan wird nur ein einzelnes Benennungsschema von namedev geliefert, und zwar jenes, welches von LANANA geliefert wird. Dieses wird von der Mehrheit der Linux Systeme momentan verwendet und ist daher für die Mehrheit der Linuxanwender sehr brauchbar.

Namedev verwendet eine fünfstufige Prozedur um den Namen eines bestimmten Gerätes herauszufinden. Wenn in einem dieser Schritte der Gerätename gefunden wird, wird dieser Name verwendet. Diese Schritte sind:

  • Beschriftung oder Seriennummer
  • Bus Gerätenummer
  • Bus Topologie
  • Statisch vergebener Name
  • Vom Kernel gelieferter Name

Der Beschriftung oder Seriennummer Schritt überprüft, ob das Gerät ein einzigartiges Identifikationsmerkmal hat. Zum Beispiel haben USB Geräte eine einzigartige USB Seriennummer und SCSI Geräte eine einzigartige UUID. Wenn Namedev eine Übereinstimmung zwischen dieser einzigartigen Nummer und einer gegebenen Konfigurationsdatei findet, dann wird der von der Konfigurationsdatei gelieferte Name verwendet.

Der Bus Gerätenummer Schritt überprüft die Bus Gerätenummer. Für nicht-hot-swappable Umgebungen ist diese Prozedur ausreichend, um ein Hardwaregerät zu identifizieren. Zum Beispiel verändern sich PCI Busnummern selten in der Lebenszeit eines Systems. Auch hier wird, wenn namedev eine Übereinstimmung mit dieser Position und einer gegeben Konfigurationsdatei findet, der Name verwendet, der von der Konfigurationsdatei geliefert wird.

Genauso ist auch die Bus Topologie ein eher statischer Weg zur Definition von Geräten solange die Benutzer nicht Geräte auswechseln. Wenn die Position des Gerätes zu einer vom Benutzer gelieferten Einstellung passt wird der beiliegende Name verwendet.

Der vierte Schritt Statisch vergebener Name ist ein simpler String Ersatz. Wenn der Kernelname (der Standardname) zu einem gegebenen Ersatzstring passt, wird der Ersatzname stattdessen verwendet.

Der letzte Schritt (Vom Kernel gelieferter Name) ist ein "Allesfänger": Dieser nimmt den vom Kernel gelieferten Standardnamen. In den meisten Fällen ist dies ausreichend, da es zu der Gerätebenennung, welche auf momentanen Linuxsystem verwendet wird, passt.

libsysfs

udev interagiert mit dem Kernel durch das sysfs Pseudodateisystem. Das libsysfs Projekt liefert ein Standard API um auf die Informationen gegeben durch das sysfs Dateisystem in einem gängigen Verfahren zuzugreifen. Dies erlaubt eine Abfrage von aller Art von Hardware, ohne dass man Vermutungen über die Art der Hardware anstellen muss.

udev

Jedes Mal, wenn der Kernel ein Event in der Gerätestruktur bekommt, stellt er udev eine Anfrage, einen Blick darauf zu werfen. udev folgt den Regeln im Verzeichnis /etc/udev/rules.d/. Dann benutzt udev die vom Kernel gegebenen Informationen, um die notwendigen Aktionen (Erstellen oder Entfernen von Gerätedateien) an der /dev/ Struktur durchzuführen.

2.  udev unter Gentoo benutzen

Voraussetzungen

udev sollte in Verbindung mit einem 2.6 Kernel verwendet werden (wie gentoo-sources mit dem 2007.0 Standardprofil). Wenn Sie einen solchen Kernel verwenden, müssen Sie nur sicherstellen, dass Sie eine aktuelle Version von sys-apps/baselayout haben. Das ist alles was Sie benötigen.

Befehlsauflistung 2.1: Installieren von udev

 # emerge udev

Stellen Sie sicher, dass folgende Optionen im Kernel aktiviert sind:

Befehlsauflistung 2.2: Benötigte Kerneloptionen

File systems --->
    [*] Inotify file change notification support
    [*]   Inotify support for userspace
  Pseudo filesystems --->
    [*] /proc file system support
    [*] Virtual memory file system support (former shm fs)

Wenn Sie genkernel verwenden, müssen Sie nichts besonderes tun. Genkernel setzt udev standardmäßig auf.

Konfiguration

Wenn Sie, um Ihr Leben einfacher zu machen, die udev-Einstellungen, die Gentoo hinzugefügt hat, benutzen wollen, müssen Sie nicht weiterzulesen. Gentoo wird udev verwenden aber ein statisches /dev erhalten, damit Sie nie fehlende Device-Nodes haben werden. Die Gentoo init Skripte werden den devfsd Dämon nicht ausführen und werden devfs deaktivieren wenn Sie booten.

Wenn Sie aber ein zäher Kämpfer sind und ein nur-udev, nicht modifiziertes System verwenden wollen, so wie es von der udev Entwicklung vorgesehen wurde (einschließlich der Schwierigkeiten von fehlenden Device-Node-Dateien, da udev sie noch nicht untersützt), dann lesen Sie einfach weiter :)

Wir werden die Regeln deaktivieren, die die Device-Node-Dateien speichern: editieren Sie die RC_DEVICE_TARBALL Variable in /etc/conf.d/rc und setzen Sie diese auf no:

Befehlsauflistung 2.3: /etc/conf.d/rc

RC_DEVICE_TARBALL="no"

Wenn Sie devfs Unterstützung in Ihrem Kernel haben, können Sie es in Ihrer Bootloaderkonfiguration deaktivieren: Fügen Sie gentoo=nodevfs als Kernelparameter hinzu. Wenn Sie devfs verwenden wollen und udev deaktivieren wollen, dann fügen Sie gentoo=noudev als Kernelparamter hinzu.

3.  Bekannte Probleme

Fehlende Device-Node-Dateien beim booten

Wenn Sie nicht erfolgreich booten können, da Sie eine Fehlemeldung darüber erhalten, dass /dev/null nicht gefunden wurde oder weil die initiale Konsole fehlt, dann ist das Problem, dass Ihnen einige Gerätedateien fehlen, die verfügbar sein müssen, bevor /dev eingebunden ist und von udev verwaltet wird. Dies ist oft auf Gentoo-Rechnern, bei deren Installation alte Medien verwendet wurden, der Fall.

Wenn Sie sys-apps/baselayout-1.8.12 oder neuer laufen haben, dann ist dieses Problem bereits entschärft, da der Bootvorgang trotzdem komplett durchlaufen müsste. Um diese nervigen Warnungen loszuwerden sollten Sie die fehlenden Device-Nodes wie untenstehend beschrieben erstellen.

Um zu sehen, welche Device-Nodes vorhanden sind bevor das /dev Dateisystem eingebunden ist, führen Sie folgende Befehle aus:

Befehlsauflistung 3.1: Auflistung der Device-Nodes vorhanden zum Systemstart

# mkdir test
# mount --bind / test
# cd test/dev
# ls

Die für einen erfolgreichen Boot benötigten Device-Nodes sind /dev/null und /dev/console. Wenn Sie im vorangegangenen Test nicht vorhanden waren, dann müssen Sie diese manuell erstellen. Führen Sie folgende Befehle im zuvor erstellten test/dev/ Verzeichnis aus:

Befehlsauflistung 3.2: Erstellen notwendiger Device-Node-Dateien

# mknod -m 660 console c 5 1
# mknod -m 660 null c 1 3

Wenn Sie fertig sind, vergessen Sie nicht die Einbindung des test/ Verzeichnisses wieder zu lösen:

Befehlsauflistung 3.3: Lösen der Einbindung des test/ Verzeichnisses

# cd ../..
# umount test
# rmdir test

udev und nvidia

Wenn Sie auf einem nur-udev System den proprietären Treiber von nVidia verwenden und der X Server nicht gestartet werden kann, stellen Sie sicher, dass Sie Folgendes besitzen:

  • das nvidia Modul aufgeführt in /etc/modules.autoload.d/kernel-2.6
  • das Basislayout mit der Version sys-apps/baselayout-1.8.12 oder neuer

Keine einheitliche Namensgebung zwischen DevFS und udev

Obwohl es unsere Absicht ist ein einheitliches Namensschema für beide dynamischen Gerätemanagementlösungen zu haben, gibt es trotzdem manchmal Unterschiede in der Benennung.

Ein gemeldeter Konflikt existiert mit dem HP Smart Array 5i RAID Controller (genauer gesagt mit dem cciss Kernelmodul). Mit udev werden die Geräte als /dev/cciss/cXdYpZ benannt; wobei X,Y und Z reguläre Nummern sind. Mit devfs sind die Geräte /dev/hostX/targetY/partZ oder symbolisch verlinkt von /dev/cciss/cXdY.

Wenn dies der Fall ist, dann vergessen Sie bitte nicht /etc/fstab und die Bootloader Konfigurationsdateien entsprechend zu aktualisieren.

Dasselbe geschieht mit universellen symbolischen Links die in /dev existierten, wie /dev/mouse, welches udev nicht länger erstellt. Überprüfen Sie Ihre X Konfigurationsdatei und stellen Sie sicher, dass die Geräteregel für Ihre Maus auf ein existierendes Gerät verweist.

Ein weiteres Problem ist der Unterschied in der Benennung der Terminals zwischen devfs und udev. Während devfs die Terminals tty nennt, benennt udev sie vc und tty. Dies führt zu einem Problem, wenn Sie Root-Logins von der Konsole mit /etc/securetty einschränken. Sie werden sicherstellen müssen, dass sowohl tty1 als auch vc/1 in /etc/securetty aufgeführt werden um zu garantieren, dass root sich an der Konsole anmelden kann.

Umbenennen von Block Devices

Neuere Versionen von udev (104 und höher) zusammen mit einem neueren Kernel (2.6.19 und höher) könnten Ihre Plattengerätenamen, aufgrund einer Änderung der Implementation von libata im Kernel, ändern. Ein CD-RW-Gerät an /dev/hdc könnte zu /dev/sr0 geändert werden. Dies ist normalerweise kein Problem, allerdings könnte es für einige Anwendungen eines werden, falls diese an vordefinierten Orten nach den Geräten suchen. Zum Beispiel erwartet media-sound/rip die Laufwerke unter /dev/cdrom, was ein Problem wird, wenn Sie einen neueren Kernel benutzen und udev Ihr Gerät in /dev/cdrom1 umbenennt.

Um diese Probleme zu beheben, müssen Sie /etc/udev/rules.d/70-persistent-cd.rules bearbeiten und dem Gerät den richtigen Namen zuordnen.

Für weitere Informationen zum Schreiben von udev-Regeln, lesen Sie bitte Daniel Drakes Leitfaden.

Umbenennen von Netzwerkgeräten

Manchmal kann aus- und einstecken von Netzwerkgeräten (wie USB-WLAN-Karten) dazu führen, dass das Netzwerkgerät jedes Mal einen anderen Namen erhält, mit einer um eins erhöhten Nummer.

Wenn das passiert, sehen Sie wie wlan0 zu wlan1 zu wlan2 usw. wird. Das passiert, weil udev zusätzliche Regeln zu seiner Regeldatei hinzufügt, anstatt die schon existierenden Regeln neu zu laden. Da udev sein Regelverzeichnis mit Hilfe von inotify überwacht, benötigen Sie Inotify-Unterstützung in Ihrer Kernelkonfiguration:

Befehlsauflistung 3.4: Aktivieren von Inotify-Unterstützung im Kernel

File systems --->
    [*] Inotify file change notification support
    [*]   Inotify support for userspace

Jetzt wird udev die korrekten Namen für Ihre Netzwerkgeräte beibehalten.

udev lädt Module in nicht vorhersehbarer Reihenfolge

Manchmal lädt udev Module in unerwünschter, unvorhersehbarer oder anscheinend zufälliger Reihenfolge. Dies ist besonders für Systeme, die mehrere Geräte des selben Typs sowie Multimediageräte, haben. Dies kann die zugewiesene Nummer der Geräte betreffen; z.B. können Soundkarten dadurch ihre Nummern tauschen.

Es gibt einige Lösungen, um die Gerätenummern und/oder Modulladereihenfolge zu beheben. Idealerweise können Sie einfach Modulparameter verwenden, um Ihre gewünschte Gerätenummer anzugeben. Einige Module, z.B. ALSA, haben einen Parameter "index". Module, die diesen Parameter benutzen, können wie folgt gezeigt angepasst werden. Dieses Beispiel ist für ein System mit zwei Soundkarten. Die Karte mit einem Index von 0 wird als erste Karte ausgewiesen. Sobald die Parameter geändert sind, müssen die Modulkonfigurationsdateien aktualisiert werden.

Befehlsauflistung 3.5: Angeben von Modulparametern

# echo "option snd-ice1724 index=0" >> /etc/modprobe.d/alsa.conf
# echo "option snd-ymfpci index=1" >> /etc/modprobe.d/alsa.conf
# update-modules

Das obige Beispiel ist die bevorzugte Lösung, aber nicht alle Module unterstützen Parameter wie index. Für diese Module müssen Sie die korrekte Modulladereihenfolge erzwingen. Zuerst müssen Sie udev anweisen, diese Module nicht mehr länger automatisch zu laden, indem Sie sie "blacklisten". Stellen Sie sicher, dass Sie den exakten Namen des Moduls, das geladen wird, verwenden. Für PCI-Geräte müssen Sie die Modulnamen verwenden, die Sie aus Ausgabe des Befehls pcimodules, verfügbar im Paket pciutils, entnehmen. Das folgende Beispiel verwendet DVB-Module.

Befehlsauflistung 3.6: Blacklisten von Modulen

# echo "blacklist b2c2-flexcop-pci" >> /etc/modprobe.d/dvb
# echo "blacklist budget" >> /etc/modprobe.d/dvb
# update-modules

Als Nächstes laden Sie die Module in der richtigen Reihenfolge. Fügen Sie sie der Datei /etc/modules.autoload.d/kernel-2.6 in der exakten Reihenfolge, in der Sie sie geladen haben wollen hinzu.

Befehlsauflistung 3.7: Laden von Modulen in der richtigen Reihenfolge

# echo "budget" >> /etc/modules.autoload.d/kernel-2.6
# echo "b2c2-flexcop-pci" >> /etc/modules.autoload.d/kernel-2.6

Sonstige Probleme

Falls Device-Nodes nicht erstellt werden, wenn ein Modul aus /etc/modules.autoload.d/kernel-2.6 geladen wird, aber erscheinen, wenn Sie ein Modul manuell mit modprobe laden, dann sollten Sie versuchen sys-apps/baselayout-1.8.12 oder neuer zu installieren.

Unterstützung für die Framebuffer-Geräte (/dev/fb/*) ist im Kernel ab der Version 2.6.6-rc2 enthalten.

Für Kernel älter als 2.6.4 müssen Sie explizit Unterstützung für das /dev/pts Dateisystem einarbeiten.

Befehlsauflistung 3.8: Aktivieren des /dev/pts Dateisystems

File systems --->
  Pseudo filesystems --->
    [*] /dev/pts file system for Unix98 PTYs

4.  Ressourcen & Quellenangaben

Die udev Diskussion beim Linux Symposium (Ottawa, Ontario Kanada - 2003) geführt von Greg Kroah-Hartman (IBM Corporation) lieferte ein solides Verständnis der udev Anwendung.

Decibel's UDEV Primer ist ein detailliertes Dokument über udev und Gentoo.

Schreiben von udev Regeln vom Gentoo-Entwickler Daniel Drake ist ein exzellentes Dokument, um zu lernen, wie Sie Ihre udev-Installation verändern können.



Drucken

Seite aktualisiert 14. Mai 2010

Die Originalversion dieser Übersetzung wird nicht länger gepflegt

Zusammenfassung: Dieses Dokument erklärt was udev ist und wie Sie udev verwenden können, um Ihren Bedürfnissen zu entsprechen.

Sven Vermeulen
Autor

Gregorio Guidi
Mitarbeiter

Joshua Saddler
Bearbeiter

Jan Hendrik Grahl
Übersetzer

Tobias Heinlein
Übersetzer

Michael Münch
Übersetzer

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.