Upgrade Squeeze/Wheezy: MFC6490CW-Scanner ging nicht mehr

[Andreas O.]

Hallo,
habe soeben von Squeeze auf Wheezy das Upgrade durchgeführt.
Dabei konnte ich o. g. Brother Scanner als normaler User nicht mehr benutzen, obwohl dieser unter Squeeze einwandfrei funktionierte (als root ging es noch).
Konkret hatte ich die Fehlermeldung:

Code: Alles auswählen

Fehler beim Öffnen des Geräts 'Brother3:bus5;dev1': ungültiges Argument.

Obwohl die /etc/udev/rules.d/60-libsane.rules belassen wurde und ich auch noch den Eintrag

Code: Alles auswählen

brother3

in der /etc/sane.d/dll.conf
stehen hatte und mein User der Gruppe "scanner" angehörte, hatte ich immer noch ein Berechtigungsproblem.
Fündig bin ich schließlich im ArchWiki geworden:
ein

Code: Alles auswählen

lsusb

brachte bei mir:

Code: Alles auswählen

Bus 001 Device 004: ID 04f9:01f3 Brother Industries, Ltd

hervor.
Anschließend habe ich als root noch

Code: Alles auswählen

chmod a+w /dev/bus/usb/001/004

ausgeführt und ich konnte wieder als "normaler" User scannen.
Weiß hier jemand den Grund, warum durch das Upgrade plötzlich das Berechtigungsproblem aufgetreten ist und wie man das künftig automatisch beheben kann?

Ich hoffe, ich konnte hier jemandem mit einem ähnlichen Problem helfen.

Andreas

[rendegast]

die /etc/udev/rules.d/60-libsane.rules belassen wurde

Dann vergleiche die mal mit der
/lib/udev/rules.d/60-libsane.rules
aus wheezy auf Unterschiede

Bus 001 Device 004: ID 04f9:01f3 Brother Industries, Ltd

In der aus libsane:

Code: Alles auswählen

$ cat 60-libsane.rules | grep -i 04f9 -C1
...
# Pentax DSmobile 600
ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="2038", ENV{libsane_matched}="yes"
...

Was dann wohl auch der Grund für Deine separate Version ist (in squeeze war die vendor-Id gar nicht vertreten)
Und dieser hätte ich den Namen zBsp.
/etc/udev/rules.d/61-libsane.rules
gegeben, sodaß sie sich nicht eventuell gegenseitig ausschließen können.
Vom Inhalt her sollte sie dann (bis auf die ID-Liste) eine Kopie der systemeigenen sein.

Das Format,
in sqzeeze hatte der Eintrag sein MODE=,GROUP=,
in wheezy wird das am Ende erledigt:

Code: Alles auswählen

ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"

LABEL="libsane_rules_end"

vielleicht wird das "alte" Format nicht korrekt abgearbeitet?
Obwohl 'man udev'

OWNER, GROUP, MODE
The permissions for the device node. Every specified value overwrites the compiled-in default value.

[Andreas O.]

Hallo rendegast,

danke schon mal für deine Antwort.
Ich bin leider nur ein "einfacher" Linux-Anwender, so dass ich deinen Ausführungen nicht ganz folgen kann.
Was ich nun verstanden habe, dass sich bei udev zwischen squeeze und wheezy irgendwelche Änderungen ergeben haben, die scheinbar beim Upgrade nicht automatisch berücksichtigt wurden oder ich wurde vielleicht sogar gefragt, ob ich "meine" rule und nicht die des maintainers beibehalten will (was ja auch meistens Standard ist) und schon funktionierte mein Scanner zunächst nicht mehr als normaler User.
Jedenfalls kommt beim Booten nach wie vor eine Fehler/Hinweismeldung von udevd, dass es sich bei meiner ursprünglichen

Code: Alles auswählen

/etc/udev/rules.d/60-libsane.rules

nun um eine

invalid rule

handelt.
Am besten nun der Inhalt meiner ursprünglichen /etc/udev/rules.d/60-libsane.rules aus squeeze:

Code: Alles auswählen

#Debian Brother
SYSFS{idVendor}=="04f9", ATTR{idProduct}=="01f3" MODE="0666", GROUP="scanner", ENV{libsane_matched}="yes"

und nun die /lib/udev/rules.d/60-libsane.rules aus wheezy, wo ich zu meinem Brother nur das gefunden habe:

Code: Alles auswählen

# If your scanner is supported by some external backend (brother, epkowa,
# hpaio, etc) please ask the author of the backend to provide proper
# device detection support for your OS

Wenn man schon für "udev" irgendwelche neue Regeln erzeugen muss, warum kann man dann nicht "automatisch" die alten Regeln so abändern, dass diese kompatibel zum neuen Format sind und sich der einfache Anwender nicht auch noch manuell um diese Sache kümmern muss?
Die man-Seite zu udev bringt mich leider nicht wirklich weiter, wie ich schnellstmöglich zu einem funktionierenden Scanner gelange.
Heißt das nun im Klartext, dass ich nun auf Brother angewiesen wäre, dass diese eine gültige udev-Regel rausbringen?
Ich verstehe die ganze Sache einfach nicht mehr. Früher mit "hal" war alles viel einfacher und nun tun sich viele Linux-Distributionen auch noch "freiwillig" den Umstieg auf dieses proprietäre System "udev" an, das, soweit ich weiß, von Red Hat stammt, um sich immer abhängiger von einzelnen Firmen zu machen?
Zumindest gibt es ja scheinbar Hoffnung zu einem fork von udev namens eudev, das anfangs nur belächelt wurde. Wie sieht es damit unter Debian aus?
Kann man dieses schon anstelle udev benutzen?
Mich regt als einfacher Anwender einfach immer mehr auf, dass man ohne "Not" funktionierende Dinge immer komplizierter machen muss und dies dem Anwender dann als "Fortschritt" verkauft - Microsoft lässt hier grüßen-frei nach dem Motto: "it's not a bug, it's a feature"...

Sorry, diesen "Dampf" musste ich an dieser Stelle mal ablassen.
Also, wie kommt man als "normal" gebildeter User nun zu einer gültigen udev-Regel, ohne erst diverse man-Seiten und sonstige Bücher dazu studieren zu müssen?

Andreas

[guennid]

Was ich nun verstanden habe [ist], dass sich bei udev zwischen squeeze und wheezy irgendwelche Änderungen ergeben haben

Das machen die udev-Leute öfter mal, um User wie dich und mich auf Trab zu halten. Thorvalds hat solche Typen mal "Interface-Nazis" genannt und ich denke, da hat er den Nagel auf den Kopf getroffen.

wie kommt man als "normal" gebildeter User nun zu einer gültigen udev-Regel, ohne erst diverse man-Seiten und sonstige Bücher dazu studieren zu müssen?

Wahrscheinlich gar nicht, es sei denn, hier weiß jemand was Schlaues.

Na, war vielleicht doch nicht ganz verkehrt, mit dem Upgrade zu wheezy auf meinem Arbeitsrechner noch zu warten.

Mein Beileid, Günther

[NAB]

dass es sich bei meiner ursprünglichen

Code: Alles auswählen

/etc/udev/rules.d/60-libsane.rules

nun um eine

invalid rule

handelt.
Am besten nun der Inhalt meiner ursprünglichen /etc/udev/rules.d/60-libsane.rules aus squeeze:

Code: Alles auswählen

#Debian Brother
SYSFS{idVendor}=="04f9", ATTR{idProduct}=="01f3" MODE="0666", GROUP="scanner", ENV{libsane_matched}="yes"

Die Regel war schon unter Squeeze nicht mehr ganz frisch ... idVendor ist anscheinend inzwischen ganz aus dem SYSFS geflogen. Ich meine, davor wurde schon beim Upgrade auf Squeeze gewarnt.
Probier mal für

Code: Alles auswählen

/etc/udev/rules.d/60-libsane.rules

diese Regel:

Code: Alles auswählen

#Debian Brother
ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="01f3" MODE="0666", GROUP="scanner", ENV{libsane_matched}="yes"

Wenn man schon für "udev" irgendwelche neue Regeln erzeugen muss, warum kann man dann nicht "automatisch" die alten Regeln so abändern, dass diese kompatibel zum neuen Format sind und sich der einfache Anwender nicht auch noch manuell um diese Sache kümmern muss?

Das wäre natürlich fein und wäre in diesem Fall auch gar nicht so schwer ... aber generell kann das ziemlich nach hinten losgehen, wenn irgendein Installer versucht zu erraten, was der Anwender da in seiner Konfigurationsdatei bewerkstelligen wollte.

Heißt das nun im Klartext, dass ich nun auf Brother angewiesen wäre, dass diese eine gültige udev-Regel rausbringen?

Ja, natürlich. Frage bitte bei Brother nach, warum sie sich nicht an der Entwicklung von udev beteiligen ... sooo schwer ist es ja nun auch nicht, eine passende Regel zu basteln.

Ich verstehe die ganze Sache einfach nicht mehr. Früher mit "hal" war alles viel einfacher und nun tun sich viele Linux-Distributionen auch noch "freiwillig" den Umstieg auf dieses proprietäre System "udev" an, das, soweit ich weiß, von Red Hat stammt, um sich immer abhängiger von einzelnen Firmen zu machen?

Linux tut sich schwer mit der dynamischen Konfiguration von Geräten. Die riesige Datenbank von HAL fand ich nicht wirklich einfacher, und wäre es soooo eine gute Idee gewesen, würde HAL vermutlich noch existieren. Das Problem an udev ist, dass es eingesetzt wurde, lange bevor es einigermaßen ausgereift und konsistent war, gemäß dem Open-Source-Motto "wenn wir es nicht unter die Leute bringen, kriegen wir keine BugReports". Darum ändert sich logischer Weise noch was in udev, und die Regeln müssen angepasst werden.

Zumindest gibt es ja scheinbar Hoffnung zu einem fork von udev namens eudev, das anfangs nur belächelt wurde. Wie sieht es damit unter Debian aus?
Kann man dieses schon anstelle udev benutzen?

http://www.heise.de/open/meldung/Eudev- ... 96619.html