Posts by ABPSoft

    Quote

    Originally posted by Mabthera
    Hallo Andre!
    Liefert folgendes:

    Code
    root@dm8000:/var/volatile/tmp/flash_root/media# du -sh *
    126.3M SSD


    Ah yep, wie schon erwartet: Der Schmutz war unter dem Mountpoint der SSD versteckt. Ab hier ist es einfach, aber (wenn man nicht guckt, wohin man tritt) nicht ungefährlich, daher in zwei Schritten. Erstmal gehen wir in den Mountpoint rein und verifizieren, dass wir wirklich dort gelandet sind:

    Code
    cd /tmp/flash_root/media/SSD/ || echo STOP
    pwd


    Nur wenn kein STOP ausgegeben wird und das pwd (print working directory) wirklich nochmal bestätigt, dass wir in /tmp/flash_root/media/SSD und nirgends anders stehen, kommt der große Schnitter:

    Code
    rm -rf *


    Achtung, dieser Befehl löscht gnadenlos, hierarchisch und ohne Rückfrage alles[1] unterhalb des aktuellen Arbeitsverzeichnisses (CWD, current working directory), also nach (und nur nach) obigen Vorbereitungen alles was noch unter /media/SSD im Flash liegt, man will also wirklich genau aufpassen wo man steht und verstehen, was der dort macht, bevor man ihn loslässt.


    And now, unleash hell.


    [1] Strenggenommen nicht alles, sondern nur alles, dessen Name nicht mit einem Punkt anfängt, und das aus sehr, sehr gutem Grund. Falls der Schmutz wider erwarten nicht komplett verschwindet, gucken wir uns das gezielt an.


    HTH,
    Andre.

    Quote

    Originally posted by Mabthera
    Und was sagt uns das jetzt?


    Dass Du - wie eigentlich nur noch als letzte, nicht fortgeschritten esoterische Lösung blieb - an einer Stelle im Flash Daten hast, die bei den vorigen Untersuchungen unsichtbar blieb, weil sie übermountet war (ich nehme an, von Deiner SSD).


    Nach dem Output zu urteilen ist es aber keine Aufnahme, sondern 127MB Daten in fast 3000 Files irgendwo unter /media. Ich nehme an, es sind die Reste Deiner VideoDB (Cover-JPEGs etc). Vielleicht auch Filme, aber keine Aufnahme (*.ts - wobei das nicht gequoted war, also ein minimales Risiko bleibt, dass der Befehl was anderes gemacht hat als gedacht). Nun sind 127MB aber auch wieder nicht so viel, also werden es wohl doch nur Reste von der VideoDB sein.


    Im Prinzip kannst Du nach /tmp/flash_root/media gehen und dort alles bis auf die Mountpoints löschen. Aber bitte mit Vorsicht, daher erst mal nur das hier (die ersten beiden Befehle kannst Du weglassen, falls Du nicht inzwischen rebootet hast und der Mount folglich noch steht):

    Code
    mkdir -p /tmp/flash_root
    mount --bind / /tmp/flash_root
    cd /tmp/flash_root/media
    ls -la
    du -sh *


    Das wird uns dann sicher den vollgesuppten Mountpoint zeigen. Wie wir den bereinigen folgt, wenn klar ist wie er heißt (ich erwarte sowas wie hdd oder ssd, aber es gibt ja Überraschungen).


    Klar ist auf jeden Fall schon mal, dass wir die Leiche (127MB verschwundene Daten, die das Root-FS abfüllen) gefunden haben und Du ohne Flashen wieder zu diesem freien Platz kommen wirst ;)


    HTH,
    Andre.

    Quote

    Originally posted by friday13
    wenn ich im qnap ssl für ftp aktiviere, dann komme ich über den browser auch drauf. jedoch nicht von extern. dort scheitert das verzeichnislisting.


    Eine per SSL verschlüsselte FTP Control Connection (ftps) verhindert ziemlich sicher jegliches NAT/PAT. Da "von extern" sicherlich bedeutet, dass Du auf das NAT Deines Home-Routers angewiesen bist, brauchst Du da nicht weiter zu experimentieren. Das wird nie gehen. Wie also hier schon empfohlen: Nimm sftp (das hat nix mit FTP zu tun, es ist ein SSH-Login, das ein nur Submodul mit einen definierten, festen Befehlsumfang aktiviert, der für Dateitransfer ausreicht). Als GUI-Client gibt's z.B. auch noch WinSCP.


    HTH,
    Andre.

    Quote

    Originally posted by xorg
    wie sind die Farben denn "vertauscht", also wie kann ich sie mit z.B. GIMP wieder "geradebiegen"?


    Das sieht nach einem klassischen U-V-Dreher aus, d.h. im ursprünglich im MPEG encodierten YUV-Farbraum wurden die Farbdifferenzkanäle U und V miteinander vertauscht, während der reine Helligkeitskanal (Y, praktisch das SW-Bild) erhalten blieb. Wie man das mit GIMP fixen kann weiß ich nicht, aber wenn Du das Bild irgendwie in die YUV-Kanäle zerlegen kannst, dann musst Du nur U und V nochmal drehen und es dann wieder nach RGB zurücktransformieren.


    HTH,
    Andre.

    Quote

    Originally posted by Thorsten020
    Die Baluns sind IMHO Möglichkeiten zur Vervielfachung von Telefon- oder TV Anschlüssen.


    Baluns (Balanced-Unbalanced) sind Umsetzer zwischen 100Ohm symmetrischen (Twisted Pair) und 75Ohm asymmetrischen (Koax) HF-Kabelwegen. Ich hab ja keine Ahnung was Du da genau hast, aber die extrem spärliche Beschreibung der Produkte da bei BKS sieht zumindest für mich so aus, als wäre sowohl BasicNet als auch HomeNet im Kern eine strukturierte (TP) Verkabelung mit Eigenschaften jenseits von Class FA. Da an jedem LNB/Switch und an jedem Receiver asymmetrische F-Buchsen verbaut sind, braucht man immer Baluns, um auf die symmetrische TP-Strecke umzusetzen. Das ist teuer, produziert zusätzliche Verluste und wenn ich da lese

    Quote

    SAT-Balun 1-fach, F / MMC,
    75/100Ohm, 1.5dB Durchgangsdämpfung 5-1006MHz

    dann habe ich da schon Fragezeichen in den Augen bezüglich der für SAT-ZF wirklich relevanten Frequenzen jenseits von 1GHz. Die Idee ist an sich ja clever (Kerpen versucht das auch schon ewig in den Markt zu kriegen), aber so eine bis auf 2GHz gezüchtete PiMF dämpft doch ungleich mehr als Koax, das Problem kann man nicht so einfach wegzaubern...


    Ich würde ja sagen, Dein "Restproblem" heißt irgendwo falscher Balun oder falsches Patchkabel (zu hohe Dämpfung bei SAT-ZF). Aber auch nur, wenn das wirklich im Kern TP-Verkabelung ist. Wenn alles Koax ist, dürften solche Probleme nicht existieren.


    Quote

    BTW: Cat 7 gibt es doch wirklich?


    Naja, für gewisse Werte von "gibt" und "wirklich". Es gibt eine ISO/IEC 11801 Class F (nicht von der EIA/TIA als Cat 7 akzeptiert), bei der eigentlich nur Kabel existieren, weil der Streit um die Steckgesichter nie ganz gelöst wurde. Alle Welt macht modulare Westernstecker aka RJ45 aka 8P8C dran, aber damit eigentlich kein Cat7. Weil auch niemand Cat7 braucht, die Idee des Standards war ursprünglich, 10GBase-T zu supporten, das kann aber auch Cat6A (ein Post-Factum-Upgrade von Cat6, sehr ähnlich zu Cat5E was inzwischen Cat5 vollständig beerbt hat). Cat7 ist selbst für BK zu wenig (nur 600MHz), für SAT-ZF unbrauchbar und für 10GBase-T schon zu gut. Dann gibt es inzwischen auch Class FA nach ISO/IEC 11801:2011 Edition 2 Amendment 2, was ebenfalls nicht von der EIA/TIA als Cat7A akzeptiert, aber trotzdem von allen so genannt wird, die es verkaufen wollen. Das kommt knapp über 1000MHz und ist damit prinzipiell BK-fähig, wie gesagt auf ein paar Meter (nicht wirklich 100) und nach reichlicher Dreingabe von Baluns. Aber das ist immer noch nicht SAT-ZF: Hier sind wir dann im Reich der Fantasie, das könnte irgendwann mal ISO/IEC 11801 Edition 3 werden, die Tendenz der EIA/TIA das Category 8 zu nennen sieht zur Abwechslung mal gut aus (wie gesagt, die letzte wirklich existierende Category ist 6A) und das Zeug wird für 40GBase-T entwickelt. Maximale Frequenz soll irgendwo zwischen 1,6GHz und 2GHz liegen, weiß noch keiner genau. BKS verkauft Dir aber gerne "Kategorie 8" mit 2,3GHz, und wenn das wirklich vollständig so funktioniert wie auf dem Papier und richtig installiert wurde, dann mag es auch SAT-ZF tragen können. Das mit den 50m glaub ich aber auch erst, wenn ich es sehe ;)


    HTH,
    An"Layer1"dre.

    Quote

    Originally posted by RainerHH22
    kann mir jemand mal diesen Stream aufschlüsseln, was die einzelnen Daten bedeuten?


    #SERVICE 1:0:1:6D6B : 437:1:C00000:0:0:0:rtp%3a//@239.35.10.28%3a10000:ZDFinfo


    Bezüglich IPTV ist erstmal nur der Medien-URL wichtig, der hier mit URL-encodeten Doppelpunkten stehen muss (weil Doppelpunkte, wie man sieht, bereits als Feldtrenner für die DVB-Servicereferenz und den Namen herhalten):

    Code
    rtp://@239.35.10.28:10000

    bedeutet konkret, der Client soll der IPv4-Multicastgruppe 239.35.10.28 beitreten (das ist keine Unicast-Zieladresse irgendeines Servers!) und dort auf dem Port 10000/udp lauschen, wo (sofern jemand die Gruppe bedient) kurze Zeit später Pakete im Format RTP runterzufallen beginnen sollten. In denen steckt der Content, und der prasselt fürderhin auf die Box hernieder, bis diese die Mcast-Gruppe wieder verlässt (vulgo wegzappt).


    Die Service-Referenz-Felder sind für das Funktionieren des URLs im Prinzip irrelevant, hier allerdings sehr hilfreich, weil sie die korrekten EPG-Daten (sofern vorhanden) referenzieren helfen.


    HTH,
    Andre.

    Quote

    Originally posted by Mabthera
    Ihr habt sicher recht damit, dass flashen einfacher ist, ich würde halt nur gerne verstehen was da passiert ist.


    Das kann ich nachvollziehen, denn irgendwie ist das schon recht mysteriös. Ich kann auch nicht mehr viel beitragen, außer Deine Beobachtung zu bestätigen, dass völlig unklar ist, wohin der Platz verschwindet:

    • Deine vollsten Verzeichnisse entsprechen meinen, es gibt da keins, wo sich 100MB verstecken könnten, also auch kein angefangener .ts oder sowas. Selbst wenn irgendwo ein paar hundert unkomprimierbare JPEGs lägen, müsste einen das betreffende Directory anspringen.
    • Die Gesamtanzahl Files liegt nur wenig über meiner. Generell hast Du hinsichtlich Datennutzung und Anzahl Files ca. 110% von dem was ich hier habe, was problemlos mit ein paar anderen oder zusätzlichen Plugins erklärbar ist. Nichts, was aus der Reihe tanzt.
    • Das UBI Log wirft keine Fehler, also nichts was an der Struktur offensichtlich kaputt wäre.
    • Laut UBI Log ist LZO als Kompressor aktiv. Kann also auch nicht unkomprimiert sein.
    • Die Zahlen (LEB-Anzahl und -Größe) passen zusammen und zur Gesamtgröße des FS. Was man nicht sieht (wüsste nicht, wie man ran käme, auch ubinfo -a gibt das nicht preis) ist die Anzahl wirklich benutzter LEBs.


    Ich sehe noch eine Möglichkeit: Die Leiche liegt an einer Stelle, die inzwischen schon wieder übermounted ist. Das würde nämlich bei einem du -x ebenfalls nicht mitgerechnet. Wenn Du also den Bind-Mount in /tmp/flash_root hast, jag da nochmal das du -shx drüber. Sollte da plötzlich mehr auftauchen als in der / selbst (Blöcke oder Files), dann haben wir doch noch was ausgegraben:

    Code
    mkdir -p /tmp/flash_root
    mount --bind / /tmp/flash_root
    du -shx /
    du -shx /tmp/flash_root
    find / -xdev | wc -l
    find /tmp/flash_root -xdev | wc -l


    Alles weitere ist fortgeschrittene Forensik. Du kannst ja von dem Flash noch einen Dump machen (geht im Webinterface des SSL aka STOP Mode, man kriegt auf der 8000er dann ein 256MiB großes File namens FLASH) und bei DMM mal fragen, ob jemand Interesse hat, sich das genauer anzugucken. Spannend wäre es schon zu wissen, was genau da schief gegangen ist. Alternativ mal DrBest fragen, es ist ja immerhin mit der VideoDB passiert. Haken an der ganzen Sache ist, dass die Tools zur Analyse von UBIFS-Dumps nicht gerade vom Himmel fallen, will sagen, das wird schnell viel zeitraubende Handarbeit...


    HTH anyway,
    Andre.

    Quote

    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).


    Quote

    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.

    Quote

    Originally posted by Jogi29
    Meine Tendenz geht ganz stark nach Mainboard bzw. SATA-Controller auf dem MB defekt.


    Die ursprüngliche sda (S/N WD-WCAWZ0990301) hatte 11 pending sectors und READ-Fehler im Log. Sowas kommt nicht von außen, das ist die Platte, egal wie kaputt das Interface ist (Ok, evtl. sind noch spezielle Muster in Schwankungen der Stromversorgung dazu in der Lage, sowas zu provozieren, halte ich aber für unwahrscheinlich). Falls Du die also noch/wieder im Array hast, dann hat wohl die Aufgabe der Sektoren (durch das beim RAID-Init erfolgende Überschreiben) erstmal geholfen, aber die verfällt u.U. weiter. Das Fehlerbild, wo einige Operationen (speziell Leseoperationen) zwar noch gelingen, aber extrem lange dauern, ist jetzt nicht gerade untypisch.


    HTH,
    Andre.

    Quote

    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.

    Quote

    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.

    Quote

    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.

    Hi,


    wenn ich das so lese, dann verzichte ich mal lieber auf das Update, bis der nächste Tarball mit dem Fix kommt. Wobei das spannenderweise niemanden sonst hier zu erwischen scheint? Wäre interessant zu wissen, was genau das triggert...


    An"paranoia"dre.

    Quote

    Originally posted by Frankster
    Am PC gibt es keine Probleme.


    Womit? Mal einen Player probiert, der auch libdvdnav verwendet? Könnte z.B. VLC sein (ich weiß nicht, wie das unter Windows aussieht - unter Linux nutzt fast alles, was DVD abspielen kann, diese Bibliothek).


    Sowas ist meist ein Corner Case im Mastering des Menüs der DVD, der auf einen Bug in libdvdnav trifft, oder umgekehrt. Nicht umsonst ist eine typische Formulierung im Changelog der Entwickler:

    Quote

    ... improved playback of badly mastered or "copy protected" DVDs.


    Wie's aussieht benutzt die Dream libdvdnav 4.1.2, was im April 2008 released wurde. Danach gab es mehrere Major und Minor Releases, die 4.2.1 ist wohl der aktuell verbreitetste Stand, nach dem Umzug ins VideoLAN Git gibt es aber seit einigen Wochen auch eine 4.9.9 - was ich mal als Anzeichen werten würde, dass man da "in Bälde" vor hat, eine 5.0 zu releasen.


    Es könnte also sein, dass Dein spezifisches Problem in einer aktuelleren Release gefixt ist - muss aber nicht. Das DVD-Bediensystem ist eine komplette VM mit einer Hand voll Befehlen, da kann immer noch irgendwo ein Corner Case sitzen und libdvdnav war seinerzeit berühmt dafür, nicht gerade frei von Glitches zu sein. Ist auch Mist, wenn man dauernd um Nasen drumrumprogrammieren muss, die versuchen, die Menü-VM mit Kopierschutz-Maßnahmen zu verseuchen (CSS selbst ist ja irrelevant).


    HTH,
    Andre.

    Quote

    Originally posted by Thorsten020
    Jetzt interessiert mich wo der Abschwächer sitzt. Vielleicht in diesen BKS Adaptern? Oder in der BKS Hausverdrahtung? Die Gesamtkabellänge incl. BKS ist schon recht lang, länger als in meiner bisherigen Wohnung. Aber der Anteil davon, der frei herumliegt ist kürzer. BKS behauptet die Qualität wird durch deren Leitungsverlegung besser. Doch die Koaxialkabel von BKS sind definitiv viel dünner.


    Ist das überhaupt Koax? Ich hatte das so verstanden, dass BKS (für mich hieß das bisher Blitzknallsatz) diesen abenteuerlichen Weg geht, mittels Baluns von Koax auf Twisted Pair umzusetzen, wobei TP-Kabel mit kaum noch realisierbaren Eigenschaften zum Einsatz kommen. Die nennen sich dann gern Cat7 (kein offizieller Standard), Cat7+ oder wie hier Kat8 (Fantasy). Das Problem: Sat-ZF liegt zwischen 1 und 2GHz und in diesem Frequenzbereich dämpft TP viel mehr als Koax. Dazu kommt, dass die TP-Kabel, die das überhaupt packen, so Space Age sind, dass sie schon kaputt gehen, wenn man sie schief anguckt. Wenn jemand drauf gelatscht ist, sind sie mit Sicherheit hinüber. Das Auflegen auf die proprietären Stecksysteme ist auch eine Kunst und Fehler sind nur mit teurem, ebenfalls proprietärem Messequipment nachzuweisen.


    Dämpfung ist (in gewissem Rahmen, diese Konstrukte sind allerdings schneller bei 30dB als einem lieb sein kann) normalerweise aber kein Problem, speziell keines, was Du mit der SNR-Anzeige zu sehen bekommst (AFAIK zeigt die Dream bei DVB-S keinen Pegel an, bestenfalls eine AGC, aus der man grob entnehmen kann, wie hoch der Vorverstärker aufdreht). Für eine massive Verschlechterung der SNR müssen (wenn nicht gerade so viel gedämpft wird, dass das Signal im Restrauschen ersäuft) andere Dinge dazu kommen, z.B. Crosstalk oder ein kaputter Balun. Insofern kann es nicht schaden, die Einzelteile der Verkabelung genauer unter die Lupe zu nehmen. Meine erste Frage wäre, ist das Zeug (Baluns) wirklich für Sat-ZF gemacht? Die für BK müssen nur bis 900MHz gehen und dürfen galvanisch entkoppeln, die für Sat-ZF tunlichst nicht.


    HTH,
    Andre.

    Quote

    Originally posted by F_brandt
    Ist eine Dreambox von der Hardware her in der Lage gemäß dieser Norm als Client (oder Server) zu laufen?
    Wenn ja, geht das schon oder fehlt evtl. noch Software hierfür?


    Die Hardware ist prinzipiell geeignet, sowohl als Client als auch als Server zu arbeiten. Die Grenzen sind hier primär bei der NIC zu suchen, die 100Mbps aller z.Z. erwerbbaren Modelle skalieren da nicht beliebig, aber auf der Clientseite doch ganz ordentlich.


    Die Software ist untenrum auch schon vorbereitet, wie man an obigem (funktionierende Bouquet-Einträge) ja schon sehen kann. Das eigentliche Problem ist, dass SAT>IP ein Paradigmenwechsel ist - plötzlich wird aus jeder Box eine n-Tuner-Box (mit unbekanntem n), ob noch was frei ist entscheidet sich erst wenn man den Server danach fragt, es kommt eine ganze Welt neuer möglicher Fehlerbilder dazu etc. Und da fragt sich, was von DMM diesbezüglich kommt - schließlich finanzieren die sich über den Hardwareverkauf. Mit Zero-Tuner-Boxen, die bezüglich paralleler Aufnahmen eine 7020HD oder 8000 in den Schatten stellen könnten, zerfällt der ganze etablierte Markt. DMM hat ja (AFAIK) auch keine Anstalten gemacht, sich in den Headend-Markt für SAT>IP zu stürzen. Ein sofortiger Einstieg in diesen Markt (also vor zwei Jahren) mit einer Palette von Headends und Zero-Tuner-Clients hätte da vielleicht komplett frischen Wind gebracht, aber er ist halt nicht passiert (oder wenn Goliath so was werden sollte, dann wurde es zu lange zurück gehalten). Da Partnerbox incl. Remote Streams ja schon länger funktioniert, hatte man wohl auch nicht direkt sofort Handlungsbedarf gesehen. Dabei kommen einem sofort coole Ideen, wenn man drüber nachdenkt - wenn alle Dreamboxen am LAN automatisch ein SAT>IP-Cluster aus allen vorhandenen Tunern bilden würden, das dann wiederum allen zur Verfügung steht, und das am besten auch gleich Quellenneutral (DVB ist auch -C und -T)...


    Anders gesagt, keiner weiß was (von DMM) kommt und ob es gut genug sein wird, um sich komplett in SAT>IP zu stürzen und das olle Koax endlich loszuwerden.


    HTH,
    Andre.

    Quote

    Originally posted by netdom
    An sich funktioniert es, aber leider nicht im Cron. Habt ihr eine Idee woran das liegen könnte ?


    Sowas liegt eigentlich immer daran, dass Cron nur minimale Suchpfade (PATH) setzt, woraufhin dann diverse Kommandos nicht gefunden werden.


    Bash
    #!/bin/sh
    #set -x
    /bin/date > /media/hdd/dyndns/file.txt


    Wenn Du hier stattdessen sowas wie

    Code
    exec >/media/hdd/dyndns/log-`date +%Y%m%d%H%M%S`.txt 2>&1


    hinklebst, hast Du ein vernünftiges Log. Wenn Du dann noch Dein obiges set -x (oder gleich set -xv) scharf machst, auch mit Debug.


    Code
    DATA=$(/usr/cat /media/hdd/dyndns/update.api | ...


    /usr/cat? Siescheer dat?


    Quote

    Das ist mir auch schon mit anderen Scripten so gegangen, ich versteh es nicht.


    Es ist eigentlich immer ein Pfad - oder etwas, das beim Versuch, die Pfade absolut zu machen, schief ging. BTW, man kann den PATH auch im Script als allererstes aufblasen, dann spart man sich das rumfriemeln an jedem einzelnen Befehl ;)


    HTH,
    Andre.

    Quote

    Originally posted by arcade
    BusyBox v1.19.4 (2013-06-03 21:22:04 CEST) multi-call binary.


    Usage: tune2fs [-c MOUNT_CNT] [-i DAYS] [-L LABEL] BLOCKDEV


    Wuargh. Mir war nicht klar, dass selbst die e2fsprogs in einer von BusyBox lobotomisierten Version beiliegen. Man könnte jetzt die richtigen e2fsprogs für OE2.0 bauen, ich hab sowas mal früher für OE1.6 gemacht, um an filefrag und e2freefrag ranzukommen, aber meine Build-Umgebung gerade nicht zur Hand. In Deinem Fall ist die Lösung aber einfach: Da es externe Platten sind, hängt man die einfach kurz an einen richtigen Rechner auf dem Linux läuft (zur Not halt ein Live-System booten, ich empfehle GRML), setzt den Befehl ab und hängt sie wieder an die Dream.


    HTH,
    Andre.

    Quote

    Originally posted by abero
    Jetzt konnte ich vorher jedoch noch ein 250MB großen RAW-Dump namens 'FLASH' (ohne Endung) auf den PC sichern. Gibt es irgendeine Möglichkeit aus der Datei noch Config-Dateien zu extrahieren?


    Im Prinzip ja. Man müsste den konkreten Abschnitt mit dem UBIFS von / lokalisieren und dann auf einer Hostmaschine mit nandsim und UBIFS im Kernel das Filesystem mounten. Wie das prinzipiell geht, ist hier angedeutet. Das liest sich aber, als sollte man da einigermaßen wissen was man tut oder man kann sehr viel Zeit zubringen...


    Quote

    Das ich es nicht zurückflashen kann ist mir klar ;)


    Das ist eine besonders spannende Frage (nicht in Deinem Fall, das Ding würde ja dann wieder nicht mehr booten). Aber wir haben hier eine 100% bitidentische Kopie der Payload-Daten des Flashs. Im Prinzip muss man die auch wieder so in den Flash kriegen, wobei eine optimierte Schreibroutine unangetastete Erase-Blocks identifizieren und nicht sinnlos überpinseln sollte. Also eher nicht sowas wie dd nach /dev/mtdblock3 ;)


    HTH,
    Andre.

    Quote

    Originally posted by pepo83
    Also bei mir hat das Defragmentieren nicht viel gebracht:
    vorher 90%
    nachher 83%
    ?(


    Der von xfs_db ausgegebene fragmentation factor ist mit einiger Vorsicht zu interpretieren, genaues dazu sagt die Manpage. Dazu kommt:

    • Ohne weitere Parameter läuft ein Aufruf von xfs_fsr maximal 2 Stunden (oder höchstens zehn Durchläufe, wenn es schneller gehen sollte). Große und böse fragmentierte Filesysteme sind in dieser Zeit aber nicht komplett zu schaffen. Das ist kein Problem, weil die Wirkung kumulativ ist. Also nochmal aufrufen.
    • Standardmäßig sichert xfs_fsr seinen State in /var/tmp, was aufgrund der falschen Persistenzeigenschaften dieses Directories auf der Dream nicht so clever ist. Es macht allerdings auch wenig Unterschied, wenn man das bloß alle Jubeljahre mal aufruft, einigermaßen regelmäßige Runs (sagen wir mal wöchentlich) profitieren aber von der Option -f um das woanders zu parken.
    • Sehr volle Filesysteme oder solche mit bereits enormer Free Space Fragmentation werden nicht von einem Durchlauf optimal. Im Worst Case verbessert sich nichts mehr, obwohl noch jede Menge ineinander verschachtelte Kämme rumliegen. Daher am besten defraggen, nachdem man größere Löschaktionen hatte.
    • Verbose (-v) ist sehr hilfreich bei interaktivem Aufruf (man sieht dann, welche bösen Kämme mit >20000 frags man so ansammelt, und ob es bereits Probleme gibt, noch Free Space zu finden - wenn also ein File nicht bis zu einem einzigen Extent zusammengefaltet werden kann oder oft kommt, dass keine Verbesserung mehr möglich ist, dann weiß man bescheid). IMO bringt es aber gar nichts, einen Aufruf über Cron Verbose laufen zu lassen, zumal auf der Dream kein MTA läuft. Ausnahme wäre, wenn man den Log irgendwohin abwirft, um ihn später anzusehen.


    Unter dieser Maßgabe mal eine Idee für ein triviales defrag-Script, das interaktiv und unter Cron laufen sollte (ich nehm für den State /media/usb aber das kann auch im Flash oder auf der HDD liegen - rennt ja nicht aller paar Minuten, schreibt dort nur wenig und die HDD läuft sowieso):

    Code
    #! /bin/sh
    OPTS=""
    tty >/dev/null && OPTS="$OPTS -v"
    exec xfs_fsr $OPTS -f /media/usb/.fsrlast


    HTH,
    Andre.