nitsnatsnok
Anmeldungsdatum: 27. Oktober 2013
Beiträge: 160
|
aasche schrieb: Ich habe die letzten Aenderungen von nitsnatsnok wieder rueckgaengig gemacht, da in keinster Weise ersichtlich ist, ob diese fuer die als getestet angegebenen Ubuntu-Version 12.04 und 10.04 zutreffen.
Kubuntu 12.04, Kernel 3.2.0-58-generic-pae i686 - bitte entschuldige, hätte ich diese Information im Kommentar mit angeben sollen? Der Mountbefehl im Skript dürfte für alle Kernelversionen nötig sein, da automount offenbar erst nach der Ausführung eines via udev-Regel ausgeführten Skripts erfolgt. Bei der Angabe des Mountbefehls habe ich lediglich die im selben Artikel unter "Einhängen eines Dateisystems" gegebenen Befehle genutzt - logischerweise reicht der Befehl "mount /dev/backup" nicht aus, wenn man nicht vorher einen entsprechenden fstab-Eintrag dafür erstellt hat, was im Artikel aber nirgendwo erwähnt wird (angenommen, man liest ihn von oben nach unten).
|
aasche
Anmeldungsdatum: 30. Januar 2006
Beiträge: 14259
|
nitsnatsnok schrieb: bitte entschuldige, hätte ich diese Information im Kommentar mit angeben sollen?
Das Problem haengt damit zusammen, dass der Artikel lt. Kopf fuer zwei Ubuntu-Version (10.04, 12.04) Gueltigkeit haben soll. Und ich war unsicher, ob es nach Deinen Aenderungen auch noch mit 10.04 funktioniert (was Du ja nicht ueberpruefen kannst).
Kubuntu 12.04, Kernel 3.2.0-58-generic-pae i686
ok, dann handhaben wir das ganze pragmatisch:
ich stelle Deine Aenderungen wieder her und entferne 10.04 aus der Liste der getesteten Versionen (hier wird sich vermutlich niemand mehr finden, der es ueberprueft)
Das Kernproblem ist, dass immer wieder gut gemeinte Aenderungen im Wiki stattfinden, die auf Grundlage entweder einer lt. Kopf gar nicht getesteten Version oder durch Loeschen der fuer Vorgaenger-Versionen weiterhin zutreffenden Information vorgenommen werden. Das wollte ich bei einem sowieso schon komplexen Thema wie udev ausschliessen. Danke fuer Deine Rueckmeldung ☺
|
nitsnatsnok
Anmeldungsdatum: 27. Oktober 2013
Beiträge: 160
|
Wunderbar, ich hab dazugelernt und werd zukünftig drauf achten - danke für deine Geduld! 😉
|
lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
Ich habe einen neuen Abschnitt "udev-Regel für das Entfernen eines Gerätes" hinzugefügt. Dabei habe ich mich am bisherigen Aufbau des Artikels orientiert. Wenn ich dabei gegen Wiki-Konventionen verstoßen habe, entschuldige ich mich, aber ich habe nicht die Ruhe, den Abschnitt ggf. zu überarbeiten. Sollte dies nötig sein, wäre es schön, wenn sich jemand anderes dafür fände. Sonst könnt ihr den Abschnit aber auch einfach wieder entfernen.
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 636
Wohnort: Hannover
|
Neustart des udev-Systems: Der Befehl
funktioniert bei mir nicht, aber stattdessen sudo service udev restart Und bei Euch?
|
aasche
Anmeldungsdatum: 30. Januar 2006
Beiträge: 14259
|
linux_joy schrieb: Und bei Euch?
Das wird von der Ubuntu-Version anhaengen. Getestet ist der Artikel mit 12.04.
|
klaushipp
Anmeldungsdatum: 4. September 2010
Beiträge: Zähle...
|
UDISK_PRESENTATION_HIDE glaube ich nicht mehr aktuell. Bei mir geht es zumindest nicht. Als Alternative kann UDISK_IGNORE gesetzt werden, hat den gleichen Effekt. Kann das jemand bestätigen?
Ich ergänze das dann gerne.
|
aasche
Anmeldungsdatum: 30. Januar 2006
Beiträge: 14259
|
klaushipp schrieb: UDISK_PRESENTATION_HIDE glaube ich nicht mehr aktuell. Bei mir geht es zumindest nicht. Als Alternative kann UDISK_IGNORE gesetzt werden, hat den gleichen Effekt. Kann das jemand bestätigen?
Womit bestaetigen? Wie bereits oben erwaehnt, ist der Artikel bisher nur mit Ubuntu 12.04 getestet. Daher eine Ergaenzung bitte immer mit Angabe der zugrundeliegenden Ubuntu-Version vornehmen und keine scheinbar veralteten Angaben loeschen (da Ubuntu 12.04 im Wiki als LTS-Version eine wichtige Rolle spielt).
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6472
|
linux_joy schrieb: Neustart des udev-Systems: Der Befehl
funktioniert bei mir nicht, aber stattdessen sudo service udev restart Und bei Euch?
$ sudo reload udev
$ echo $?
0 tut. Kubuntu 14.04
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28954
Wohnort: WW
|
Hallo, tut's genau so unter Ubuntu 14.04 Gruß, noisefloor
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28954
Wohnort: WW
|
Hallo, ich bin ja normal eher gegen "getestet: generel" Markierungen - aber hier im udev-Artikel spricht viel dafür. Oder sieht jemand irgendwas im Artikel, was wirklich nur unter einer *buntu-Version funktioniert? Gruß, noisefloor
|
Cordess
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
Ich habe zum udev Artikel ein paar Fragen: 1. Laut dem Abschnitt Funktionstest kann man mit dem Befehl
| sudo udevadm info --root --query=symlink --name=/dev/GERÄTEDATEI_ODER_SYMLINK
|
herausfinden, welche Gerätenamen in /dev/ für ein bestimmtes Gerät noch so alles angelegt wurden. Allerdings scheint der Befehl in der Praxis keine Funktion zu haben.
So zeigt bspw. bei mir der Aufruf von
| sudo udevadm info -r -q symlink -n /dev/input/event4
|
nur eine leere Zeile an, obwohl es noch bspw. mindestens die Gerätedateien
/dev/input/js0 /dev/input/mouse2 /dev/hidraw3
für dieses Gerät gibt. Ob es noch weitere gibt, das würde ich gerne herausfinden. Mit dem Befehl scheint das aber nicht zu funktionieren. 2. Können Regeldateien auch mit 3 stelligen Zahlen beginnen?
Falls nein, dann sollte man das im Artikel vielleicht noch eindeutiger erwähnen.
Im Artikel steht zwar im Abschnitt udev-Regeln folgendes:
| Die einzelnen Regeldateien beginnen mit einer zweistelligen Zahl und werden in alphanumerischer Reihenfolge abgearbeitet.
|
das sagt aber nichts darüber aus, ob auch dreistellige Zahlen gehen würden oder ob diese ignoriert werden. 3. Können Regeldateien mit der gleichen Zahl beginnen, wenn der Rest unterschiedlich ist? Laut /lib/udev/rules.d/ eines aktuellen Ubuntu LTS Systems scheint das zwar zu gehen,
aber das sollte man eventuell im Artikel noch erwähnen das man das machen kann.
In welcher Reihenfolge dann die rules Dateien abgearbeitet werden, wenn die Zahlen identisch sind, könnte man in dem Artikel auch noch aufnehmen. Ich kenne die Antwort dazu leider nicht, falls jemand das weiß, kann er das aber gerne sagen.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Zu Frage 2 und 3: Aus der Manpage zu udev:
The udev rules are read from the files located in the system rules directory /usr/lib/udev/rules.d, the volatile runtime directory /run/udev/rules.d and the local administration directory /etc/udev/rules.d. All rules files are collectively sorted and processed in lexical order, regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc have the highest priority, files in /run take precedence over files with the same name in /usr/lib. This can be used to override a system-supplied rules file with a local file if needed; a symlink in /etc with the same name as a rules file in /usr/lib, pointing to /dev/null, disables the rules file entirely. Rule files must have the extension .rules; other extensions are ignored.
Es ist also egal, ob es eine Nummer vor der Regel gibt, wie viele Stellen sie hat usw. (Nummerierung ist ein leichter Weg um eine Reihenfolge herzustellen, wobei du beachten musst, das nur nach alphabetischer Reihenfolge sortiert wird, daher brauchst du zweistellige Nummern, wenn du eine Regel zwischen vom System vorgegebenen udev-Regeln positionieren willst) - was zählt, ist dass sie die Endung .rules hat und ob sie durch gleichnamige oder nachfolgende Regeln übersteuert wird. Zur Frage 1: bist du sicher, dass die genannten Geräteknoten Symlinks auf /dev/input/event4 sind? Ich würde eher vermuten, dass da ein USB-Gerät mehrere Endpunkte anbietet, für die jeweils eigenständige Geräteknoten angelegt werden. Mit lsusb -vvv sollte man das sehen können.
|
Cordess
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
seahawk1986 schrieb: Zu Frage 2 und 3:
Danke für die Antwort, dann wäre das geklärt.
Zur Frage 1: bist du sicher, dass die genannten Geräteknoten Symlinks auf /dev/input/event4 sind? Ich würde eher vermuten, dass da ein USB-Gerät mehrere Endpunkte anbietet, für die jeweils eigenständige Geräteknoten angelegt werden. Mit lsusb -vvv sollte man das sehen können.
Ich denke du hast recht, mein Fehler.
geht in dem Fall allerdings nicht, da es sich um ein Bluetoothdevice handelt. Momentan habe ich die Devicedateien durch einen recht umständlichen Weg herausgefunden, in dem ich per
mir erst einmal alles was in der udev drin steht, ausgeben lassen habe.
Anschließend habe ich nach der BT Adresse (vergleichbar einer MAC) gesucht, durch diese hatte ich dann einige sysfs Devicepfade.
An denen ich mich dann via
| udevadm info -a -p DEVICEPFAD
|
herunterhangeln konnte um diese wiederum aufzuschreiben. An die Gerätedateien kam ich dann, in dem ich jeden einzelnen aufgeschriebenen sysfs Devicepfad der zu dem BT Gerät passte in folgende udevadm Abfrage packte:
| udevadm info --query=all -p DEVICEPFAD | grep DEVNAME
|
Also mehr oder wenig recht umständlich. Das Problem ist nur, mit dem Befehl:
fand ich dann noch heraus, dass die Ausgabe von udevmadm monitor noch ganz andere Devicepfade ausgibt, wenn ich das BT Gerät bediene. Devicepfade die sich mit der BT Adresse vorher nicht finden ließen.
Und die mir bereits bekannten Devicepfade, von denen ich Ausgaben erwartete, lieferten gar nichts.
Warum, das suche ich momentan herauszufinden, eventuell kann der generische Treiber "hid-generic" damit wohl nichts anfangen und udevadm monitor bleibt daher stumm. Ich muss also davon ausgehen, dass es noch weitere Gerätedateien und Devicepfade für dieses BT Eingabegerät gibt, die mir noch nicht bekannt sind.
|
GukkDevel
(Themenstarter)
Anmeldungsdatum: 5. November 2007
Beiträge: 14
|
Kurze Information, bei 18.04 ist /etc/udev/ leer auch unter /lib/udev/ fehlt z.B. die angesprochene Zuordnung der Netzwerkkarten.
|