staging.inyokaproject.org

aasche schrieb:

BillMaier schrieb:

Der Teil Nutzung in der grafischen Oberfläche scheint mir recht alt zu sein. Ich kann davon jedenfalls nichts in Lucid finden.

Ich kann das so bestätigen. Gibt es hier Widerspruch? Sonst fliegt der Teil raus.

Da Kontinuitaet ein Fremdwort fuer die Nautilus-Entwickler ist, kann der Absatz zu Nautilus raus. Aber das Beispiel "Musiksammlung" sollte unabhaengig davon funktionieren. Ich wuerde aber vorschlagen, diesen Teil als Unterartikel Banshee/Externe Musiksammlung auszulagern.

Schöner Vorschlag. +1

/edited: Kannst Du das übernehmen?

Hab mal den Vergleich mit Windows entfernt. Die Hardware-Erkennung unter Windows hat bei mir nie funktioniert und ich habe sie somit in schlechter Erinnerung. Udev funktioniert meist...

wow, vielen Dank. Da hab ich ja wieder Arbeit. 👍

elektronenblitz63 schrieb:

Hallo,
zur Ergänzung.

Udev Events abfragen/protokollieren

udevadm monitor --property
udevadm monitor --kernel 
udevadm monitor --udev 

udev-Regeln auf Fehler hin prüfen:

udevadm test *.*
# oder
udevadm test /etc/udev/rules.d/<eigene_Regel>.rules 

(Wildcard kann auch durch Angabe der erzeugten Regel ersetz werden / es werden alle Regeln, auch die in ~/lib/udev/rules.d geprüft)

Beispiele für udev-Regeln:
Ethernet MAC-Changer
Laptop Docking-Event
Tx-Power bei WLAN-Sticks
Device-Switcher für WLAN-Karten (muss ich aktuell mal erneut testen)

seahawk1986 schrieb:

Berlin 1946 schrieb:

Hier stellt sich die Frage, warum sind die interessant ❓

Weil man auf die Kriterien in einer udev-Regel matchen lassen kann.

Berlin 1946 schrieb:

Hier einen Text- Vorschalg:

Hier sind vor allem die Zeilen idVendor, idProduct und iSerial interessant.

Einfügen:

Aus diesen Zeilen werden die Werte idVendor = 0ab4, idProduct = 0685a und iSerial =ABCDEF01234 benötigt, um die udev- Regeln schreiben zu können. (siehe unten)

Was haltet Ihr davon:

"Hier sind vor allem die Zeilen idVendor, idProduct und iSerial interessant, da sie sich aufgrund ihrer Eindeutigkeit relativ gut für eine udev-Regel verwenden lassen."

Mal sehen, vielleicht fällt mir noch was besseres ein. Kommt ja immer auch auf den Zusammenhang an. Und soweit bin ich im Artikel noch nicht fort geschritten.

noch treffender:

"Hier sind vor allem die Zeilen idVendor, idProduct und iSerial interessant, da sich ihre Werte aufgrund ihrer Eindeutigkeit relativ gut für eine udev-Regel verwenden lassen."

Halloelektronenblitz63

udev-Regeln auf Fehler hin prüfen:

udevadm test *.*
# oder
udevadm test /etc/udev/rules.d/<eigene_Regel>.rules 

Entweder stimmt hier was nicht, oder ich stehe ordentlich auf dem Schlauch.

udevadm test /etc/udev/rules.d/70-persistent-net.rules 

(oder jede vergleichbare andere) ergibt:

Nach dem Test aller Regeln in /lib/udev/rules.d endet der Test mit:

unable to open device '/sys/etc/udev/rules.d/70-persistent-net.rules'

Die Zeile wird natürlich angewendet, sonst könnte ich diese Zeilen nicht abschicken. Dasselbe gilt für eigene Regeln. Getestet unter 10.04 und 12.04. Hier bräuchte ich nochmal Hilfe.

Hi,

das wäre ja zu einfach, wenn man mit dem Kommando direkt eine .rules-Datei prüfen könnte 😉.

udevadm test erwartet als Argument einen Gerätenamen unterhalb /sys und zwar ohne das führende /sys. Beispiel:

sudo udevadm test /class/net/eth0

Es wird dann geprüft, welche Rules zutreffen. Weitere Options stehen in der Manpage.

aha. Danke.

Mal eine Frage in die Runde:

"Der Punkt ACTION=="add" sorgt dafür, dass die Regel nur zutrifft, wenn das Gerät neu angeschlossen wird. Anderenfalls würde das auszuführende Skript nach Beenden sofort automatisch erneut gestartet werden."

Das kann ich so nicht bestätigen. Bei mir läuft das Skript einmal durch und gut ist. Der Unterschied muss also entweder veraltet sein oder woanders liegen. Wer weiß was?

BillMaier schrieb:

Bei mir läuft das Skript einmal durch und gut ist.

Welches Skript?

BillMaier schrieb:

Mal eine Frage in die Runde:

"Der Punkt ACTION=="add" sorgt dafür, dass die Regel nur zutrifft, wenn das Gerät neu angeschlossen wird. Anderenfalls würde das auszuführende Skript nach Beenden sofort automatisch erneut gestartet werden."

Das kann ich so nicht bestätigen. Bei mir läuft das Skript einmal durch und gut ist. Der Unterschied muss also entweder veraltet sein oder woanders liegen. Wer weiß was?

Wenn du keine spezielle ACTION angibst, gilt die Regel für jedes udev-Event (also z.B. auch beim Entfernen "remove" oder bei "change").

Grundsätzlich würde ich versuchen eine Regel explizit zu schreiben, d.h. genau den gewünschten Anwendungsfall einzugrenzen statt auf ein erwartetes Verhalten zu hoffen.

linrunner schrieb:

BillMaier schrieb:

Bei mir läuft das Skript einmal durch und gut ist.

Welches Skript?

Ich dachte, das wird aus dem Kontext klar. Es geht um ein Skript, das durch eine UDEV-Regel mit

RUN+=/pfad/skript

gestartet wird. (Bei mir schreibt das Skript einfach eine Notiz in eine Textdatei.)

seahawk1986 schrieb:

Wenn du keine spezielle ACTION angibst, gilt die Regel für jedes udev-Event (also z.B. auch beim Entfernen "remove" oder bei "change").

Genau das kann ich eben nicht verifizieren:

Ich habe einmal das

ACTION=="add"

weg gelassen, was aber nichts an der Ausführung durch Anstecken (in dem Fall des USB-Sticks) ändert. Beim Abziehen wird das Skript definitiv nicht ausgeführt.

Hier meine Konfiguration:

#/etc/udev/rules.d/71-stick.rules 
#Stick mit Klappmechanismus - zum Test für UDEV
#
SUBSYSTEMS=="usb", KERNEL=="sd?1", ATTRS{serial}=="9350B4D3", SYMLINK+="bummbumm", RUN+="/usr/local/bin/bumm"

#!/bin/bash
# File: /usr/local/bin/bumm
echo "bummbumm" >> /home/meins/bummbumm.txt

In das File "bummbumm" wird nur beim Anstecken des Skripts Sticks geschrieben. Beim Abziehen passiert nichts.

Grundsätzlich würde ich versuchen eine Regel explizit zu schreiben, d.h. genau den gewünschten Anwendungsfall einzugrenzen statt auf ein erwartetes Verhalten zu hoffen.

Also immer

ACTION=="add"

zu verwenden, wenn es darum geht, die Regel beim Anstecken zu verwenden oder remove beim Abziehen oder wasweißich. Und nicht stattdessen davon auszugehen, dass die Regel schon machen wird, was zufällig einmal funktioniert hat. War das so gemeint?

Ich möchte im Artikel die Eindeutigkeit der Regeln und der Filter hervorheben. Da passt das glaub ganz gut.

vielen Dank noch Euch beiden.