Posts by ABPSoft

    Quote

    Originally posted by juanito_perez
    Was nicht funktioniert ist der Explorer (explorer.exe).


    Lies noch mal ;)
    Der Explorer funktioniert auch. Du landest lediglich in einem völlig leeren Verzeichnis, weil OE2.0 Dich nach /home/root wirft. Wenn er allerdings nicht gestattet, von da wegzunavigieren, dann ist das hässlich. Leider ist im Directory Listing auch kein ".." drin, mit dem man nach oben käme.


    Netman hat die Lösung hier aber schon anderswo gepostet: Einen Nutzer anlegen, der FTP-Zugriff gestattet und / als HOME hat.


    HTH,
    Andre.


    Edit: Richtig lesen gilt bilateral ;)

    BTW, blkid ist sogar noch cooler, ohne Parameter sagt es einem alles, was sich zu irgendwelchen angeschlossenen block devices sagen lässt:

    Code
    root@dm800:~# blkid
    /dev/sda1: LABEL="hdd" UUID="49bde8eb-f1f7-4a89-9c56-9ad640979f5e" TYPE="ext2"
    /dev/sdb1: LABEL="USB1" UUID="9fd3eef8-1f06-4784-8e65-bf5561c8163c" TYPE="ext3"


    Was die Konvertierung von ext2/3 nach ext4 angeht, kann ich nur auf https://ext4.wiki.kernel.org/i…n_ext3_filesystem_to_ext4 verweisen, da steht alles was es zu wissen gibt. Vorher umount versteht sich ;)


    HTH,
    Andre.

    Quote

    Originally posted by msxler
    Ich habe jetzt die bei meiner DM8000 die Festplatte mit dem Speichermanager von DMM neu formatiert und ich kann nirgens erkennen ob es jetzt ext3 oder ext4 formatiert ist.
    Im fstab steht nur noauto.
    Gibt eine Anzeige (die man im Telnet) eingeben kann um das zu sehen??


    Code
    cat /proc/mounts


    Das zeigt allerdings, wie es gemounted ist, nicht wirklich was da für ein FS drauf ist. Um 100% sicher zu sein, braucht man dumpe2fs, aber das liegt bei Dreams üblicherweise nicht dem Image bei. Könnte sich aber mit OE2.0 geändert haben. Dann

    Code
    dumpe2fs /dev/sda1 | head


    und das Gerät anpassen. Ein ext4 erkennt man an extent unter den Filesystem Features.


    Quote

    Zum weiteren habe ich gelesen, dass man ext3 in ext4 konvertieren kann. (Ohne die Daten zu verlieren)
    Auch hier welche eingaben müssen da gemacht werden??


    Willst Du das wirklich? Du kommst nicht mehr zurück, kannst also kein OE1.6 mehr nutzen, ohne das FS zu versenken. Das will wohlüberlegt sein...


    HTH,
    Andre.

    Quote

    Originally posted by netman


    adduser ftp -h / -S -D -H


    (ftp ist mein hier gewählter neuer User, ihr könnt natürlich auch andere Namen verwenden.
    Mit dem Parameter -h / wird dem User das rootverzeichnis zugewiesen)


    Vorsicht. Der Nutzername ftp hat unter Unix traditionell eine Sonderbedeutung, er aktiviert den anonymen FTP-Zugang. Mag sein, dass das auf der Dream mit dem aktuell beiliegenden FTP-Daemon keine Auswirkung hat, aber ich wollt's gesagt haben. Insbesondere, falls jemand die Idee auf andere Linux-motorisierte Appliances oder Server überträgt.


    HTH,
    Andre.

    Quote

    Originally posted by sin
    Hab grade bestimmt 30-40x "opkg remove blala --force-depends" eingegeben umd das image wieder "sauber" zu machen. :tongue:
    Davon ab das z.t. die geringsten sachen schon nen "--force-depends" brauchen.


    Das könnte sich mit diesem Update deutlich geändert haben:
    http://git.opendreambox.org/?p…5677f5f96d9c73322d91b275f
    Falls wirklich Recommends als harte Depends gewertet wurden, dann verwundert ein solches Verhalten nicht mehr.


    HTH,
    Andre.

    Quote

    Originally posted by oneone
    ich weiß hier einfach iChat mehr weiter, warum klappt der Pc und die dream nicht... Es ist mir ein Rätsel.


    Erstmal Gratulation zum Umbau. Damit, und mit dem Switch am Ende, hinter dem bereits ein anderes Gerät funktioniert, kann man die physikalische Qualität der Strecke eigentlich komplett aus der weiteren Fehlerbetrachtung entfernen. Leider gibt es auch oberhalb des Layer 1 noch genug weitere Schichten, auf denen was schief gehen kann...


    Fragen/Tests:
    [list=1]
    [*]Wer ist in Deinem LAN eigentlich der DHCP-Server?
    [*]Benutzt der NC10 DHCP?
    [*]Bekommt die Dreambox im STOP-Modus eine IP? Kannst Du die dann pingen und kommst Du mit dem Browser auf das WebIF des SSL?
    [*] Wie hängt die neue Strecke eigentlich genau an der Headendseite am Netz? Speziell im Vergleich zum Anschluss des Powerline-Modems?
    [/list=1]
    HTH,
    Andre.

    Quote

    Originally posted by DeMaddin
    Bei Win geht das blitzschnell, weil da schlauerweise nur der Dateiheader gelöscht wird. (Daten sind physikalisch noch da)


    Das ist bei anderen Filesystemen, auch ext3 auf Linux, nicht anders. Wie lange es dauern würde, Deine hypothetischen 50GB komplett zu überschreiben, kannst Du ausrechnen - bei den bescheidenen SATA-Controllern und schlaffen CPUs, von denen wir hier reden, mal grob mit 15MB/s reingehen...

    Quote

    Aber Linux auf der Box meint, es müsste gleich den zu löschenden Bereich formatieren. Warum ist das so?


    Es ist nicht so. Wenn Dich interessiert, wie es wirklich ist: Wie das klassische Unix FS, BSD FFS, UFS und ext2 benutzt auch ext3 die Blockadressierung über direkte, indirekte, doppelt indirekte und dreifach indirekte Blöcke. Je größer ein File wird, um so mehr Indirektion über Metadaten steckt drin. Außerdem sind alle Blöcke in Bitmaps verzeichnet, um schnell entscheiden zu können, ob sie belegt oder frei sind. Ein richtig großes File zu löschen bedeutet also, massenweise Blockpointer auf Blockpointer zu entsorgen und parallel Bitmaps zu manipulieren. Nun, das geht nicht so sehr schnell, aber man kann schon noch damit leben - wie ext2 und die anderen Exemplare dieser FS-Generation (Stand späte 80er/frühe 90er) demonstrieren. Pappt man jetzt aber an so ein FS ein Log aka Journal dran, in dem jede Metadatenoperation zunächst abgelegt, synchron rausgeschrieben und erst dann an den Live-Daten appliziert werden muss, und hat dieses Journal auch noch I/O-Priorität vor dem Rausschreiben gewöhnlicher Daten, und macht man zur Krönung auch noch den Fehler, dem FS ein Autocommit nach spätestens 5 Sekunden zu verpassen, ja dann - hat man das ext3-Problem "Löschen vieler oder großer Files, oder gar vieler großer ist langsam wie die Krätze und blockiert die eigentlichen Funktionen des FS destruktiv".


    Die Lösung, damit das wieder skaliert, heißt Reduktion der zu loggenden Metadaten-Operationen. Macht man am besten, indem man von Blockmapping auf Extents umsteigt. Ext4 tut das, behält aber ansonsten die Struktur von ext2/3 bei. XFS tut das, aber auf modernerer Grundlage. Beide zippen olle Files wieder so, wie man das erwartet. Ext4 momentan noch ein winziges bissel schneller als XFS bei geringer Parallelität (ein oder zwei Cores), danach überholt XFS. Auf der Dream und ähnlichen PVRs sind sie daher gleichwertig, XFS hat aber noch andere Vorteile, die letztlich wohl auch erklären, warum DMM es momentan favorisiert. Im Prinzip ist XFS sogar kompatibel mit OE 1.6, denn das gab es schon dazumal. Vielleicht kriegen sie ja wenigstens hin, dass die 800HD mit XFS läuft, wenn es da schon nicht zu einem Kernel aus diesem Jahrzehnt reicht...


    Andre.

    Quote

    Originally posted by deadcantdance
    Okay, danke für die schnelle Info. Wenn Du mir jetzt noch sagst, was ich wo ändern muss, damit das Clonen funktioniert...


    Edit: Ich denke ich habs gefunden, GIT_BRANCH im Makefile, korrekt?


    Ja, wobei das eigentlich da drin stehen sollte, wenn es das Makefile aus OE 1.6 ist. Ich hab mir das einfach aus dem Repo gezogen und damit den Rest bootstrapped.

    Code
    ...
    * [new tag] shr/testing2009-1rc1 -> shr/testing2009-1rc1
    You asked me to pull without telling me which branch you
    want to merge with, and 'branch.opendreambox-1.6.merge' in
    your configuration file does not tell me, either. Please
    specify which branch you want to use on the command line and
    try again (e.g. 'git pull <repository> <refspec>').
    See git-pull(1) for details.


    Ähm, sieht aus als wäre Dein geclontes Repository unrund, evtl. durch den kaputten GIT_BRANCH. Am einfachsten dürfte es sein, alles automatisch Erzeugte außer dem Makefile wegzuschmeißen, ein "make initialize" zu geben und dann nochmal zu gucken. Ich weiß nicht genau, wie die Umgebung aussieht, die das hier diskutierte Script präpariert, das nackte OE 1.6 Makefile macht unter dem Toplevel ein Directory für den Boxtyp (MACHINE mit Default dm8000), da drin liegt der Clone von openembedded. Im einfachsten Fall reicht zum Aufräumen also ein "rm -rf dm8000/openembedded" gefolgt von "make initialize". Man kann aber gefahrlos alles wegwerfen, das Makefile in ein leeres Directory stecken und dort starten, der Rest wird angelegt und geholt.


    HTH,
    Andre.


    Edit: Aktuelles Makefile gibt's hier, hab vergessen dass das in 'nem anderen Repository steckt: http://git.opendreambox.org/?p…-opendreambox-1.6;hb=HEAD

    Quote

    Originally posted by deadcantdance


    Code
    git branch --track opendreambox origin/opendreambox || true; \
    git checkout -f opendreambox \
    )
    fatal: Not a valid object name: 'origin/opendreambox'.
    error: pathspec 'opendreambox' did not match any file(s) known to git.
    make: *** [/home/user/openembedded/1.6/openembedded/.git] Fehler 1


    Was läuft schief?


    Der remote branch, den Du tracken willst, heißt opendreambox-1.6. Wenn Du nachsehen willst, geht das (ohne Git-Fu) am schnellsten auf http://git.opendreambox.org/?p=openembedded.git;a=summary.


    BTW, OE2.0 braucht wirklich kein Script mehr. Repo clonen, reingehen, make image. Bzw. momentan vorher noch vor die kaputten letzten Commits zurückspulen ;)


    HTH,
    Andre.

    Quote

    Originally posted by elisen-jens


    danke; cooler Tipp; aber das heisst, dass mein TV-Browser und DCC immer mit neuen IPs versorgt werden müssen, oder? Hab das alles auf meinem Windoof-PC so schön verlinkt...


    DHCP kann die Dream (und alles andere) genauso gut immer mit der selben IP "versorgen". Meist per MAC Address Reservation.


    HTH,
    Andre.

    Quote

    Originally posted by gutemine
    Das debian etch kann mann nicht mehr mit debootstrap runterladen weil schon zu alt


    Auch nicht mit archive.debian.org als Mirror? Dort geht's mit buzz los ;)


    Andre.

    Quote

    Originally posted by pepo83


    Also bei dem Test ist XFS eine Spur schneller.


    Klingt ja schon recht vernünftig, nach den ersten Meldungen hier konnte einem Angst werden. Eine vernünftige Blocksize zum Testen mit dd wäre wohl eher 1MiB oder 2MiB, glaube kaum dass E2 auf Boxen mit so wenig RAM noch größere Puffer beim Rausschreiben benutzt. Hast Du das mit Standard-Mountoptions laufen? Mal allocsize probiert? Und das wichtigste - fühlt sich das bei Aufnahme und Wiedergabe auch vernünftig an?


    TIA,
    Andre.

    Quote

    Originally posted by LukaNoah
    Ich kopiere gerade nen Film zurück auf die Box. Übertragungsraten zwischen 4 und 5 Mbit/s. (WinSCP)


    Ich würde jetzt nicht gerade SCP als Benchmark nutzen. Das testet primär den Crypto-Durchsatz der beteiligten CPUs, und mindestens eine davon ist schwächlich. FTP ist da näher dran (und sollte 100Base-TX saturieren, also ca. 11MB/s zeigen), aber am besten sind lokale Tests mit dd(1) von bzw. nach /dev/zero bzw. zwischen zwei Files.


    Kannst Du mal "grep sda /proc/mounts" machen, mich interessiert mal, wie die Parameter bei Defaults aussehen. Für einen PVR wäre als erstes sowas wie "allocsize=4m" hilfreich, eventuell auch noch größer (64m). Preallocation block clustering hilft sehr gegen übermäßiges Fragmentieren. Apropos, XFS hat den großen Vorteil, dass mit xfs_fsr ein bewährter Online-Defragger verfügbar ist. Der von ext4 ist AFAIK immer noch Alpha.


    HTH,
    Andre.

    Quote

    Originally posted by meierlemeierle@gmx.de
    kann mir jemand sagen, wie lange das bauen des cross-compile-systems dauert?


    Mein Rekord: 90min. Leerer Cache, aber praktisch alle Downloads schon da.


    Siehe hier: Beschleunigung der Image-Erstellung durch Doppelkern


    Quote

    ich mache das unter einem aktuellen debian in einer virtuellen maschine (vm hat einen kern und 1gb ram, physikalisch ist es ein p6600 mit 4gb ram).


    Das ist dünn. Mehr Cores spendieren, parallelisieren... und auf dem Blech rechnen. Ich fahre Debian Testing nativ auf meinem Laptop. Damals hatte ich auch noch psyco, das ist aber irgendwie nicht mehr in Wheezy drin. Und so extrem viel bringt es auch nicht, dass das Größenordnungen ausmachen würde.


    Quote

    edit: bin nun seit fast 10h dabei und bei schritt 289 von 2400... aber kann doch keine 4 tage dauern??? auf der ersten seite steht etwas von 4-24h - aber in abhängigkeit vom alter des beitrags wäre ich von wenigen stunden ausgegangen...


    Das hält sich nicht zufällig mit Downloaden auf? Ansonsten noch E/A, es werden halt exzessiv viele kleine Files erzeugt und rumgeschubst. Da hilft 'ne SSD mehr als alles andere ;)


    HTH,
    Andre.

    Quote

    Originally posted by oneone
    Also das sind zwei kupferrote LAN Kabel gewesen.


    OMG.


    Die Farbe war mir eigentlich egal. Allerdings ist Verlegekabel meistens grau, magenta oder gelb, folglich (und angesichts das Faktes, das wohl Stecker dran waren) liegt da wahrscheinlich flexibles (also Patchkabel). 40m Patchkabel steht übrigens nicht im Standard. Das kann gehen, aber es kann auch Ärger machen. Deswegen misst man es.


    Quote

    Ich weiß ich aber nicht ob der techniker das gemessen oder wie du schreibst einen durchgangsprüfer genutzt hat. Er hat auf dem einen Ende ein Gerät aufgesteckt und auf dem anderen ebenfalls ein kleineres und da liefen dann LEDs durch. Der Techniker sagte, das jedes Lämpchen eine Litze ist und wenn die alle leuchten ist die Verbindung da.. Und das war so...


    Also doch. Durchgangsprüfer. Sehr hilfreich, wenn man Klingeldraht verlegt. Für TP bestenfalls zu gebrauchen, um einen abben Draht nachzuweisen, aber nicht als Qualitätskontrolle.


    Quote

    Wenn das jetzt nur der Durchgang gewesen ist, wo kann dann noch der Fhler liegen??


    Widerstand, Kapazität, Schräglauf, Paarfehler, NEXT, FEXT...
    Bereits Cat5 ist recht anspruchsvoll und geht schneller kaputt, als man denkt, beispielsweise wenn Bauarbeiter auf dem Kabel rumlatschen als wär's die Strippe an ihrer Hilti. Cat5e ist noch zickiger. Cat6a ist eine Herausforderung. Cat7 gibt's zum Glück so selten wie die Leute, die es auflegen können (dank fehlender Standardisierung eines Steckgesichts)...


    Quote

    Gelötet hat der nix.
    Mit profivbinder meine ich hält so ein kleines Kästchen vo auf beiden Seiten das Kabel reingeht und im inneren die einzelnen Litzen mteinander verbunden werden.


    Womöglich noch geschraubt? So etwas gibt es für Litze nicht.


    Quote

    Des weiteren hat er noch auf jedem ende einen neuen Stecker drauf gemacht. Die alten hatte ich abgeschnitten um das Kabel besser zu den Zielorten verlegen zu können. Das Haus ist älter und hat sehr schmale leerrohre


    Du hast also tatsächlich Patchkabel genommen, die Stecker abgeschnitten und dann durchs Leerrohr gezogen. Argh...


    Die Situation ist aber noch zu retten. Wie gesagt, in der Mitte ebenfalls Stecker draufcrimpen und eine Cat5-Kupplung nehmen (oder besser Cat5e, die sind geschirmt). Apropos Schirm: Dein "die Dream flippt aus, der Läppi aber nicht"-Effekt könnte auch ein Fehlstrom-Effekt sein. Man legt eigentlich kein Kupfer zwischen potenziell unabhängig stromversorgten Gebäudeteilen. Potenzialunterschiede können bis zum Abfackeln der Endgeräte führen, und die Versicherung winkt dankend ab.


    Quote

    Ich hab im i net ein wenig rumgelegen und was gefunden, wo geschrieben wurde das es eine a und eine b Variante des Auflegens gibt. Kann es damit was zu tun haben, und was meint diese Umschreibung.


    Das ist so ziemlich das Einzige, was nicht stören dürfte. Ein Mismatch zwischen EIA/TIA 586 A und B führt lediglich dazu, dass die Paare 1/2 und 3/6 anschließend gekreuzt sind statt gerade, was bei Geräten aus den letzten 6 Jahren niemandem mehr auffällt, weil Auto-MDI-X inzwischen überall im PHY eingebaut ist. Viel wahrscheinlicher ist einer der vielen anderen Fehler, die passieren können. Klassiker sind Paar-Mismatches, weil dabei die prinzipielle Funktionsweise von TP (paarweise Verdrillung) nicht mehr greifen kann. Dann geht allerdings auch 10Base-T kaum noch - das kriegt man zwar noch über Sternvierer, aber auch nur getrennt verseilt.


    BTW, richtig Crimpen will auch gelernt sein, besonders unter räumlich erschwerten Bedingungen, wenn etwa die Kabel irgendwo bloß 20cm aus der Wand gucken oder sowas. Umso wichtiger ist die Qualitätskontrolle mit einem geeigneten Messgerät. Die kosten in der Einstiegsklasse vierstellige Summen, aber man kann sie ausleihen. Am besten gleich mit dem Techniker dran, der sie auch bedienen kann und die nötigen Werkzeuge (Crimpzange, LSA+ etc) dabeihat.


    HTH,
    Andre.

    Quote

    Originally posted by oneone
    Das Kabel wurde mittels Profi verbinder miteinander verbunden. Es wurde keine steckervariante genommen sondern Draht auf Draht gelegt!!


    Was heißt denn "Profi verbinder"? Wenn es eine LSA+ Leiste ist, sollte es bei Verlegekabel normalerwiese gehen, jedenfalls mit 100BaseTX. Das Auflegen am Patchfeld bzw. an einer Dose benutzt die selbe Technik.


    Quote

    Nochmals, der Tester zeigt, dass das kabel absolut in Ordnung ist.


    Das ist schon wenigstens ein PentaScanner, der das Kabel als Cat5 Link zertifiziert?


    Ich habe schon Leute gesehen, die TP gelötet haben und meinten, ein Durchgangsprüfer wäre ein Test. Es klingt so, als hätte der Installateur das hier besser gemacht, aber man muss halt nachfragen ;)


    Quote

    Was meinst du mit flexibles und Starr???


    Verlegekabel ist starr (Adern sind massives Kupfer), Patchkabel ist flexibel (Adern sind Kupferlitze). Man kann Litze weder vernünftig auf LSA+ auflegen noch anderweitig korrekt verlängern, außer man Crimpt Stecker dran und benutzt eine TP-Kupplung passender Güteklasse. Zur Not auch eine zur Kupplung umfunktionierte Doppeldose.


    HTH,
    Andre.

    Quote

    Originally posted by ultrax
    ... und im vierten Durchgang lief der Film sauber bis zum Ende durch. Wie soll man da eine Fehlersuche durchführen???


    Man macht ein Häkchen in der Spalte "Fehlerbild unsystematisch bis erratisch, schwer reproduzierbar", holt neuen Kaffee und sucht weiter. Oder gibt auf ;)


    Wie ich so Deine Beschreibung lese, fällt mir auf, dass ich das Fehlerbild kenne. Ich hatte letztens mal ein MKV von einer Serienfolge aus weniger stürmischen Torrent-Zeiten ausprobiert, mit ähnlichen Effekten. Das hatte auch (24000/1001)fps und ich vermutete das Problem eher dort. Zuerst war sofort alles dunkel (TV meinte HDMI wäre verstummt). Autoresolution ausschalten änderte die Lage fundamental. Wieder angeschaltet und so lange getuned, bis das Bild blieb. Dann aber die von Dir beschriebenen Effekte: Es bleibt manchmal ohne ersichtlichen Anlass stehen, und wenn es läuft hat es geradezu unerträglichen Judder (so heftig, dass mir leicht übel wird). Ich habe dann einfach aufgegeben, weil es eh nur ein Experiment war und ich MKVs auch gleich auf'm USB-Stick an den TV stecken kann.


    Hast Du Autoresolution an? Scheint ja auch sonst an Plugins auf Deiner Box kein Mangel zu herrschen ;)


    HTH,
    Andre.