7490 Festplatte wird nicht erkannt

altae

Neuer User
Mitglied seit
5 Jun 2016
Beiträge
19
Punkte für Reaktionen
3
Punkte
3
Seit dem Update auf 6.52 erkennt meine fritzbox die Festplatte nicht mehr (ext4, 2 Partitionen), unter 6.30 funktionierte dies einwandfrei, ebenso wenn ich die Platte an meinen PC mit Linux anschliesse. Auch kann ich die Festplatte auf der Box mittels manuellem mount Befehl mounten, sie wird nur nicht automatisch erkannt und eingehängt. Die Fritz Firmware selbst meint: "The USB storage medium or partitions thereof are not supported". Gibt es da Lösungsansätze? Ich kann das Problem zwar wie erwähnt mittels mount Befehl umgehen, allerdings muss ich das immer manuell machen, denn erstens löscht das System nach jedem Neustart die dazugehörigen Einhängepunkte unter /var/media/ftp und ausserdem habe ich keine Möglichkeit gefunden, die fstab Datei auf der fritzbox zu bearbeiten.
 

Anhänge

  • config.txt
    26.8 KB · Aufrufe: 10
Die Fritz Firmware selbst meint: "The USB storage medium or partitions thereof are not supported".

Hallo altae,
könntest Du mal "fdisk -l" eingeben und posten.

da sieht man dann die Geometrie und den Partitiontype.

Gruß
Pokemon20021
 
fdisk geht nicht, den Befehl kennt die Box nicht. Aber wie erwähnt, mit der Festplatte ist alles in Ordnung, habe sie an den Linux PC angeschlossen und auf Fehler überprüft. Trotzdem weigert sich die Box, die Festplatte automatisch zu erkennen.

Um das Problem zu umgehen, habe ich mir folgendes überlegt: Ich könnte ja ein Script in der rc.custom hinterlegen, welches beim Neustart zuerst die Einhängepunkte erstellt und danach die beiden Partitionen einhängt. Müsste eigentlich funktionieren. Oder doch nicht? Die automatische Erkennung wäre natürlich schöner doch solange es funktioniert...

Ach ja, blkid gibt folgendes aus, auch wenn die Festplatten nicht gemounted sind:

root@fritz:/var/mod/root# blkid
/dev/loop0: TYPE="squashfs"
/dev/sda1: LABEL="BACKUP" UUID="b24188c8-adcc-a22c-f6c1-43a00a5affdd" TYPE="ext4"
/dev/sda2: LABEL="DATEN" UUID="9333e33b-6374-f0de-01fb-7ec2d56be6b9" TYPE="ext4"
 
Nimm doch die busybox von PeterPawn https://github.com/PeterPawn/modfs/tree/master/bin/VR9
do geht doch "fdisk -l"

Code:
# find . -name busybox
./bin/VR9/busybox

# ./bin/VR9/[COLOR=#0000ff]busybox fdisk[/COLOR] -l /dev/sda
Disk /dev/sda: 124.2 GB, 124218507264 bytes
255 heads, 63 sectors/track, 15102 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1       15103   121307120  83 Linux
#

# mount
SNIP
/dev/sda1 on /var/media/ftp/USB_STICK_01 type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=writeback)
#
 
Code:
[FONT=Courier New]root@fritz:/var/mod/root# blkid
/dev/loop0: TYPE="squashfs" 
/dev/sda1: LABEL="BACKUP" UUID="b24188c8-adcc-a22c-f6c1-43a00a5affdd" TYPE="ext4" 
/dev/sda2: LABEL="DATEN" UUID="9333e33b-6374-f0de-01fb-7ec2d56be6b9" TYPE="ext4"[/FONT]

was passiert eigentlich, wenn Du manuell mountest
Code:
# mkdir /var/media/ftp/mnt_sda1
# mount -t ext4 /dev/sda1 /var/media/ftp/mnt_sda1
#
 
Wie erwähnt, manuell mounten geht einwandfrei. Das ist, was ich aktuell mache, um das Problem zu umgehen. Nur muss ich das nach jedem Neustart der Box machen, was auf die Dauer doch ein wenig lästig ist.

- - - Aktualisiert - - -

Man könnte auch einfach fdisk im menuconfig aktivieren.
Entgegen meine Aussage oben geht SMART doch, man muss nur aktuelle Versionen der Tools verwenden die noch nicht in Freetz sind.

Habe ich versucht, scheint nicht zu funktionieren. Der fdisk Befehl scheint nach wie vor unbekannt zu sein.
 
Wie wäre es denn einfach mal mit dem Protokoll, was auf /dev/console zu sehen ist, wenn der Stick angesteckt wird? Auch eine Idee, ob das Image mit oder ohne FreetzMount gebaut wurde, wäre nicht ganz falsch - wenn wir hier im Freetz-Unterforum sind, wird es ja hoffentlich wenigstens ein Freetz-Image sein.

Wie soll man aus den bisher bekannten, spärlichen Fakten denn "erraten", wo das Problem wirklich liegt?

Ich gehe zumindest mal davon aus, daß es kein eigener Kernel ist - damit fällt vermutlich die Möglichkeit, daß die notwendigen Module nicht geladen sind, erst einmal aus. Wenn "ext4" im Kernel komplett fehlen würde (das ist ja wohl die internationale Version, die deutsche gibt es ja gar nicht als 06.52), dürfte auch das manuelle Mounten nicht funktionieren.

Wie das vom Ablauf her normalerweise aussehen sollte, ist ja bekannt und am Beginn der (deutschen) 06.5x für die 7490 schon einmal Thema gewesen.

Bei der Erkennung über "blkid" muß man schon aufpassen, das da auch die richtige/passende Version von "blkid" verwendet wird - da kann ein nachträgliches "blkid" zur Kontrolle in einer Shell-Session durchaus auch ein anderes Programm aufrufen, je nach Suchreihenfolge.

Also am besten mehr (über-)prüfen und nach dem tatsächlichen Fehler suchen ... nur in der "Außenansicht" (automatisch klappt nicht, manuell aber schon) wird sich die Ursache kaum entdecken lassen, solange nicht jemand hier doch noch durch übernatürliche Kräfte glänzen kann.

Wenn man in der Session mit "getcons" nichts sehen kann, muß man eben in die hotplug-Skripte eine (vorübergehende) ausführliche Protokollierung einbauen.
 
Ok, ich konnte das Problem selbst lösen. Der "up to 9 USB devices" Patch scheint nicht kompatibel zu sein, zumindest in meinem Fall hat der wohl das Problem verursacht. Ich habe ein neues Image kompiliert, dieses mal ohne den erwähnten Patch. Nun werden die beiden Partitionen wieder korrekt erkannt und gemounted.
 
@altae:
Ich will Dir nicht zu nahe treten, aber das ist als Erklärung (zumindest in diesen dürren Worten) nicht schlüssig.

Warum?

Der Patch sieht so aus:
Code:
[ "$FREETZ_PATCH_MAXDEVCOUNT" == "y" ] || return 0
if [ -e "${FILESYSTEM_MOD_DIR}/etc/hotplug/create_handle.sh" ]; then
        file="create_handle.sh"
else
        file="usb.pandu"
fi
echo1 "patching ${file}: MAXDEVCOUNT"
modsed "s/^MAXDEVCOUNT=/MAXDEVCOUNT=9   # oldvalue: /g" \
 "${FILESYSTEM_MOD_DIR}/etc/hotplug/${file}" \
 "^MAXDEVCOUNT=9"
Da wird also bei der 113.06.52 aus der Zeile
Code:
MAXDEVCOUNT=4 # Do not accept more than MAXDEVCOUNT devices (USB HUBs don't count)!
nach dessen Anwendung die Zeile
Code:
MAXDEVCOUNT=9   # oldvalue: 4 # Do not accept more than MAXDEVCOUNT devices (USB HUBs don't count)!
Diese Variable wird dann in der gesamten Firmware genau ein einziges Mal ausgewertet, nämlich in der Abfrage
Code:
## Too many devices?
COUNT=`/sbin/lsusb -n`
HUBCOUNT=`/sbin/lsusb -N 9`
DUMMYCOUNT=`/sbin/lsusb -N 0`
COUNT=$((COUNT - HUBCOUNT))
COUNT=$((COUNT - DUMMYCOUNT))
[COLOR="#FF0000"]if test $COUNT -gt $MAXDEVCOUNT; then[/COLOR]
atomic_touch /var/$DEVID && eventadd 130 $DEVNUM && eventadd 133
IGNORE_AND_EXIT
fi
und selbst dann wird noch eine Nachricht ins Ereignisprotokoll geschrieben, bevor das Gerät ignoriert wird.

Solange Du nicht also bereits vier andere USB-Geräte angeschlossen haben solltest und der Stick mit den zwei Partitionen dann das fünfte Gerät gewesen wäre, sollte dieser Patch absolut keine Auswirkungen auf irgendeinen Ablauf im erzeugten Image haben.

Vielleicht überprüfst Du ja Deine Konfiguration noch einmal ... eine Abhängigkeit weiterer Patches von diesem habe ich auch nicht finden können:
Code:
# grep -r MAXDEVCOUNT
patches/scripts/460-modify_maxdevcount.sh:[ "$FREETZ_PATCH_MAXDEVCOUNT" == "y" ] || return 0
patches/scripts/460-modify_maxdevcount.sh:echo1 "patching ${file}: MAXDEVCOUNT"
patches/scripts/460-modify_maxdevcount.sh:modsed "s/^MAXDEVCOUNT=/MAXDEVCOUNT=9 # oldvalue: /g" \
patches/scripts/460-modify_maxdevcount.sh: "^MAXDEVCOUNT=9"
config/ui/patches.in:config FREETZ_PATCH_MAXDEVCOUNT
und damit muß es noch eine andere geänderte Einstellung geben, die das Problem verursacht bzw. beseitigt hat. Ein "diff" für die beiden ".config"-Dateien sollte da schnell Aufschluß geben - aber wenn dieser (eher harmlose) Patch die Ursache sein sollte, dann müßte das schon auf extrem verschlungenen Wegen der Fall sein.

Insofern ist das also als Lösung zumindest zweifelhaft und bis zu einer Überprüfung bzw. dem Verständnis, warum das so sein soll, muß nicht jeder mit demselben Problem das auch als denkbare Lösung ansehen und sich die Arbeit damit machen.

Es sollen zwar schon Reittiere beim Pharmazeuten vomitiert haben (und das vermutlich nicht aufgrund einer Essstörung - das muß man auch erst einmal ohne Lispeln aussprechen können, zum Glück muß ich es nur aufschreiben), aber allzu wohlfeilen (und wenig einleuchtenden) Erklärungen darf man auch mal mit etwas Mißtrauen begegnen.
 
Schau, mir eigentlich egal was du denkst. Fakt ist, ich habe das image 1:1 neu kompiliert, einfach ohne diesen Patch. Von all denen, die hier geantwortet haben, hat mir niemand auch nur ansatzweise geholfen, ich musste das selbst herausfinden. Trotzdem schätze ich natürich die Bemühungen eines jeden, der geantwortet hat.

Tatsache ist aber, ich habe hier 2 Images, das eine mit und das andere ohne den besagten Patch, ansonsten sind sie genau gleich. Flashe ich dasjenige ohne den Patch, so werden die 2 Partitionen automatisch durch die Fritz Firmware gemounted. Flashe ich das andere Image, so funktioniert es nicht mehr und ich muss manuell mounten (was einwandfrei funktioniert). Für mich ist das Beweis genug, da muss ich nicht noch weiter forschen.
 
Am Ende ist es mir auch egal, was Du für die Ursache hältst ... ich lasse es mir trotzdem nicht nehmen, auf die mangelnde Plausibilität dieser Erklärung hinzuweisen und sei es in der Hoffnung, anderen Arbeit zu ersparen, falls diese sich ebenfalls erhoffen sollten, ein ähnliches Problem auf diesem Weg zu lösen.

Es kann Dich auch niemand "zwingen", Deinen Beitrag zur Klärung der Situation zu leisten ... allerdings ist es eben um ein Community-Projekt eher schlecht bestellt, wenn es nur "leecher" gibt und niemand mehr etwas beitragen will.

Aber es ist Deine Entscheidung und zumindest bleibt mir noch, Dich meines Mitleids zu versichern, weil Du ja feststellen mußtest:
altae schrieb:
Von all denen, die hier geantwortet haben, hat mir niemand auch nur ansatzweise geholfen, ich musste das selbst herausfinden.
Das kann aber auch einfach das Ergebnis dessen sein, daß man sämtliche bereits geschriebenen Beiträge zum Thema: "Wie melde ich ein (vermeintliches) Problem im Freetz-Projekt richtig?" ignoriert oder gar nicht erst zur Kenntnis genommen hat, daß es solche "Anleitungen" tatsächlich gibt.

Insofern ... danke, daß ich Dich lesen durfte.
 
@opto:
Du warst da ja auch nicht gemeint ... solange Du Dich nicht ebenfalls weigerst, einem (reproduzierbaren) Fehler wirklich auf den Grund zu gehen.

Bei allen Differenzen bzgl. der 6490, was da nun Fehler sind und was "by design", haben schon wir zwei ja genug Anstrengungen in die Fehlersuche investiert - wenn Du mir irgendwann die Erklärung anbietest, daß Deine Images nur dann funktionieren, wenn gerade der Strom aus Wasserkraft (gesetzt den Fall, Du beziehst einen entsprechenden Mix) kommt im Moment des Packens der Daten (als unbewiesenes Postulat genauso plausibel wie die von mir in Zweifel gezogene Feststellung), dann hätte ich da ebenfalls meine Zweifel und würde damit nicht hinter dem Berg halten.
 
Von all denen, die hier geantwortet haben, hat mir niemand auch nur ansatzweise geholfen, ich musste das selbst herausfinden.

Glückwunsch, in diesem Fall muß ich schlußfolgern, dass Du die Anfrage besser nicht gestellt hättest;

Ebenfalls danke, daß ich Dich lesen durfte.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.