Archiv verlassen und diese Seite im Standarddesign anzeigen : Massenspeicher per udev erkennen?
[Dieser Beitrag war durch den Datenverlust am Server verlorengegangen. Ich setze ihn aus Dankbarkeit für nopes' wertvolle Anmerkungen wieder in verkürzter Form zusammen.]
Hallo beisammen,
unser gutes altes Smartphone mit SD-Karte wurde nach dem Anstecken per USB-Kabel von KDE seit Jahren immer ohne weiteres als Massenspeicher erkannt und von der „Geräteüberwachung“ (Device Notification von KDE) angeboten.
Vor einigen Monaten verschwand dieser Automatismus. Wir bemerkten eher zufällig, daß sich die Erkennung jedoch nachträglich triggern ließ, wenn man (was leider nur root möglich ist) "gparted" startete. Dieses scannt offenbar in irgendeiner Weise das System und löst dabei nachträglich die nötige "Magie" aus.
Leider funktioniert seit einigen Tagen auch das nicht mehr. Betroffen sind mehrere Rechner, so daß es wohl mit einem Update eines Systemprogramms (debian/testing) oder von KDE (inzwischen Version 4.13.1) zusammenhängt. Auf der Android-Seite hat sich garantiert bei Hard- und Software nichts verändert.
Die grundlegenden Vorgänge scheinen noch korrekt abzulaufen, denn nach dem Anstecken zeigt "tail -f /var/log/messages":
Jun 21 09:53:10 blechkumpan kernel: [...4.388081] usb 1-1.2: new high-speed USB device number 27 using ehci-pci
Jun 21 09:53:10 blechkumpan kernel: [...4.482618] usb 1-1.2: New USB device found, idVendor=12d1, idProduct=1037
Jun 21 09:53:10 blechkumpan kernel: [...4.482622] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 21 09:53:10 blechkumpan kernel: [...4.482625] usb 1-1.2: Product: Android Adapter
Jun 21 09:53:10 blechkumpan kernel: [...4.482627] usb 1-1.2: Manufacturer: Huawei Incorporated
Jun 21 09:53:10 blechkumpan kernel: [...4.482638] usb 1-1.2: SerialNumber: ...
Jun 21 09:53:10 blechkumpan kernel: [...4.483728] usb-storage 1-1.2:1.0: USB Mass Storage device detected
Jun 21 09:53:10 blechkumpan kernel: [...4.483864] scsi41 : usb-storage 1-1.2:1.0
Jun 20 15:17:23 blechkumpan usb_modeswitch: switch device 12d1:1037 on 001/027
So weit so gut, Hersteller- und Geräte-ID sind korrekt. Nur erscheint kein neues Blockgerät unterhalb von /dev/disk mehr. (Nach dem "Freigeben" des Massenspeichers auf der Android-Oberfläche erscheinen keine weiteren Linux-Systemprotokolleinträge.)
Immerhin fanden wir nach langem Herumprobieren, daß es schon reicht, den Treiber "usb_storage" neu zu laden:
/sbin/modprobe -r usb_storage
/sbin/modprobe usb_storage
Dieser Workaround taugt freilich auch nur, solange keine weiteren usb_storage-Geräte am Rechner hängen, war zunächst aber besser als nichts.
Da ja kein Blockgerät angelegt wird, würde ich ebenfalls bei udev ansetzen, siehe dazu auch hier (https://wiki.debian.org/DeviceManagement). Das erste was ich tun würde, Log nach udev Meldungen durchsuchen und ggf. das Log-Level von udev erhöhen, siehe dazu hier (http://unix.stackexchange.com/questions/36251/in-which-log-should-i-check-for-udev-errors).
Zum Thema udev und eigene Regeln empfiehlt sich dieses Wiki (https://wiki.debian.org/udev), wie sieht eure Regel denn aus? Falls ihr es mit RUN (http://reactivated.net/writing_udev_rules.html#external-run) probiert habt, war es die falsche Stelle, richtig ist meiner Meinung nach PROGRAM (http://reactivated.net/writing_udev_rules.html#external-naming).
hallo nopes,
wir haben mittlerweile versuchsweise eine Datei /etc/udev/rules.d/51-android.rules angelegt (Eigentümer:root, lesbar für alle) mit der einzigen Zeile:
SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", MODE="0666", GROUP="plugdev"
Was sich danach änderte, war, daß zwei Block devices erschienen (nämlich der interne Speicher des Smartphones und die SD-Karte):
UDEV [501.038346] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0/block/sdd (block)
UDEV [501.038382] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:2/block/sde (block)
UDEV [501.043141] change /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0/block/sdd (block)
UDEV [501.044182] remove /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0/block/sdd (block)
UDEV [501.044965] remove /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0 (scsi)
UDEV [501.051113] change /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:2/block/sde (block)
UDEV [501.051862] remove /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:2/block/sde (block)
... aber beide werden sofort im Anschluß wieder weggeräumt.
Vielleicht müssen wir also gar keine Regel hinzufügen, sondern eine bestehende auskommentieren bzw. ändern? (Zum Vergleichen mit früher haben wir natürlich leider nichts mehr.)
... was macht die Zeile?
Grundsatz zu den Operatoren: == ist ein PRÜFUNG, ob die Regel angewandt wird, während = ein ZUWEISUNG ist, also das was bei Anwendung der Regel passiert; eine Regel ist immer der Art PRÜFUNG+, ZUWEISUNG+
Wie auch immer, du hast zwei Prüfungen (SUBSYSTEM=="usb" und ATTR{idVendor}=="12d1") , dann zwei Zuweisungen (MODE="0666", GROUP="plugdev"), wenn die Regel triftft wird also der Dateizugriff gesetze (MODE) und die Gruppe bestimmt (GROUP). Was den Befehlen chmod und chgrp entspricht - für Details siehe hier (http://reactivated.net/writing_udev_rules.html#ownership).
Von der Sache her kannst du die Regel (falls die überhaupt greifen würde) entsprechend erweitern, also einfach neue Zuweisungen via ZUWEISUNG anhängen.
Wenn ich dann weiter drüber nachdenke, scheint euer USB System ja zu "bugggen", von daher vielleicht doch eher ',RUN+="CMD"' einfügen.
Im CMD könntest du Prüfen, ob das entsprechende Blockgerät existiert, wenn nicht halt die modprobe Kommandos usw. ausführen...
Sprich etwa so:
SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", MODE="0666", GROUP="plugdev", RUN+="/srv/my_scripts/check_if_usb_storage_needs_reload_and_do_it.sh"
Hallo nopes.
vielen Dank für die Anregungen! Mittlerweile habe ich das Ganze noch an zwei Ubuntu-Rechnern untersuchen können, an denen alles einwandfrei funktioniert. Es fällt auf, daß dort im Gegensatz zu Debian-Systemen keinerlei "modeswitch"-Ereignisse auftreten, wie oben bei Debian als
Jun 20 15:17:23 blechkumpan usb_modeswitch: switch device 12d1:1037 on 001/027
zu sehen.
Die "RUN+="-Zeile habe ich mit angepaßtem Inhalt ("echo $(date) >> /tmp/test.log") versucht, sie blieb aber ohne jeden Effekt.
Es kommt m.E. wohl eher drauf an, das (mir derzeit noch Unbekannte) zu verhindern, das den "modeswitch" unter Debian auslöst, statt per zusätzlicher Regeln das Ganze zu verschlimmbessern.
UDATE1
Langsam kommt ein wenig Licht ins Dunkel. Plötzlich erschien nämlich in /etc/udev/rules.d eine Datei "70-persistent-cd.rules" mit folgendem Inhalt:
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.
# Android_Adapter (pci-0000:00:1a.7-usb-0:2:1.0-scsi-0:0:0:1)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1a.7-usb-0:2:1.0-scsi-0:0:0:1", SYMLINK+="cdrom", ENV{GENERATED}="1"
# Android_Adapter (pci-0000:00:1a.7-usb-0:2:1.0-scsi-0:0:0:1)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_SERIAL}=="Huawei_Incorporated_Android_Adapter_CC96A0C3FBD3-0:1", SYMLINK+="cdrom1", ENV{GENERATED}="1"
UPDATE2
in der Datei /etc/usb_modeswitch.conf findet sich bei Debian die Zeile
DisableSwitching=0
Setzt man diesen Wert auf 1, so wird das Smartphone immerhin schon wieder mit seinen Blockgeräten (sdx, sdy) erkannt, es fehlen nur noch die Partitionen (d.h. Liste der Geräteüberwachung bleibt leer). Auch die oben erwähnte "70-persistent-cd.rules" wird zeitgleich vom System neu geschrieben. Ein Aufruf von "gparted" (als root) läßt dann auch wieder die Partitionen erscheinen - zumindest ein etwas besserer Workaround.
Bei Ubuntu 12.04 sieht /etc/usb_modeswitch.conf exakt aus wie bei Debian (DisableSwitching=0), also harrt die Stelle für das nötige Feintuning immer noch der Entdeckung, denn dort funktioniert ja alles wie ein Benutzer es erwarten würde.
UPDATE 3
Zwei weitere offenbar relevante Regeln stecken in /lib/udev/rules.d/40-usb-media-players.rules:
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1037|1038", ENV{ID_MEDIA_PLAYER}="huawei_ideos"
und in /lib/udev/rules.d/40-usb_modeswitch.rules:
# Generic entry for all Huawei devices
ATTRS{idVendor}=="12d1", ATTR{bInterfaceNumber}=="00", ATTR{bInterfaceClass}=="08", RUN+="usb_modeswitch '%b/%k'"
Während erste bei Ubuntu identisch ist (also nicht stören sollte), hat die zweite keine Ubuntu-Entsprechung, also keinen solchen generischen Eintrag, sondern nur zahlreiche gerätespezifische, darunter jedoch keinen für 1037 oder 1038.
Kaum kommentiert man letztere auf dem Debian-System aus, erscheinen auch tatsächlich die Blockgeräte:
UDEV [1050015.057403] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:0/scsi_disk/56:0:0:0 (scsi_disk)
UDEV [1050015.057693] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:0/scsi_generic/sg4 (scsi_generic)
UDEV [1050015.058741] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:0/bsg/56:0:0:0 (bsg)
UDEV [1050015.060412] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:1/scsi_generic/sg5 (scsi_generic)
KERNEL[1050015.061783] change /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:0/block/sdd (block)
UDEV [1050015.063166] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2 (scsi)
UDEV [1050015.064851] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2/scsi_disk/56:0:0:2 (scsi_disk)
UDEV [1050015.065901] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2/scsi_device/56:0:0:2 (scsi_device)
UDEV [1050015.066008] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2/bsg/56:0:0:2 (bsg)
UDEV [1050015.066108] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2/scsi_generic/sg6 (scsi_generic)
KERNEL[1050015.070671] change /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2/block/sde (block)
UDEV [1050015.073846] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:0/block/sdd (block)
UDEV [1050015.074457] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:1/block/sr1 (block)
"/org/freedesktop/UDisks2/drives/Huawei_Incorporated_Android_Adapter_CC96A0C3FBD3" has new interfaces: ("org.freedesktop.UDisks2.Drive")
UDEV [1050015.094046] add /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2/block/sde (block)
UDEV [1050015.100281] change /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:1/block/sr1 (block)
UDEV [1050015.102456] change /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2/block/sde (block)
UDEV [1050015.102585] change /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:2/block/sde (block)
UDEV [1050015.129124] change /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:0/block/sdd (block)
"/org/freedesktop/UDisks2/block_devices/sdd" has new interfaces: ("org.freedesktop.UDisks2.Block")
UDEV [1050015.158534] change /devices/pci0000:00/0000:00:1a.7/usb9/9-1/9-1:1.0/host56/target56:0:0/56:0:0:0/block/sdd (block)
"/org/freedesktop/UDisks2/drives/Huawei_Incorporated_Android_Adapter_CC96A0C3FBD3_1" has new interfaces: ("org.freedesktop.UDisks2.Drive")
"/org/freedesktop/UDisks2/block_devices/sr1" has new interfaces: ("org.freedesktop.UDisks2.Block")
"/org/freedesktop/UDisks2/drives/Huawei_Incorporated_Android_Adapter_CC96A0C3FBD3_2" has new interfaces: ("org.freedesktop.UDisks2.Drive")
"/org/freedesktop/UDisks2/block_devices/sde" has new interfaces: ("org.freedesktop.UDisks2.Block")
Eigentlich sieht das gar nicht so verkehrt aus. Die Preisfrage ist "nur" noch, wie man diese "org.freedesktop.UDisks2.Block"-Geräte dem Anwender zugänglich macht.
Naja es sollte udisks (https://packages.debian.org/de/jessie/udisks) für die weiteren Schritte verantwortlich sein. Also solltest du dem entsprechende DBus-Nachrichten beobachten können, wenn du das Gerät verbindest. Die Nachrichten Zeigt dir das Programm dbus-monitor bzw. etwas hübscher da grafisch d-feet (https://packages.debian.org/de/jessie/d-feet) an.
Falls du kein udisks installiert hast, würde es nun wohl reichen eine entsprechenden Link per udev zu setzen, den treffen tut ja wohl zumindestens diese generische Huawei Regel...
Es sind sogar zwei Pakete in der Richtung installiert: udisks und udisks2.
Nachdem ersteres sich ohne weitere Abhängigkeiten deinstallieren läßt
und Debian im Zusammenhang mit KDE zu udisks2 rät (http://debianforum.de/forum/viewtopic.php?f=2&t=146580), verzichte ich künftig darauf, um die Dinge einfach zu halten.
Jetzt geht es noch darum herauszufinden, was normalerweise geschieht, wenn die bereits genannten Regeln greifen und die Blockgeräte erstellt sind.
(Leider komme ich wohl erst nächste Woche dazu, damit weiterzumachen...)
Lies mal das hier (http://forums.debian.net/viewtopic.php?t=104661#p543947) durch. Da werden gleich mehrere Lösungen vorgeschlagen:
udev polling aktivieren
Kernel polling aktivieren
sysv durch systemd ersetzen
udev Regel für udisks2 fixen (/lib/udev/rules.d/80-udisks2.rules), da werden wohl einige Geräte verborgen
Mit etwas Glück hast du da den Schuldigen - ich würde übrigens auf die Regel tippen, evt gepaart mit dem Polling, da man bei Androiden ja anschließend noch den Massenspeicher aktivieren muss....
Wunderbar! - Nach einem
# cat /sys/module/block/parameters/events_dfl_poll_msecs
0
# echo 2000 > /sys/module/block/parameters/events_dfl_poll_msecs
funktionierte endlich wieder alles.
Anders als zuvor treten jetzt nach dem Freigeben des Massenspeichers auf Android-Seite folgende weitere Ereignisse auf:
KERNEL[6185.954308] change /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/host10/target10:0:0/10:0:0:0/block/sde (block)
KERNEL[6185.962294] change /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/host10/target10:0:0/10:0:0:0/block/sde (block)
KERNEL[6185.962404] add /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/host10/target10:0:0/10:0:0:0/block/sde/sde1 (block)
UDEV [6186.050048] change /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/host10/target10:0:0/10:0:0:0/block/sde (block)
UDEV [6186.094651] change /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/host10/target10:0:0/10:0:0:0/block/sde (block)
UDEV [6186.184092] add /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/host10/target10:0:0/10:0:0:0/block/sde/sde1 (block)
und die gewohnten Desktop-Automatismen (z.B. die Geräte-Benachrichtigung von KDE (http://techbase.kde.org/Projects/Plasma/Plasmoids#Device_Notifier)) laufen ab.
Kernel Polling mag vielleicht nicht die eleganteste Lösung sein - das legt nämlich die Tatsache nahe, daß auch der erwähnte Ubuntu-Referenzrechner, auf dem alles wie erwartet funktioniert, wie Debian ebenfalls events_dfl_poll_msecs = 0 hat. Aber es scheint keine auffälligen negativen Begleiterscheinungen zu bewirken, und das Problem ist vom Tisch.
Dickes Danke an nopes!
Letzte Anmerkung dazu:
Ob Kernel, oder udev bzw. Userland Polling ist eigentlich egal (stimme dir aber zu, statt stumpf immer zu pollen, ist ein gezieltest pollen, nun ja gezielt eben und damit effizienter). Aber das fehlende Polling dürfte die Ursache sein, von daher falls mal einer drüber stolpert, erstmal prüfen, ob es damit nicht erledigt ist...
Ansonsten gilt: never touch a running system ;)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.