[Problem] usb Devices werden nach Freetz-Installation nicht mehr erkannt

[PeterPawn]

Ok, das ist ein 'lsusb -vs' (der zusätzliche Pfad wird offenbar ignoriert), bei Dir also schon mal das richtige lsusb.

Wenn das allerdings ein lsusb mit geladenen storage-Treibern (also sd_mod, usb_storage - der scsi_mod müßte über Dependencies automatisch geladen werden) ist, dann fehlen da die USB-Geräte. Dann braucht der udev auch keine Treiber zu laden, wenn da keine Geräte existieren. Warum die USB-Basis-Treiber die Enumeration nicht hinbekommen (da patcht ja niemand dran herum), ist dann allerdings unklar.

Nochmal die Empfehlung, bei aktiven "udevadm monitor" ein Speichergerät an die Box anzustecken und das Protokoll dabei anzusehen ... in der Telnet-Console vor dem udevadm noch ein "setconsole" machen und auch die interessanten Passagen aus "dmesg" nicht auslassen nach dem Anstecken.

Ein "rmmod" zuviel kann es aber wohl schon mal nicht sein, das einzige der drei Module, das sich wirklich entladen läßt (beim Rest hat AVM das vermutlich rausgepatcht), ist sd_mod ...

EDIT: Auf alle Fälle sind das aber wohl in weiten Teilen dann doch zwei unterschiedliche Probleme mit denselben Symptomen, aber zumindest teilweise unterschiedlichen Ursachen ... insofern bin ich unsicher, ob man die nicht besser trennen sollte (schon damit spätere Leser nicht durcheinander kommen).

 

[Al_]

@PeterPawn (2014-12-07 19:58 )
Ein guter Start, dass Du die Treiber als geladen identifizieren konntest. An zwei lsusb scheint es jedoch nicht zu liegen, ich finde auf der FritzBox nur eines:

root@Juerg:/var/mod/root# find / -name lsusb
/sbin/lsusb
root@Juerg:/var/mod/root#

 

[gismotro]

EDIT: Auf alle Fälle sind das aber wohl in weiten Teilen dann doch zwei unterschiedliche Probleme mit denselben Symptomen, aber zumindest teilweise unterschiedlichen Ursachen ... insofern bin ich unsicher, ob man die nicht besser trennen sollte (schon damit spätere Leser nicht durcheinander kommen).

OK, dann lassen wir diesen Thread mal für AL_ Ich wolle ja hier nur helfen. Mein Prob ist nicht so wichtig bzw. können wir später ja noch suchen.

 

[PeterPawn]

An zwei lsusb scheint es jedoch nicht zu liegen, ich finde auf der FritzBox nur eines

War eine Vermutung samt Begründung, mehr nicht ...

Wenn Du in einer Telnet-Session ein "setconsole" machst und anschließend den USB-Speicher verbindest, was erscheint dann dort ? Und was erscheint bei angeschlossenem Speicher bei Dir bei "lsusb -vs" ?

 

[Al_]

lsusb -vs zeigt nach dem Einstecken des USB Sticks zusätzlich folgendes (ganze Ausgabe vor/nach Einstecken: Anhang anzeigen fresh-boot_lsusb_2014-12-08.txtAnhang anzeigen usb-plugged_lsusb_2014-12-08.txt); die Bezeichnungen (VID, PID, SNUM) werden richtig erkannt, also gleich wie auf dem Desktop.

43a44,62
> New device on line 24
> Dev #2 on bus #1
> Interface 0, class 08, subclass 06
> BUS=001
> DEV=002
> VID=0011
> PID=7788
> CLS=00
> SCL=00
> SPEED='hi'
> VER='2.0'
> MANU='Generic'
> PROD='Mass Storage'
> SNUM='AF28982F'
> ISOC=0
> INUM=1
> ICLS1=08
> ISCL1=06

setconsole während des Einsteckens des USB Sticks (angehängt; wobei die erste Zeile "sh[1170] ..." bereits vor dem Einstecken erschien: Anhang anzeigen setconsole_2014-12-08.txt) sagt "No space left on device" für /dev und Unterverzeichnisse. Ich habe deshalb noch mit df den freien Platz anzeigen lassen:

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                13056     13056         0 100% /
tmpfs                    54692      1828     52864   3% /var
dev                      54692        16     54676   0% /dev
/var/dev/nand           524288     30852    493436   6% /var/media/ftp

Platz hat es also noch. Aber in /dev hat es schon sehr viele Einträge; "# ls -l | wc -l" ergibt 13488! Die meisten heissen loop.. mit einer vierstelligen Zahl (z.B. loop2786). Wieviele inodes kann /dev beinhalten? "df -i" funktioniert leider nicht in Freetz. Komisch ist auch, dass " ls -l loop* | wc -l" 13330 ausgibt, also mehr als es vierstellige Zahlen gibt.

 

[PeterPawn]

Ich habe deshalb noch mit df den freien Platz anzeigen lassen:

Es kann auch sein, daß da einfach keine freien inodes mehr vorhanden sind.

Auf jeden Fall liegt da schon mal ein Problem, in /dev sollten < 200 Dateien (bzw. special files für char- oder block-Devices) stehen und keinesfalls mehr als 8 Loop-Devices (0-7).

Eigentlich werden loop-Devices nur benötigt, um in Image-Form vorliegende Dateisysteme zu verwenden. Da kommt normalerweise ja nur das root-Filesystem einer 7390 (squashfs) in Frage und warum dafür dann so viele loop-Devices angelegt werden, erschließt sich mir erst einmal nicht ... das ist entweder schon ein Build-Error oder bei Mounten irgendeines Dateisystems geht etwas schief.

Wie sieht denn das /dev-Verzeichnis auf dem Build-System aus (build/modified/filesystem/dev) ?

Wenn da noch alles in Ordnung ist, mußt Du wohl doch mal eine Übersicht machen und am besten mal die Basisgeräte für die ausufernden Device-Sammlungen ermitteln.

Also: df hattest Du ja schon, ein "mount" bzw. "cat /proc/mounts" wäre auch nicht schlecht - zusammen mit einem "ps w", falls da noch ein Prozess läuft, der irgendwelche Mounts ständig wiederholen will.

Immer nur dann, wenn nicht schon vor dem mksquashfs das /dev-Verzeichnis voll ist, denn dann liegt der Fehler schon irgendwo im Build-System und man muß auf der Box nicht weiter suchen ...

 

[Al_]

Ein grosser Schritt weiter, siehe zuunterst in diesem Eintrag. Vielen Dank!

Doch zuerst die Ausgabe der von Dir angegebenen Befehle. Das Problem mit inodes wollte ich mit df -i suchen, aber diese Option hat df auf Freetz offenbar nicht. Im build-Verzeichnis auf dem Desktop hat es nicht so viele Dateien in dev:

/var/chroot/precise/freetz-devel/build/modified/filesystem/dev$ ls
adsl_mon          avm_net_trace132  avm_net_trace138  avm_net_trace160  capi20      loop0  loop6  mtd11  mtd3  mtd9        mtdblock13  mtdblock5  null    tty    ttyS1
avm_net_trace0    avm_net_trace133  avm_net_trace139  avm_net_trace161  console     loop1  loop7  mtd12  mtd4  mtdblock0   mtdblock14  mtdblock6  ptmx    tty0   urandom
avm_net_trace128  avm_net_trace134  avm_net_trace140  avm_net_trace162  kdsld_misc  loop2  mem    mtd13  mtd5  mtdblock1   mtdblock15  mtdblock7  pts     ttyp0  zero
avm_net_trace129  avm_net_trace135  avm_net_trace141  avm_net_trace163  kmem        loop3  mtd0   mtd14  mtd6  mtdblock10  mtdblock2   mtdblock8  random  ttyp1
avm_net_trace130  avm_net_trace136  avm_net_trace142  bme               led         loop4  mtd1   mtd15  mtd7  mtdblock11  mtdblock3   mtdblock9  rtc     ttyp2
avm_net_trace131  avm_net_trace137  avm_net_trace143  caldata           log         loop5  mtd10  mtd2   mtd8  mtdblock12  mtdblock4   new_led    tiatm   ttyS0

mount und cats /proc/mounts auf der FritzBox:

root@Juerg:/var/mod/root# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
proc on /proc type proc (rw)
tmpfs on /var type tmpfs (rw)
dev on /dev type tmpfs (rw,nosuid)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,mode=600)
/var/dev/nand on /var/media/ftp type yaffs2 (rw,sync)
usbfs on /proc/bus/usb type usbfs (rw)
root@Juerg:/var/mod/root# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / squashfs ro 0 0
proc /proc proc rw 0 0
tmpfs /var tmpfs rw 0 0
dev /dev tmpfs rw,nosuid 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,mode=600 0 0
/var/dev/nand /var/media/ftp yaffs2 rw,sync 0 0
usbfs /proc/bus/usb usbfs rw 0 0

Und ps w:

root@Juerg:/var/mod/root# ps w
  PID USER       VSZ STAT COMMAND
    1 root      1296 S    init
    2 root         0 SW<  [kthreadd]
    3 root         0 SW<  [ksoftirqd/0]
    4 root         0 SW<  [watchdog/0]
    5 root         0 SW<  [events/0]
    6 root         0 SW<  [khelper]
    7 root         0 SW<  [async/mgr]
    8 root         0 SW<  [CPMAC workqueue]
    9 root         0 SW<  [kblockd/0]
   12 root         0 SW<  [kswapd0]
   13 root         0 SW<  [aio/0]
   14 root         0 SW<  [nfsiod]
   22 root         0 SWN  [avm_debugd]
   23 root         0 SW<  [pm_info]
   24 root         0 SW<  [mtdblockd]
   27 root         0 SW<  [rpciod/0]
   28 root         0 SW<  [l2tp]
   29 root         0 SW   [tffsd_mtd_0]
   84 root         0 SW<  [cleanup_timer_f]
  211 root         0 SW<  [yaffs-bg-1]
  223 root         0 SW   [pdflush]
  225 root         0 SW<  [capi_pipew/0]
  226 root         0 SW<  [pcmlink_ctrl]
  227 root         0 SW<  [capitransp]
  230 root         0 RW<  [avm_dect_thread]
  421 root      1020 S <  /sbin/udevd --daemon
  427 root      1296 S    {busybox} tail -f /nohup.out
  444 root         0 SW<  [khubd]
  454 root      3736 S    aurad
  543 root      1020 S <  /sbin/udevd --daemon
  576 root      2364 S    /bin/configd
  662 root      8828 S    /usr/bin/vdsld ats
  665 root      3820 S    /usr/sbin/dsl_monitor -d
  682 root         0 SW   [pdflush]
  770 root      2604 S    avmipcd
  773 root      4196 S    l2tpv3d
  780 root     15820 S    /usr/bin/avm/ctlmgr
  784 root      8356 S    upnpd
  822 root      3892 S    multid
  835 root      2784 S    upnpdevd
  847 root      2700 S    wland -B
  919 root      5704 S    pbd
 1007 root      5732 S    telefon a127.0.0.1
 1008 root      1296 S    telnetd -l /sbin/ar7login
 1063 root      5816 S <  voipd
 1141 root       924 S    /bin/run_clock -c /dev/tffs -d
 1578 root      1292 S    {busybox} httpd-webcfg -P /var/run/webcfg.pid -p 81 -c /mod/etc/webcfg.conf -h /usr/mww/ -r Freetz
 1752 root      1292 S    {busybox} inetd
 2242 root      1296 S    init
 3425 root      1156 S    hostapd -B /etc/wpa2/WSC_ath0.conf
 3872 root      1156 S    hostapd -B /etc/wpa2/WSC_ath1.conf
 4327 root      1204 S    /sbin/chronyd -n -f /var/tmp/chrony.conf
23529 root         0 SW<  [scsi_eh_0]
23530 root         0 SW<  [usb-storage]
23537 root      1020 S <  /sbin/udevd --daemon
23611 root      1312 S    -sh
23650 root      1296 R    {busybox} ps w

Dann löschte ich mit "rm /dev/loop99*" einige der loop devices; zumindest innerhalb von einigen Minuten sind sie nicht wieder entstanden. Und: der USB Stick mounted sich beim einstecken! Wie aber erreiche ich, dass sich diese vielen loop Devices nicht bei jedem boot wieder bilden?

 

[PeterPawn]

Dann löschte ich mit "rm /dev/loop99*" einige der loop devices; zumindest innerhalb von einigen Minuten sind sie nicht wieder entstanden. Und: der USB Stick mounted sich beim einstecken! Wie aber erreiche ich, dass sich diese vielen loop Devices nicht bei jedem boot wieder bilden?

Das ist die eigentliche Frage. Irgendetwas im Bootvorgang legt diese Devices an ...

Ich würde als erstes mal probieren, die Freetz-Modifikationen nicht starten zu lassen und dann schauen, ob die Freetz-Änderungen am AVM-Teil der Firmware sich schon so auswirken oder ob es erst eine der Freetz-Modifikationen ist, die den Effekt hervorruft.

Es gibt da meines Wissens (zumindest gab es sie mal) eine Moglichkeit, über einen zusätzlichen Kernel-Parameter im Urlader-Environment die Freetz-Modifikationen komplett abzuschalten. Ich weiß den Wert aktuell nicht ... wenn Du ihn nicht selbst findest, kann ich aber auch mal suchen.

Findet sich eigentlich in dmesg ein Hinweis, wo und wann die ganzen Devices erzeugt werden ?

Ansonsten fiele mir nur noch ein, daß man wohl die inotifytools auch mit einem GUI und der Möglichkeit, den gesamten Bootvorgang zu dokumentieren, verwenden kann ... auch das habe ich auch nur mal nebenbei irgendwo gelesen. Ich selbst verwende nur inotifywait als statisch gelinktes Binary ... diese Protokollierung wird vermutlich mit inotifywatch arbeiten und irgendwohin eine Ausgabedatei schreiben.

Es wäre aber auch eine Möglichkeit, das Anlegen der Dateien zu loggen und dann anhand des Kontextes (keine Ahnung, ob da nur der Dateiname oder auch eine PID oder der Name des Prozesses protokolliert wird) die fragliche Stelle näher zu identifizieren.

Ansonsten fehlt mir ein wenig die Phantasie, wie dieses Problem entstehen kann ... da müßte ja eine Schleife über irgendwelche Mount-Vorgänge laufen und das auch noch für ein Filesystem in einem Image. Eine solche Stelle wäre mir ad hoc (zumindest in der AVM-Firmware) nicht geläufig, in den Freetz-Modifikationen bin ich nicht so sehr zuhause, wie im AVM-Code. Daher würde ich auch erst einmal - wie oben schon geschrieben - die Fehlersuche in Segmente aufteilen.

EDIT: Ich habe dann doch noch einmal nach dem Parameter zum "Abschalten" von Freetz gesucht, Du findest die Erläuterung dazu hier: http://freetz.org/wiki/help/fritz_faq#HilfedieBoxisttotalverkonfiguriertFreetzNot-AUS
Sollte Deine Box dort schon andere notwendige Einträge haben (der Wert annex=x ist meines Wissen - basierend auf AVM-Code - nicht noch einmal explizit notwendig, wenn der annex-Eintrag im Environment schon den richtigen Wert hat), müßtest Du den resultierenden Wert natürlich entsprechend anpassen. Die Abschaltung über S99-zzz-rcmod müßte - zumindest dem Augenschein nach - aber in Freetz immer noch integriert sein. Da bei Dir das System auf der Box ja noch startet, brauchst Du die Kopfstände mit dem Setzen von Parametern über EVA nicht machen und kannst direkt aus dem System heraus mit "echo" ins Urlader-Environment schreiben.

 

[Al_]

Vielen Dank für die weiteren Tipps.

• Mit dmesg habe ich auf die Schnelle nicht gefunden, wo die loop devices angelegt werden.
• kernel_args ds_off=y hat keinen Einfluss auf die Anzahl /dev Einträge

Was mir noch aufgefallen ist: die Einträge sind unmittelbr nach dem booten noch nicht (alle) da, sondern es enstehen etwa 5000 Einträge pro Minute bis das Maximum (13507) erreicht ist.

root@Juerg:/var/mod/root# date ; ls /dev -l | wc -l
Tue Dec  9 23:52:38 CET 2014
4691
root@Juerg:/var/mod/root# date ; ls /dev -l | wc -l
Tue Dec  9 23:52:44 CET 2014
5099
root@Juerg:/var/mod/root# date ; ls /dev -l | wc -l
Tue Dec  9 23:52:52 CET 2014
5597
root@Juerg:/var/mod/root# date ; ls /dev -l | wc -l
Tue Dec  9 23:53:00 CET 2014
6147
root@Juerg:/var/mod/root# date ; ls /dev -l | wc -l
Tue Dec  9 23:53:48 CET 2014
9618

Mit 'lsof /dev/loop*' kam nie eine Antwort. Möglicherweise geht das Anlegen der /dev/loop* so schnell, dass lsof immer den kurzen Moment verpasste, während der gesuchte Prozess noch auf den inode zugriff.
Wie inotifywatch und inotifywait weiterhelfen können, sehe ich nicht. Soweit ich die man pages verstehe, geben sie zurück, dass etwas passierte in einem Verzeichnis, aber nicht welcher Prozess. 'inotifywait -e create /dev' ergibt '/dev/ CREATE loop7387' (natürlich mit aufsteigenden Zaheln bei weiderholtem Befehl). Was sonst noch im /dev Verzeichnis passiert: 'inotifywait /dev' (also ohne Beschränkung auf CREATE) ergibt '/dev/ ACCESS ptmx'.
Mit 'losetup /dev -a' versuchte ich herauszufinden, ob während der ersten paar Minuten nach dem booten (also dann, wenn die loop Devices angelegt werden) eine Datei damit assoziiert ist; losetup hat aber nichts gefunden.

Versuchter work-around:'max_loop=64' bei den kernel_args einzufügen (in der Hoffnung, dass dann max 64 loop Devices erstellt werden) half nicht; es entstehen weiterhin tausende.

Ich schlage vor, diesen Thread jetzt abzuschliessen, da der Grund, warum USB Devices nicht gemounted wurden, gefunden ist. Die Sache mit den vielen loop Devices, zaŵar die Ursache des Übels, gehört meines Erachtens in einen neuen Thread. Nochmals vielen Dank an PeterPawn.