(gelöst) Canon Lide 25 mit Eigenbaukern nur root-Betrieb

[guennid]

Der USB-Scanner war vorher an einer anderen Maschine angeschlossen und funktionierte. Auf der aktuell benutzten Maschine arbeitet er reibungslos mit wheezy-Standard-Kern 3.2.0. Mit meinem selbstgebauten 3.10.15 funktioniert er nicht. Er wird mit dem Eigenbaukern von lsusb, sane-find-scanner ind scanimage -L gelistet. Beim Einstecken liefert dmesg:

Code: Alles auswählen

usb 3-1: new full-speed USB device number 3 using uhci_hcd

Beim 3.2.0er sagt dmesg dagegen:

Code: Alles auswählen

[   32.232112] usb 4-1: new full-speed USB device number 2 using uhci_hcd
[   32.400164] usb 4-1: New USB device found, idVendor=04a9, idProduct=2220
[   32.400286] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   32.400410] usb 4-1: Product: CanoScan
[   32.400479] usb 4-1: Manufacturer: Canon

Hier fehlt/fehlen doch ein Modul/Module, welche(s)?

Grüße, Günther

[DeletedUserReAsG]

Nein, da fehlt kein Modul. uhci_hcd ist schon ein Passendes, der Rest liegt an der udev- und/oder Sane-Konfiguration.

[guennid]

Hmmm,

Bist du da wirklich sicher?

Unter /udev/rules.d/ finde ich in keiner Datei eine Regel, die ich mit dem Scanner in Verbindung bringen würde. Bei der Scanner-Software bin ich nur mit xsane vertraut - und das findet keine Geräte, da kann ich also nichts konfigurieren. Wieso unterscheiden sich die dmesg-Meldungen, wenn beide Kerne in Ordnung sind?
Schau auch mal hier, da scheint's auch ein Kern-Problem zu sein.

Grüße, Günther

[DeletedUserReAsG]

Ich kann dir nur sagen, dass die Liste der geladenen Module vor dem Anstecken und nach dem Anstecken exakt gleich ist. Und dass ich auf meinem Arch mit 3.13 auch „nur“ die Meldung bekomme, die du da hast, und es funktioniert.

[guennid]

Du hattest wieder mal recht. xsane arbeitet - als root. Der user ist nach wie vor in der Gruppe scanner, aber für ihn findet xsane keinen. Das alte ~/.sane hatte ich vor dem Versuch weggesichert.

Und wieso darf dieser User mit 3.2.0 aber mit 3.10.15 nicht??? Ist der Kern an dieser Stelle buggy??? Rätsel über Rätsel???

Grüße, Günther

[KBDCALLS]

Und was ist mt einem aktuellen Kernel aus den Backports ?

[guennid]

Um den geht's mir nicht. Der originale (3.2.0) tut ja. Ich will einen selbstgebauten nutzen.
Hier habe ich was gefunden, was für mich auf kernel-bug hindeutet. Keine Ahnung ob das auch debian-relevant ist und ich verstehe auch nicht alles - zu englisch.
Ich kompilier mir jetzt mal einen 12er. Mal sehen wie's dann ausschaut.

Grüße, Günther

[KBDCALLS]

Der Bug hat bestimmt nichts mit dem Problem zu tun. Es ging drum das der Scanner nicht gefunden wurde . Es sei denn man hat sane-find-scanner als Root aufgerufen. Ich habe den Kernel aus den Backports vorgeschlagen , damit man auschließen kann das es am Kernel liegt. Wenn der funktioniert, dann kann man ja immer noch einen selber backen.

PS: Der größte Teil des Rules-geraffel findet man unter /lib/udev/rules.d

[dirk11]

Du hattest wieder mal recht. xsane arbeitet - als root. Der user ist nach wie vor in der Gruppe scanner, aber für ihn findet xsane keinen. Das alte ~/.sane hatte ich vor dem Versuch weggesichert.
Und wieso darf dieser User mit 3.2.0 aber mit 3.10.15 nicht??? Ist der Kern an dieser Stelle buggy??? Rätsel über Rätsel???

Ein ähnliches Thema hatten wir glaube ich schonmal, und ebenso glaube ich mich zu erinnern, das die Gruppe scanner nicht ausreicht. netdev war wohl auch noch ein Kandidat, wo der User Mitglied sein musste.

[smutbert]

Die Gruppe plugdev erschiene mir einleuchtender.

[dirk11]

Die Gruppe plugdev erschiene mir einleuchtender.

Richtig, die war's. War unterwegs, konnte nicht nachschauen. Bei mir ist für' Scannen in der /etc/group sowas:

Code: Alles auswählen

plugdev:x:46:dirk
saned:x:110:dirk
scanner:x:101:saned,dirk

[guennid]

In plugdev ist er doch auch drin, mein user.

Es ist ein Kern-Problem. Nachdem ein Eigenbau-Kern 3.12.15 die gleichen Probleme zeigte, habe ich KDBDCALLS Vorschlag mit dem backports-Kern realisiert. Der tut, wie auch der wheezy-Standard.

Beim Installieren des backport-Kerns unter laufendem Eigenbaukern fiel mir auf, dass gemeckert wurde über fehlenden device-mapper. Unter dem Standard-Kern (3.2.0) wurde das nicht angemeckert. Ich habe keine Ahnung von RAID und LVM, aber wenn ich menuconfig trauen darf, dann brauche ich diesen device-mapper nicht.

Keine Ahnung, ob das was mit dem sane-Problem zu tun hat.

Hier ist die config des 3.12.15er Eigenbau-Kerns.

Grüße, Günther

[guennid]

Vielleicht kommt man des Rätsels Lösung näher durch Beschäftigung mit udev.
Bei den Ubuntus lese ich:

Falls sich USB-Scanner nur als root verwenden lassen, kann es helfen, in der Datei /lib/udev/rules.d/50-udev-default.rules den Eintrag 0664 auf 0666 im libusb device nodes-Abschnitt abzuändern.

Wovon sprechen die? Ist das für Debian irrelevant?

Der komplette Inhalt dieser Datei sieht bei mir so aus:

Code: Alles auswählen

# virtio serial / console ports
KERNEL=="vport*", ATTR{name}=="?*",     SYMLINK+="virtio-ports/$attr{name}"

SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id"

# RTC on some architectures
SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos",          SYMLINK+="rtc"

# /dev/sndstat
SUBSYSTEM=="module", KERNEL=="snd", ACTION=="add", \
        RUN+="/bin/ln -sf /proc/asound/oss/sndstat $root/sndstat"

Aber wie dem auch sei: Das Problem muss doch darin liegen, dass die Standard Kerne Einstellungen für das Scannen vornehmen, die meine selbstgebauten nicht vornehmen.

Frage ist: Welche Einstellungen sind das? Und warum werden die nicht eingestellt?

Und noch 'ne Frage: Müsste udev unter /dev eine Gerätedatei erstellen? Welche müsste udev erstellen?

Ich sehe da nichts bei mir, mit keinem Kern.

Und hier noch was:

Code: Alles auswählen

dmesg | grep usb

3.2 Standard:

Code: Alles auswählen

[    0.703053] usbcore: registered new interface driver usbfs
[    0.703145] usbcore: registered new interface driver hub
[    0.718582] usbcore: registered new device driver usb
[    1.052110] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.052174] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.052247] usb usb1: Product: EHCI Host Controller
[    1.052308] usb usb1: Manufacturer: Linux 3.2.0-4-amd64 ehci_hcd
[    1.052370] usb usb1: SerialNumber: 0000:00:1a.7
[    1.053116] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    1.053184] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.053261] usb usb2: Product: UHCI Host Controller
[    1.053324] usb usb2: Manufacturer: Linux 3.2.0-4-amd64 uhci_hcd
[    1.053387] usb usb2: SerialNumber: 0000:00:1a.0
[    1.054251] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    1.054319] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.054394] usb usb3: Product: UHCI Host Controller
[    1.054459] usb usb3: Manufacturer: Linux 3.2.0-4-amd64 uhci_hcd
[    1.054523] usb usb3: SerialNumber: 0000:00:1a.1
[    1.076108] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002
[    1.076172] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.076246] usb usb4: Product: EHCI Host Controller
[    1.076307] usb usb4: Manufacturer: Linux 3.2.0-4-amd64 ehci_hcd
[    1.076369] usb usb4: SerialNumber: 0000:00:1d.7
[    1.077261] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    1.077328] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.077402] usb usb5: Product: UHCI Host Controller
[    1.077465] usb usb5: Manufacturer: Linux 3.2.0-4-amd64 uhci_hcd
[    1.077528] usb usb5: SerialNumber: 0000:00:1d.0
[    1.078311] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[    1.078375] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.078450] usb usb6: Product: UHCI Host Controller
[    1.078514] usb usb6: Manufacturer: Linux 3.2.0-4-amd64 uhci_hcd
[    1.078577] usb usb6: SerialNumber: 0000:00:1d.1
[    1.716027] usb 2-1: new full-speed USB device number 2 using uhci_hcd
[    1.886119] usb 2-1: New USB device found, idVendor=0a5c, idProduct=2110
[    1.886184] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    1.886248] usb 2-1: Product: BCM2045B
[    1.886307] usb 2-1: Manufacturer: Broadcom Corp
[    2.128032] usb 3-1: new full-speed USB device number 2 using uhci_hcd
[    2.300256] usb 3-1: New USB device found, idVendor=04a9, idProduct=2220
[    2.302125] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.302190] usb 3-1: Product: CanoScan
[    2.302253] usb 3-1: Manufacturer: Canon
[    9.158580] usbcore: registered new interface driver btusb
[   13.125655] usbcore: registered new interface driver usbserial
[   13.131850] usbcore: registered new interface driver usbserial_generic
[   13.134831] usbserial: USB Serial Driver core
[   13.156474] usbcore: registered new interface driver option
[   13.515328] usbcore: registered new interface driver usb-storage

3.10.15 Eigenbau:

Code: Alles auswählen

usbcore: registered new interface driver usb-storage
usb 3-1: new full-speed USB device number 2 using uhci_hcd
usb 4-1: new full-speed USB device number 2 using uhci_hcd
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver option
usbserial: USB Serial support registered for GSM modem (1-port)

[guennid]

So, ein Stück weiter bin ich jetzt, dank diesem link. scanimage -L als root liefert unter dem selbstgebauten Kern

Code: Alles auswählen

device `plustek:libusb:003:002' is a Canon CanoScan LiDE25 flatbed scanner

.
Als user kommt nur, dass kein Gerät gefunden wurde. Mit dem strace-Kram bin ich nicht wirklich zurechtgekommen. Das diff gab immer noch eine ellenlange Ausgabe, die vollständig zu verstehen ich außerstande bin. Aber immerhin: ich habe mir die Rechte von /dev/bus/usb/003/002 angesehen: root/root. Das habe ich geändert auf root/scanner, und schon konnte der User scannen.

Gleiche Ausgabe mit scanimage -L unter backports-Kern 3.12, sowohl als root, als auch als user. Rechte: dito.

Demgemäß könnte man dem Misstand wohl mit einer udev-Regel abhelfen. Wie könnte die aussehen? Mit der, die im Link angegeben wird, funktioniert es, angepasst auf meine Verhältnisse, hier nicht.

Und davon ab: Wieso stört sich xsane beim Standard-Kern nicht an root/root für die Gerätedatei, wohl aber bei meinem selbstgebauten?

Grüße, Günther

[smutbert]

zu deiner letzten Frage: meines Wissens kann man auf zwei Arten auf USB-Geräte zugreifen:
- einerseits über die Gerätedatei, das funktioniert nur wenn sich ein Gerätetreiber im Kernel zuständig fühlt.
- ohne Gerätedatei über libusb. Dazu darf allerdings glaube ich kein Gerätetreiber (mehr?) geladen sein.

Also würde ich vermuten, dass im neuen Kernel ein Gerätetreiber ist, der sich für den Scanner zuständig fühlt. Ganz verrückte Idee:

Starte den Computer ohne angeschlossenen Scanner und speichere die Ausgabe von

Code: Alles auswählen

lsmod

Schließe den Scanner an und vergleiche die Ausgabe von lsmod mit der von vorher und blackliste das neu dazugekommene Modul mit einer Datei in /etc/modprobe.d/, die

Code: Alles auswählen

blacklist Modulname

enthält. Damit die initrd nicht dazwischenfunken kann (bei einem Scannertreiber allerdings sehr unwahrscheinlich), mache ich in so einer Situation immer noch ein

Code: Alles auswählen

update-initramfs -u

Nach einem Neustart sollte das Modul nicht mehr geladen werden und der Zugriff über libusb vielleicht (!) wieder wie zuvor funktionieren.
(Bei manchen sane-Treibern musst man vielleicht die Zugriffsart in der passenden Datei in /etc/sane.d/????, in diesem Falle also libusb usb oder [usb] oä aktivieren und/oder den Zugriff über die Gerätedatei deaktivieren, aber wenn ohnehin nur mehr eine Möglichkeit zur Verfügung steht, dürfte das in den meisten Fällen nicht mehr notwendig sein)

[guennid]

Der lsmod-Vergleich mit dem 3.12.bpo (mit und ohne Scanner-Verbindung) brachte keine Unterschiede.

Was deinen Ausdruck "neuer kernel" betrifft, da verstehen wir uns wohl miss: Davon zu sprechen macht wenig Sinn. Beide zu betrachtende Kerne sind "neu". Der eine ist selbstgebaut (3.10), der andere ist von bpo (3.12). Nur mit dem bpo-Kern darf ein User scannen. Ein Vergleich der lsmod-Ausgaben bei diesen beiden Kernen macht keinen Sinn, da die Modulkonfiguration sich ganz wesentlich unterscheidet. Sinn machen würde sie meines Erachtens nur, wenn man das Modul/die Module kennte, das/die man sucht. Womit aber wieder lsmod an sich redundant würde. Da müsste man dann die configs betrachten.

Das hier könnte ich mir als weiterführend vorstellen:

- einerseits über die Gerätedatei, das funktioniert nur wenn sich ein Gerätetreiber im Kernel zuständig fühlt.
- ohne Gerätedatei über libusb. Dazu darf allerdings glaube ich kein Gerätetreiber (mehr?) geladen sein.

Aber wie schalte ich einen "Gerätetreiber" (ich nehme an du meinst das Kern-Modul) ab, wenn ich nicht weiß welche(n/s)? Oder ist uhci_hcd gemeint? Der ist auf jeden Fall beteiligt.


Grüße, Günther

[KBDCALLS]

Ohne die Hostreiber dürfte es wohl mit dem Scanne problematisch werden.

Wird wohl nichts anderes übrigbleiben . Die Configs der Kernel miteinander zu vergleichen.

Code: Alles auswählen

hid                    94034  2 hid_generic,usbhid
usbcore               154175  4 ehci_hcd,ehci_pci,usbhid,xhci_hcd
usb_common             12440  1 usbcore

[smutbert]

Ja, uhci_hcd darfst du nicht deaktivieren und entschuldige das Durcheinander mit „altem“ und „neuen“ Kernel. Irgendwie ist mir sowieso nicht klar welcher Treiber die Erzeugung der Gerätedatei veranlaßt, früher gab es ein Kernelmodul scanner, aber das gibt's ja schon lange nicht mehr.


Ich hätte jedenfalls das gleiche wie KBDCALLS vorgeschlagen. Nachdem es sich womöglich um eine USB-Option dreht und die Kernelkonfigurationen ja üblicherweise in /boot liegen, könntest du einmal mit (die Namen der config-Dateien musst du gegebenenfalls anpassen)

Code: Alles auswählen

comm -3 <(sort <(grep -i usb /boot/config-3.12-0.bpo.1-amd64)) <(sort <(grep -i usb /boot/config-3.10-Eigenbau))

die Unterschiede der Kernelkonfigurationen anzeigen lassen, die etwas mit USB zu tun haben. Die Ausgabe erfolgt eigentlich in 3 Spalten, wobei die erste Spalte nur Zeilen enthält, die auschließlich in der ersten (bpo) Konfiguration auftauchen, die zweite Spalte nur Zeilen, die nur in der zweiten Kernelkonfiguration auftauchen und die dritte Spakte schließlich Zeilen enthält, die in beiden Konfigurationen auftauchen - diese dritte blenden wir mit -3 aus, weil sie eher uninteressant sein dürfte.
(Wobei ich allerdings zugeben muss nicht die geringste Idee zu habe, welche Kerneloption solche Auswirkungen haben könnte…)

[guennid]

Ich muss das noch mal aufmachen, denn eine befriedigende Lösung habe ich immer noch nicht.
Ich habe zwar mittlerweile herausgekriegt/nachvollzogen, dass die Ursache des Problems, dass der User nicht scannen kann, die ist, dass nur root/root in der vom Kern angelegten Gerätetatei (dev/bus/[nr]/[nr] lesen und schreiben darf. Ändere ich das auf root/scanner (User ist in Gruppe scanner), dann darf der User scannen. Eine Dauerlösung ist das nicht.

1. Bei meinem momentanen Kenntnisstand sehe ich mich zwar in der Lage, mir eine udev-Regel zu schreiben, möchte das aber erstmal nicht, sondern herauskriegen, ob und wenn ja, wie, udev hier bei Verwendung des Standard-Kerns dafür sorgt, dass der User scannen darf. Was muss ich dafür tun?

2. Ob das folgende von Belang ist, weiß ich noch nicht.
lsusb sagt:

Code: Alles auswählen

Bus 003 Device 003: ID 04a9:2220 Canon, Inc. CanoScan LIDE 25

scanimage -L sagt:

Code: Alles auswählen

device `plustek:libusb:003:003' is a Canon CanoScan LiDE25 flatbed scanner

In /lib/udev/rules.d/60-libsane.rules taucht 049a Nur bei den "Regeln"? für die Canon-Scanner auf, bei den Plustek-Scannern nicht. Was will mir das "plustek" in der scanimage-Ausgabe sagen?

Grüße, Günther

[smutbert]

Das plustek will dir sagen, dass "plustek" das Backend also gewissermaßen der Treiber von sane ist, der verwendet wird. In der manpage von sane-plustek findest du eine Liste von Scannern, die von plustek unterstützt werden und da sind u.a. einige Canons dabei.

Was liefert denn scanimage -L mit dem anderen Kernel?

[guennid]

Was liefert denn scanimage -L mit dem anderen Kernel?

mit Standard-Kern 3.2.0 im Grunde das Gleiche:

Code: Alles auswählen

device `plustek:libusb:003:002' is a Canon CanoScan LiDE25 flatbed scanner

Die Rechte auf die Gerätedatei sind hier ebenfalls root/root, aber wie schon gesagt, mit diesem Kern kriegt der User mit scanimage den Scanner genannt und kann auch mit xsane druckern. Mit Eigenbau-Kern 3.10.15 geht beides nur als root, außer, wenn ich die Rechte für die Gerätedatei wie o.a. ändere.

Grüße, Günther

[KBDCALLS]

Und mal mit dem 3.16 versucht? Aus den Wheezy Backports?

[guennid]

Und mal mit dem 3.16 versucht? Aus den Wheezy Backports?

Den 3.14er aus den backports hatte ich letztens versucht. Same proceddure wie 3.2.0-Standard. Aber das ist ja nicht das Problem. Mit jedem von mir verwendeten Standardkern funktioniert alles, wie es soll. Nur mit selbstgebauten nicht und ich will eigentlich nur wissen, wieso. Bei den Modulen finde ich keinen Unterschied und bei den Rechten für die Gerätedatei auch nicht.

Wie gesagt, ich könnte mir wohl mit einer Udev-Regel helfen, aber erstmal will ich wissen, warum das so ist, wie es ist.

Grüße, Günther

[smutbert]

Mein Verdacht war oder ist, dass der Treiber mit dem alten Kernel nicht über die Gerätedatei sondern anders auf den Scanner zugreift — aber dass die Ausgabe von scanimage -L fast genau gleich aussieht, vor allem das plustek:libusb, paßt nicht so recht zu meinem Verdacht. Offensichtlich ist außerdem meine Annahme, dass Zugriffe über libusb gar nicht über Gerätedateien gehen überholt. Also etwas anderes…


Du hast doch auch diese Zeile am Ende der /lib/udev/rules.d/60-libsane.rules

Code: Alles auswählen

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

Ich denke, die soll der Gruppe Scanner mittels ACL für alle Gerätedateien, an deren Ende ein Scanner hängt, Lese- und Schreibrechte verleihen. Die Ausgabe von

Code: Alles auswählen

getfacl /dev/bus/[nr]/[nr]

sowohl für den neuen, wie auch den alten Kernel könnte also auch recht interessant sein.

[guennid]

Vielleicht ist der Übeltäter identifiziert. getfacl brachte zunächst nur "Datei oder Verzeichnis nicht gefunden" sowohl mit Eigenbau- als auch mit Standard-Kern. Dann habe ich gesucht, was das eigentlich ist und wurde auf das Paket acl verwiesen. Das ist zwar installiert, aber wenn ich dem hier trauen darf, dann muss bei mir zumindest CONFIG_EXT3_FS_POSIX_ACL im Kern aktiviert sein, und genau das ist es nicht, wohl aber beim Standard-Kern. Und wo wir schon mal dabei sind und der Kern neugebaut wird: so langsam wird's wohl Zeit das System auf ext4 zu heben. Hab' ich schon mal nach gefragt, aber wieder vergessen. Ihr könntet meine Suche abkürzen, wenn ihr mir gleich sagen könnt, wie das geht.

Grüße, Günther