DM8000 Flash voll

    Hallo!
    Ich habe gerade festgestellt, dass der flash meiner 8k voll ist:


    root@dm8000:~# df -h
    Filesystem Size Used Available Use% Mounted on
    ubi0:rootfs 225.0M 225.0M 4.0K 100% /
    devtmpfs 72.9M 0 72.9M 0% /dev
    none 73.0M 1.0M 72.0M 1% /var/volatile
    /dev/mtdblock2 7.0M 3.6M 3.4M 51% /boot
    /dev/sdd1 1.8G 51.8M 1.8G 3% /media/cf
    /dev/sda1 1.8T 703.4G 1.1T 38% /media/hdd
    root@dm8000:~#


    Ich verstehe allerdings nicht wieso. Ich verwende das aktuelle Merlin-Image, nur einige Plugins und nur ein skin sind installiert und die Picons sind ausgelagert.
    Wie kann ich denn via telnet den Inhalt des flash checken?
    In diesem Zusammenhang, wo liegen denn üblicherweise die Verzeichnisse videodb_images und videodb_tmp_images des Videodb-Plugins. Ich dachte im selben Verzeichnis welches man für die Videodb definiert hat, bei mir sind sie aber da (siehe Anhang). Und Videodb funktioniert auch nicht mehr.
    Kann es daran liegen?
    Liebe Grüße!

    Gesagt -getan!
    Nun sieht es so aus.


    root@dm8000:~# df -h
    Filesystem Size Used Available Use% Mounted on
    ubi0:rootfs 225.0M 127.1M 97.9M 56% /
    devtmpfs 72.9M 0 72.9M 0% /dev
    none 73.0M 1.1M 71.9M 1% /var/volatile
    /dev/mtdblock2 7.0M 3.6M 3.4M 51% /boot
    /dev/sdd1 1.8G 51.8M 1.8G 3% /media/cf
    /dev/sda1 1.8T 703.4G 1.1T 38% /media/hdd
    192.168.1.11:/Filmdatenbank
    11.7T 4.9T 6.8T 42% /media/net/NAS


    Frag' mich nur wie das passiert ist. BTW, kann man den flash-Inhalt im telnet anzeigen?
    Anyway - vielen Dank!
    Liebe Grüße!


    G

    Mit

    Code
    du -h /


    kannst Du Dir die Verzeichnisgrößen anzeigen lassen.

    "Einen Tag ungestört in Muße zu verleben heißt, einen Tag lang ein Unsterblicher zu sein."


    Die Wertigkeit des Inhalts ist umgekehrt proportional zur Anzahl verwendeter Ausrufe- oder Fragezeichen.

    • Offizieller Beitrag
    Zitat

    Original von Mabthera
    Frag' mich nur wie das passiert ist. BTW, kann man den flash-Inhalt im telnet anzeigen?
    Anyway - vielen Dank!
    Liebe Grüße!


    G


    Vielleicht mal ins flash aufgenommen, hängt die Box an nem offenen Port ? Hacker?

    Um Aufnahmen im Fllash suchen, am besten /dev/mtdblock3 nochmal mounten, das ist dann ohne gemountete Filesysteme und leeres /proc, /sys etc.


    Edit: Befehle korrigiert
    mkdir /tmp/flash_root


    JFFS2 Filesystem (OE1.6)
    mount -t jffs2 /dev/mtdblock3 /tmp/flash_root/


    UBIFS (aktuelles OE2.0)
    mount -t ubifs /dev/ubi0_0 /tmp/flash_root/



    find /tmp/flash_root/ -name *.ts


    nach files suchen, die z.B. größer als 10MB sind
    ls -lahS $(find /tmp/flash_root -type f -size +10000k)


    da sollte ausser zwei libs nichts ausgespuckt werden


    die einzelnen Ordnergrößen anzeigen lassen, um nach Auffälligkeiten zu suchen


    du -sch /tmp_flashroot/*



    dannach wieder aushängen


    umount /tmp/flash_root

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    5 Mal editiert, zuletzt von Fred Bogus Trumper ()

    Ich bedanke mich für Eure Hinweise und Tipps und die telnet-Befehle. Wieder was gelernt.
    @ Mr. Bunny: Kein offener Port
    Liebe Grüße!
    G

    Zitat

    Originally posted by Fred Bogus Trumper
    Um Aufnahmen im Fllash suchen, am besten /dev/mtdblock3 nochmal mounten, das ist dann ohne gemountete Filesysteme und leeres /proc, /sys etc.


    Zumindest bei du gibt's für sowas die Option -x und die hat zur Abwechslung auch BusyBox mal nicht weglobotomisiert. Der Trick mit dem zweiten Mount ist allerdings öfter mal hilfreich, wenn man was vereinzeln will - man muss dazu unter Linux aber noch nicht mal das Original-Device und Filesystemformat referenzieren (wobei da kernelintern letztlich das Selbe passiert). Einfach einen Bind-Mount machen:

    Code
    mount --bind / /tmp/flash_root


    HTH,
    Andre.

    Hallo!
    Leider schon wieder dasselbe Problem, hab' das "gelöst" wieder entfernt.
    Der flash ist wieder voll, die Box war im Dauerloop und hatte ein Problem mit dem Datenträger (SSD) wo die videodb drauf ist. Der GS sagte irgendwas von Data-Malformation. Nach löschen der videodb läuft die Box jetzt wieder, aber nun wieder das:


    root@dm8000:~# df -h
    Filesystem Size Used Available Use% Mounted on
    ubi0:rootfs 225.0M 224.3M 708.0K 100% /
    devtmpfs 72.9M 0 72.9M 0% /dev
    none 73.0M 472.0K 72.6M 1% /var/volatile
    /dev/mtdblock2 7.0M 3.6M 3.4M 51% /boot
    /dev/sdd1 1.8G 51.8M 1.8G 3% /media/cf
    /dev/sdb2 54.0G 32.2M 54.0G 0% /media/SSD
    /dev/sda1 1.8T 703.4G 1.1T 38% /media/hdd
    root@dm8000:~#


    Das Problem ist nur, dass ich diesmal nicht erkennen kann, wo da was gespeichert wurde. wenn ich dem Rat von Fred Bogus Trumper folge:


    mkdir /tmp/flash_root
    mount -t ubifs /dev/mtdblock3 /tmp/flash_root


    bekomme ich diese Fehlermeldung:
    root@dm8000:~# mkdir /tmp/flash_root
    root@dm8000:~# mount -t ubifs /dev/mtdblock3 /tmp/flash_root
    mount: mounting /dev/mtdblock3 on /tmp/flash_root failed: Invalid argument
    root@dm8000:~#


    Ich stehe an und bitte um Hilfe! :confused_face:
    Anbei noch die crashlogs als die Box im loop war.
    Liebe Grüße!
    G

    Zitat

    Originally posted by Mabthera
    mount: mounting /dev/mtdblock3 on /tmp/flash_root failed: Invalid argument


    Probier mal stattdessen das Bind-Mount. Oder erstmal nur das, um die vollsten 10 Directories zu finden:


    Sieht das bei Dir signifikant anders aus?


    HTH,
    Andre.

    Hallo!
    Sieht bei mir so aus:


    root@dm8000:~# du -x / | sort -n | tail -10
    15080 /usr/lib/python2.7/site-packages
    16436 /lib
    27156 /usr/lib/enigma2/python/Plugins/Extensions
    29996 /usr/lib/python2.7
    32960 /usr/lib/enigma2/python/Plugins
    38432 /usr/lib/enigma2
    38432 /usr/lib/enigma2/python
    161608 /usr/lib
    193128 /usr
    222968 /
    root@dm8000:~#


    Ist das signifikant anders?
    LG
    G

    Mabthera


    sorry, das hatte ich ungetestet getippselt bzw. verwechselt/vermischt- jffs2 kann über /dev/mtdblock3 so mounten


    richtig wäre für ubifs:
    mkdir /tmp/flash_root
    mount -t ubifs /dev/ubi0_0 /tmp/flash_root/


    zumindest auf der DM7020HD


    aber der bind mount ist die elegantere Lösung - daran hatte ich gar nicht gedacht ...

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    Damit ich das recht verstehe, ich nehme den Befehl von Andre für den bind-mount (was auch immer das sein mag) und danach Deine


    find /tmp/flash_root/ -name *.ts
    ls -lahS $(find /tmp/flash_root -type f -size +10000k)
    du -sch /tmp_flashroot/*


    um die files zu suchen?
    LG
    G

    Zitat

    Originally posted by Mabthera
    Ist das signifikant anders?


    Nee, eigentlich nicht, und das finde ich extrem verwunderlich. Dein / ist mit 222968k auch nicht annähernd so voll, wie das df vermuten ließe, jedenfalls so lange Du das UBIFS mit Kompression laufen lässt. Deine Zahlen wirken eher unkomprimiert - da wäre es dann wohl tatsächlich voll (222M Daten in 225M verfügbarem Platz). Gewöhnlich sieht das aber eher so aus:

    Code
    root@dm7020hd:~# du -shx /
205.3M  /
root@dm7020hd:~# df -h /
Filesystem                Size      Used Available Use% Mounted on
ubi0:rootfs             368.7M    102.1M    266.6M  28% /


    205M Daten bei 102M Used legen eine durchschnittliche Kompression von 2:1 nahe, und damit müsstest Du noch ca. 100M Platz haben...


    Mal beim dFlash ohne Compression restored?


    HTH,
    Andre.

    Ich habe dflash nie verwendet!


    Sieht bei mir so aus:

    root@dm8000:~# du -shx /
    217.7M /
    root@dm8000:~# df -h /
    Filesystem Size Used Available Use% Mounted on
    ubi0:rootfs 225.0M 224.4M 588.0K 100% /


    also eher 1:1, sprich keine Kompression. Wie kann denn sowas passieren? Gestern noch alles ok, dann spinnt die SSD und plötzlich ist der flash voll, weil UBIFS nicht komprimiert ist????
    LG!
    G

    Zitat

    Originally posted by Mabthera
    Ich habe dflash nie verwendet!


    Dann ist es unwahrscheinlich, dass da was unkomprimiert in den Flash gekommen ist (mit dem SSL kann man bekanntlich maximal 128M große Images flashen).


    Zitat

    also eher 1:1, sprich keine Kompression. Wie kann denn sowas passieren? Gestern noch alles ok, dann spinnt die SSD und plötzlich ist der flash voll, weil UBIFS nicht komprimiert ist????


    Das kann vor allem bedeuten, dass meine Theorie falsch ist. Oder besser gesagt, nicht nah genug an der verrückten Realität (cf. Newton vs. Einstein). UBIFS ist ja ein etwas komplexeres Konstrukt, bei dem "100% voll" erst mal jeder Zustand sein kann, der dazu führt, dass keine Logical Erase Blocks mehr frei sind. Dieser Zustand kann von unkomprimierten Daten herrühren, muss es aber nicht, und Dein Output von du legt nahe, dass er das nicht tut. Ab hier wird's spannend. Z.B. könnte Dein UBIFS schlicht einen Hau haben (wäre ja nichts Neues, aber auf der 8000 bisher nicht verbreitet). Oder es liegen irgendwo jede Menge Metadaten, die in du nicht auftauchen, aber LEBs blockieren. Wie viele Files liegen in Deinem Root-FS? Dank BusyBox geht das nicht mit df -i sondern nur brute force:

    Code
    root@dm7020hd:~# find / -xdev | wc -l
10906


    Und guck mal nach UBI(FS)-Ausschriften im Log:

    Code
    grep UBI /var/log/messages*


    Könnte auch sein, dass ein bereits gelöschtes File (das keinen Namen mehr hat, also von du nicht gesehen wird) noch im FS liegt, weil ein Prozess das noch offen hat. Das Drama geht bei einem Reboot nicht weg?


    HTH,
    Andre.

    Also:
    Anzahl der Dateien:


    root@dm8000:~# find / -xdev | wc -l
    11753
    root@dm8000:~#


    Nach einem reboot sieht der Speicher unverändert aus:

    root@dm8000:~# du -shx /
    217.8M /
    root@dm8000:~# df -h /
    Filesystem Size Used Available Use% Mounted on
    ubi0:rootfs 225.0M 224.3M 680.0K 100% /
    root@dm8000:~#


    Das Drama persistiert also!


    Log-Ausschriften:


    root@dm8000:~# grep UBI /var/log/messages*
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.363000] UBI: attaching mtd3 to ubi0
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.363000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.363000] UBI: logical eraseblock size: 129024 bytes
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.363000] UBI: smallest flash I/O unit: 2048
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.363000] UBI: sub-page size: 512
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.364000] UBI: VID header offset: 512 (aligned 512)
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.364000] UBI: data offset: 2048
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.877000] UBI: max. sequence number: 19319
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: attached mtd3 to ubi0
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: MTD device name: "root"
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: MTD device size: 248 MiB
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: number of good PEBs: 1984
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: number of bad PEBs: 0
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: number of corrupted PEBs: 0
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: max. allowed volumes: 128
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: wear-leveling threshold: 4096
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: number of internal volumes: 1
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: number of user volumes: 1
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: available PEBs: 0
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: total number of reserved PEBs: 1984
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: number of PEBs reserved for bad PEB handling: 19
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.896000] UBI: max/mean erase counter: 25/9
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.897000] UBI: image sequence number: 438663092
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 1.899000] UBI: background thread "ubi_bgt0d" started, PID 51
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 2.082000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 2.082000] UBIFS: file system size: 251596800 bytes (245700 KiB, 239 MiB, 1950 LEBs)
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 2.082000] UBIFS: journal size: 9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 2.082000] UBIFS: media format: w4/r0 (latest is w4/r0)
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 2.082000] UBIFS: default compressor: lzo
    Jun 22 18:11:09 dm8000 user.notice kernel: [ 2.082000] UBIFS: reserved for root: 0 bytes (0 KiB)
    root@dm8000:~#


    Mir sagt das leider nichts!
    LG
    G

    du musst die Abfragen in /tmp/flash_root machen - egal ob mit bind mount gemounted oder direkt aus dem flash (/dev/ubi0_0)


    also


    find /tmp/flash_root/ -xdev | wc -l


    oder


    find /tmp/flash_root/ -name *.ts

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    Einmal editiert, zuletzt von Fred Bogus Trumper ()

    Guten Morgen!
    Diese Eingaben liefern folgendes:

    root@dm8000:~# mkdir /tmp/flash_root
    root@dm8000:~# find /tmp/flash_root/ name *.ts
    /tmp/flash_root/
    find: name: No such file or directory
    find: *.ts: No such file or directory
    root@dm8000:~# find /tmp/flash_root/ -xdev | wc -l
    1


    Wie finde ich denn nun dieses eine file? Die UBIFS Meldungen aus dem log sehen ja ok aus, oder nicht?
    Ich bin nun wieder die Woche über unterwegs und melde mich am Freitag Abend zurück.
    Danke für Eure Zeit und Hilfe!
    Liebe Grüße!


    G