Posts by ABPSoft

Hi,

danke erstmal allen, die sich so lange mit dem Thema beschäftigt und die Resultate hier in Form von Code und Beiträgen publiziert haben, bis sich aus den drei Threads ein klares Bild zur generellen Vorgehensweise ergab. Ich habe mir damit einen Boot-Stick gebastelt (ohne das Plugin oder Script zu nutzen, ich wollte genau wissen wie es geht) und der hat zu meinem eigenen Erstaunen wirklich beim 1. Versuch gebootet

Mein ungutes Gefühl war damit aber nicht weg: Bei meiner 7020HD wechselten in der Vergangenheit der USB-Stick und die HDD mit schöner Regelmäßigkeit die Erkennungsreihenfolge, mal war der Stick sda und die HDD sdb und dann mal wieder umgekehrt. Dank UUID-Mount ist das an sich kein Problem, aber UUID-Boot funktioniert nur mit initrd und PARTUUID gibt's erst seit Kernel 3.8. Also muss die Erkennungsreihenfolge für die korrekte Funktion stabil sein, sonst habe ich eine 50-50-Chance dass es nicht bootet. Wie sind denn da die Erfahrungen in der Praxis bei Einsatz des Plugins? Ist ja nun eine Weile in der freien Wildbahn...

Mein Vertrauen stieg jedenfalls deutlich, als ich diesen Kernel-Parameter entdeckte:

usb-storage.delay_use=
                        [UMS] The delay in seconds before a new device is
                        scanned for Logical Units (default 1).

Ich boote jetzt mit

/boot/vmlinux-3.2-dm7020hd.gz rootfstype=ext4 root=/dev/sdb2 usb-storage.delay_use=3 rootdelay=8 rw console=ttyS0,115200

was heißt, dass der USB-Stick erst ca. 3-4s nach seiner Entdeckung am Bus wirklich als Storage aktiviert wird. In der Zeit hat sich dann die HDD ziemlich sicher gemeldet und ein Race ist sehr unwahrscheinlich. Bis zum Ablauf von rootdelay ist der Stick dann mit Sicherheit da und wird gemountet (* markiert die interessantesten Zeilen):

[*   0.655000] Waiting 8sec before mounting root device...
[    0.684000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    0.688000] ata1.00: ATA-9: WDC WD30EFRX-68AX9N0, 80.00A80, max UDMA/133
[    0.689000] ata1.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[    0.693000] ata1.00: configured for UDMA/133
[*   0.694000] scsi 0:0:0:0: Direct-Access     ATA      WDC WD30EFRX-68A 80.0 PQ: 0 ANSI: 5
[    0.696000] sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[    0.697000] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    0.698000] sd 0:0:0:0: [sda] Write Protect is off
[    0.698000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    0.698000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[*   0.739000] usb 1-1: new high-speed USB device number 2 using ehci-brcm
[    0.783000]  sda: sda1
[*   0.785000] sd 0:0:0:0: [sda] Attached SCSI disk
[*   0.940000] scsi2 : usb-storage 1-1:1.0
[    1.022000] ata2: SATA link down (SStatus 4 SControl 300)
[*   3.954000] scsi 2:0:0:0: Direct-Access     Generic  Flash Disk       8.07 PQ: 0 ANSI: 2
[    3.960000] sd 2:0:0:0: [sdb] 7987200 512-byte logical blocks: (4.08 GB/3.80 GiB)
[    3.962000] sd 2:0:0:0: [sdb] Write Protect is off
[    3.962000] sd 2:0:0:0: [sdb] Mode Sense: 03 00 00 00
[    3.963000] sd 2:0:0:0: [sdb] No Caching mode page found
[    3.964000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[    3.968000] sd 2:0:0:0: [sdb] No Caching mode page found
[    3.968000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[    4.207000]  sdb: sdb1 sdb2 sdb3
[    4.211000] sd 2:0:0:0: [sdb] No Caching mode page found
[    4.211000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[*   4.212000] sd 2:0:0:0: [sdb] Attached SCSI removable disk
[*   8.675000] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)
[    8.676000] VFS: Mounted root (ext4 filesystem) on device 8:18.

Bisher funktioniert das hier prächtig. In Fällen, wo also SATA HDD(s) gegen genau einen USB-Stick gewinnen müssen, damit der an einer stabilen Position landet, erscheint der Parameter daher sehr hilfreich. Ich wollte das nur an die Entwickler und Tester des Plugins zurückgeben, vielleicht hilft es dort ja auch jemandem.

Thanks,
An"no more UBIFS sudden death"dre.

Quote

Originally posted by Jojojoxx
Mich wundert, dass die Einträge zu den sporadisch auftretenden Ubifs Fehlern bei der 7020hd alle mindestens ein Jahr alt sind, scheinbar hat niemand das Problem bei aktuellen Images mehr.

Naja, die Mehrzahl der Regulars hier spielt wohl inzwischen lieber mit 7080HD und 820HD...

Quote

Ich habe heute bereits zum zweiten Mal (auf einem aktuellen OE 2.0 Image) das Problem gehabt, dass die Box hängt und dmesg massenhaft fehler der folgenden Form auswirft:

Code

May  1 17:52:01 dm7020hd user.err kernel: [ 5710.136000] UBIFS error (pid 6662): ubifs_read_node: bad node at LEB 620:159744, LEB mapping status 0
May  1 17:52:01 dm7020hd user.err kernel: [ 5710.138000] UBIFS error (pid 6662): do_readpage: cannot read page 0 of inode 7186, error -22

Bei mir ist das Problem auch wieder da, und zwar verschärft. Es fing IIRC Ende März an, als die Box beim halben Ladebalken stehen blieb. Hintergrund war eine kaputte libQt* (weiß nicht mehr exakt welche, aber das sind halt mit die fettesten Files auf der Kiste). Ich hab die aus dem Backup ersetzt. Seitdem geht es aber zunehmend rasanter mit Problemen. Ablauf scheint immer wieder folgender zu sein:

[list=1]
[*]Beim Lesen von Files im Flash kommt es zu korrigierbaren ECC-Fehlern und UBI scrubbed den betreffenden LEB (kopiert ihn in einen neuen PEB):

[ 1560.247000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:24afb800
[ 1560.280000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:24afb800
[ 1560.509000] UBI: scrubbed PEB 2315 (LEB 0:1599), data moved to PEB 2645
[ 1561.456000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:252c4a00
[ 1561.459000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:252c4a00
[ 1561.720000] UBI: scrubbed PEB 2347 (LEB 0:1610), data moved to PEB 2623
[ 1569.786000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:26e56c00
[ 1569.789000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:26e56c00
[ 1569.807000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:26e56c00
[ 1570.055000] UBI: scrubbed PEB 2457 (LEB 0:647), data moved to PEB 2595

[*]Irgendwas schreibt im Flash. Größere Updates sind besonders gefährlich, aber mitunter reicht auch schon das Rewrite von keymap, timers oder autotimers.
[*]Beim nächsten Bootvorgang zerbröselt es dann fast immer was und die klassischen Fehler tauchen auf (bad node type (255 but expected 1/2/etc)). Dann folgen Fehler wie die von Dir geposteten.
[/list=1]

Ich hatte das erst gestern wieder und habe dann - weil es langsam nervt - wiederholt das gesamte / in place mit dem letzten tar (wo grad alles noch ging) überschrieben. Das Problem ist nun, dass dabei ständig weitere ECC scrubs stattfinden. Ich mach anschließend ein sync, drop_caches und check dann mit md5sum -c gegen ein Digestfile für das gerade ausgepackte tar. Meistens liefert das weitere ECC scrubs, manchmal sogar neue Lesefehler. Man sollte annehmen, dass das irgendwann mal aufhört, wenn alle altersschwachen Erase Blocks ausgemustert wurden, tut es aber leider nicht. Ich kann mich irgendwie nicht des Eindrucks erwehren, dass das ECC scrubbing manchmal daneben schießt und die falschen EBs trifft...

Quote

Nach allem was ich dazu finde hilft wohl nur ein Neuflashen.

Speziell da habe ich meine Zweifel. Das Neuflashen der 7020HD vom 2nd aus ist ja leider nicht UBI-aware (zumindest war es das nicht, als ich zuletzt geguckt habe), d.h. es zerstört die komplette Nutzungsstatistik von UBI (Erase Counters). Man flasht also zunehmend in EBs, die hohe ECs hatten oder gar zuvor schon wegen correctable ECC errors ausgemustert wurden (nur die komplett kaputten Blöcke werden ausgespart). Wenn obige Theorie zutrifft, dann nimmt das Problem anschließend lawinenartig zu - und mein Verdacht ist, dass das bei mir grade anfängt...

Quote

Das habe ich zuvor dann auch gemacht, aber nach einiger Zeit kommt der Fehler zurück. Gibt es inzwischen irgendeine Möglichkeit, dass dieser Fehler dauerhaft verschwindet?!

Ich spiele mit dem Gedanken, alles auf einen USB-Stick zu verlagern und nur noch von dem zu booten. Schöner wäre es natürlich, wenn die Kiste mit dem eingebauten Flash vernünftig funktionieren würde. Und komisch ist, dass wir ja mal ein reichliches Jahr Ruhe hatten - und in der Zeit kamen noch wesentlich mehr Updates als heute. Die Vermutung liegt nahe, dass der zu Grunde liegende Bug mal gefixt war, aber wieder da ist. Oder aber, dass er schon immer von ECC scrubs getriggert wurde und die mit dem zunehmenden Alter des Flashs jetzt immer häufiger werden...

Fragt sich halt, ob das jemals wirklich gefixt war oder ob das "wir mounten UBIFS nicht mehr sync, weil es das Problem beseitigt" nur die Rate des Auftretens reduziert hat. Ein echter Fix war das allein ja eh nicht, denn man muss von einem Filesystem schon verlangen können, dass es auch bei sync mount korrekt funktioniert. Wenn der Bug im BCM Blob steckt, dann Gute Nacht...

HTH & TIA,
Andre.

Quote

Originally posted by Kaiser Wilhelm
FF legt bei mir die temporären Sachen auf die hdd, da ich noch immer der Meinung bin, dass die ssd länger lebt, wenn ich ihr nicht jeden Schreibzyklus aufzwinge.

Naja, an sich sind ordentliche SSDs wesentlich robuster, als bisweilen kolportiert wird. Die meisten Beschwerden kamen ja schon zu Zeiten der Intel Postville von Leuten, die zwar unbedingt eine SSD haben mussten, aber keine Intel bezahlen wollten - die damals schnell auftauchenden Trittbrettfahrer waren nun mal nicht ausgereift. Heute ist die Lage besser, es gibt genug Produkte die wirklich was taugen. HDDs kommen mir nicht mehr in die Nähe meiner Laptops und Workstations, außer über USB für Backup

Das ist ja das Ätzende: Alles, was normalerweise auf meinem OS so abgeht, macht nur die Schreibzugriffe die wirklich nötig sind. Und ich hab sogar eine Swap-Partition auf der SSD, nur ist halt auch genug RAM drin damit die praktisch nie gebraucht wird. Und dann kommt so ein dämlicher Browser daher und meint, Größenordnungen mehr schreiben zu dürfen als alles, was ich so ernsthaft mit der Kiste anstelle. Dank hdplop (wmhdplop oder in GKrellM) fällt einem zum Glück auf, wenn was austickt, wobei ich das mit FF auch erst gemerkt habe, nachdem mir das S.M.A.R.T.-Monitoring von Total_LBAs_Written bei einer neuen SSD Suspekt wurde.

Quote

Aber alle 15sec eine Sicherung der Tabinhalte ist wirklich nicht notwendig, zumal die Sicherung ja nur nach einem Crash benutzt wird, oder?

Yep, wenn man den Browser sauber beendet, dann schreibt er den Session Store eh noch mal raus. Ich bin ja im Prinzip ein großer Freund des regelmäßigen Sicherns - die Tabs sind mein Exobrain, ohne die sähe ich ziemlich alt aus. Bookmarks ersetzen das nicht, vor allem wegen des Kontexts (History hinter jedem Tab). Daher wäre mir eine zeitnahe, Crash-konsistente Sicherung dieser Daten durchaus wichtig. Nur ist die Ausführung halt mangelhaft. Wieso müssen bei einer Änderung an einem Tab alle anderen (95% davon in dieser Session nie geöffnet) mitgesaved werden? Doch nur, weil das alles in ein einziges File gepappt wurde (noch dazu ein 10MB großer JSON-Einzeiler, viel Spaß dabei da drin was flicken zu wollen). Und das File geht bei Systemcrashes auch gern mal kaputt, was natürlich nachvollziehbar ist bei der Größe und Änderungsrate. Ein File pro tabview-tab und die Welt sähe schon anders aus...

HTH,
Andre.

Quote

Originally posted by cepheus
refesh des shoutbox?

Genau das. Der Impact ist im FF verheerend, wenn dieser mit den Standardwerten für seine Zustandssicherung arbeitet. Ich hatte das mal analysiert, als mir spanisch erschien, wieso mein System stündlich Gigabytes auf die Platte schreibt. Konkret macht FF mit Standardeinstellungen aller 15s ein State Save. Aus irgendwelchen Gründen resultiert es in zwei State Saves direkt nacheinander, im Rhythmus von 30s (aber wenn man sieht, wie dieses Feature sonst so gecodet ist, wundert einen das auch nicht weiter). Ein State Save ist so groß wie sessionstore.js (zu finden im Profilordner), bei meinen bescheidenen 500 offenen Tabs sind das schon mal 10MB, also saved das Ding 20MB aller 30s (40MB pro Minute, macht 2400MB jede Stunde! Das sind 57GB am Tag - schöne Grüße an die SSD...). Nun tut er das immerhin nur, wenn er einen Anlass sieht, den State saven zu müssen - und eine offene Shoutbox auf der IHAD Hauptseite triggered das genau so wie andere Seiten mit Auto-Refresh.

Ich empfehle dringend das Tuning von browser.sessionstore.interval in about:config. Achtung, das sind Millisekunden (man lasse sich das auf der Zunge zergehen - wollen die die Platte saturieren?). Bei mir steht das jetzt auf 300000 und damit gibt es State Saves nur noch aller 5min. Die Coder von dem Spaß können gern wiederkommen, wenn sie einen selektiven State Save beherrschen, bei dem man nur wegschreibt, was sich auch wirklich geändert hat. Glaub aber nicht dass da wer was fixt, wenn man liest wie gelegentliche Reporter dieses Problems von den Verantwortlichen oder ihren Fanbois zurechtgewiesen werden. Möchte nicht wissen, wie viele SSDs die schon mit auf dem Gewissen haben...

HTH,
Andre.

Quote

Originally posted by Pocky
Das ist die Austastlücke wo auch z.B. der Videotext mit übertragen wird.

Wobei das, was man hier konkret sieht, die WSS (Wide Screen Signaling)-Zeile 22 ist, bei der man sich streiten kann, ob das noch Austastlücke oder schon aktives Bild ist. Den Teletext sieht man eigentlich nur bei starker Fehlstellung des Syncs, die WSS (eingeführt mit PALplus, danach essenziell für den Umstieg auf "anamorphes" 16:9) gerät hingegen sehr leicht ins Blickfeld, weil sie erst im Overscan verschwindet. Das Pendant dazu unten ist VHS-Schmutz, der auch besser gnädig im Overscan geblieben wäre

HTH,
Andre.

Quote

Originally posted by cklahn
Vielleicht habt Ihr noch eine Idee?

Das NAS ist mit NFS gemounted und schreibt auf ein POSIX-konformes Filesystem? Das riecht nämlich so, als wären da Symlinks schlicht nicht supported. Es gibt auch noch ein paar mehr Probleme mit dem NFS-Export von Symlinks, weswegen da vielleicht sogar Sicherheitsmechanismen greifen (die etwa absolute Symlinks und solche relativen, die aus dem NFS-Mount heraus zeigen würden, schlicht verhindern, weil die potenziell auf dem Server oder anderen Clients Unheil anrichten könnten) - das wissen dann die Spezialisten für das jeweilige NAS.

Was ich mich fragen würde, wenn ich eine OE2.2-Kiste hätte - wieso muss da doppelt und dreifach kopiert werden? Kriegt man das nicht (mit passenden Excludes und zur Not mit ein paar bind-Mounts) so hin, dass es in einem Stream liest, tared und komprimiert, womit am Ziel genau der Platz gebraucht wird, der für das Resultat nötig ist (und kein Feature jenseits von "man kann da ein File zum Schreiben öffnen und vollmachen")?

HTH,
Andre.

Quote

Originally posted by albatos
Wlan müsste stark genug sein. Habe volle signalstärke angezeigt. Das wlan geht über einen netgear router, an den auch die dm800s per lan angeschlossen ist. Was für ptobleme könnten da vorliegen?

Das Problem hieß bei mir 2.4GHz. Im ISM-Band ist in urbaner Umgebung nichts mehr zu reißen, die Interferenzen machen es für Streaming unbrauchbar. Der Stream wurde magisch stabil (720p, über Stunden, auf Galaxy S4 mini) nachdem ich das 2.4GHz-Radio im AP ausgeschaltet hatte. Da Android ja der letzte Dreck beim WLAN Roaming ist, muss man den Holzhammer nehmen - auf die Idee 5GHz zu nutzen kommt es in den seltensten Fällen von alleine.

Jetzt heißt es nur Daumen drücken, dass 5GHz nicht demnächst genau so zugeschissen ist wie das 2.4GHz ISM heute. Wobei die meisten SOHO-Kisten nur im U-NII-1 und evtl. U-NII-2 senden. Das nächste große Ding wird sicherlich, auf U-NII-2 extended auszuweichen (Kanäle 100-140), weil es dort noch halbwegs ruhig ist...

HTH,
Andre.

Quote

Originally posted by speedy73
Gibt es den eine Möglichkeit die Senderliste in den VLC-Player zu bekommen?

Genau so wie Bschaar zwei Postings weiter oben schrieb. Das Bouquet als Playlist (.m3u) downloaden, im VLC öffnen (oder VLC mit dem m3u als Parameter aufrufen), View/Playlist wählen und schon kann man flott (im Rahmen der zu erwartenden Umschaltgeschwindigkeit des Stream Proxy) rumzappen.

HTH,
Andre.

Quote

Originally posted by Bundy00
Nun habe ich aktuell gerade mal ~ 2- 2,5 MB/s (egal in welche Richtung) und habe keine Ahnung woran das liegen könnte.

Neben der bereits geäußerten Primärvermutung (eine neu hinzugekommene Interferenzquelle) wäre noch zu sagen, dass 802.11n gern bei solchen Datenraten sättigt, wenn die eingebauten Mechanismen für Frame Aggregation abgeschaltet sind. Das wiederum wird manchmal getan, um die Stabilität des Empfangs am Rand der Zelle zu verbessern. Vielleicht schlägt ja ein Automatismus zu, der das für Dich entschieden hat, oder Du hast eine Einstellmöglichkeit a la "Reichweite vs. Durchsatz". Ich kenn die verwendeten Geräte nicht, aber man kann ja mal in dieser Richtung forschen.

HTH,
Andre.

Quote

Originally posted by m0rphU
Im Übrigen würde ich mich immer fragen, warum die Datei kaputt ist. Vllt. ist ja bei dem Stromausfall noch größerer Schaden im Dateisystem eingetreten.

IMO ist keymap.xml ein Canary für unsauberes Runterfahren, was ja bei einem Stromausfall notgedrungen eintritt. Oder wenn die Kiste so hängt, dass einem außer Power Off nix mehr bleibt. Hatte das selbst schon. Hintergrund ist anscheinend, dass keymap.xml bei jedem Booten von irgendwas (hab nicht näher geguckt, wahrscheinlich eine der QuickButton-Inkarnationen) angefasst, modifiziert und neu geschrieben wird. Und wenn das mal nicht mehr sauber gesynced werden kann, isses kaputt - und E2 fliegt dann auch beim nächsten Booten auf die Fresse. Ansonsten schreibt man ja eher wenig im Flash rum, nur bei Updates und vielleicht noch die epg.dat, deren Verlust aber nicht so fatal ist. Es ist also sehr wahrscheinlich, dass es bei sowas nur und ausschließlich die keymap.xml zerlegt hat, aber Ausnahmen bestätigen die Regel.

BTW, ich hab eine Kopie von keymap.xml auf'm /media/usb liegen, weil enigma2 reinstall sich immer etwas zieht. Ist so mit das größte Paket was auf der Box rumfliegt. Also beim opkg install nicht die Luft anhalten

HTH,
Andre.

Quote

Originally posted by gero11
Bleiben die Pugins (GP3.2, Mediaportal, CCCam, usw) vom "force reinstall" unberührt, oder müssen die Plugins danach neu installiert werden?

Der angegebene Befehl ist das minimalinvasive Verfahren, wieder zu einem laufenden E2 zu kommen. Es geht nichts verloren, außer evtl. Patches an E2 oder an der keymap.xml selbst. Da das auch bei jedem einzelnen Update des Pakets enigma2 passiert, kannst Du sicher sein, dass nicht mehr kaputt geht als bei eben einem solchen Update - in der Regel also gar nichts. Kein Vergleich zu neu flashen. Das force reinstall klingt vielleicht brutal, ist hier aber auch nur nötig, um opkg überhaupt zur Arbeit zu verleiten - es würde eigentlich keinen Grund sehen, das Paket in der selben Version noch mal zu installieren, die ist ja schon aktuell und braucht kein Update. Was opkg nicht wissen kann, ist dass da drin ein File kaputt ist und Du bewusst diesen Befehl nutzt, um es zu reparieren.

Da sich E2 bei Dir u.U. in einer Dauer-Restart-Schleife befindet, garnierst Du das opkg vielleicht noch mit einem vorherigen init 4 und einem abschließenden init 3 rein zur Vorsicht.

HTH,
Andre.

Quote

Originally posted by Paulchen P.
Zu Full HD Spezifikation gehört auch 1080i und nein; kein Sender sendet in 1080p, weil das nicht zur jetzigen DVB-S2 Spezifikation gehört.

So wie ich das gehört habe, ist der Hauptgrund, warum man bei diversen Broadcastern auf (mehr Endgeräte mit) HEVC wartet, dass man damit endlich 1080p50/60 auch auf den Sender bekommen kann - und das wird als wesentlich wichtiger empfunden als 4k. Niemand will schon wieder alle Studios, Produktionswege etc erneuern, aber es wär schon schön, wenn man erstmal das inzwischen üblicherweise bei der Produktion anfallende HD-Material auch in der Quellqualität versenden könnte. Weder das Runterskalieren auf 720p50/60 und schon gar nicht der Eierschneider auf 1080i50/60 sind wirklich adäquate Verfahren zum Umgang mit Full-HD-Material. Ausnahmen bestätigen die Regel. Aber man ist ja letztlich froh über jeden Sender, der in sowas wie HD und ohne angeflanschte Schutzgelderpressung zu einem durchdringt...

An"KD hat immer noch nicht ausgebaut"dre.

Quote

Originally posted by Schnello

Code

root@dm7020hd:/media/net# rsync -aPn 192.168.1.1:/dreamboxlog/ /media/hdd/test/
root@192.168.1.1's password:

Wobei genau das kein Daemon-Zugriff war sondern SSH, was man schon daran sieht, dass er nach einem Passwort fragt. Um den Daemon anzusprechen verwendet man zwei Doppelpunkte (oben wäre das also 192.168.1.1::/dreamboxlog/ gewesen) oder schreibt stattdessen einen rsync:// URL.

HTH,
Andre.

Quote

Originally posted by ddinc
Habe bemerkt,daß die Aufnahmen immer in der 59.Min. stoppen und RO mount.

Das klingt ja nun ganz schwer nach irgendeiner verbuggten Powersave-Funktion oder sowas seitens der externen Box. Wann würgt es ihn ab, wenn Du die Platte fünf Minuten vor Beginn einer Aufnahme pingst, so dass sie etwas eher anläuft? Dein Idle ist 600s, die sollte dann also bis zum Beginn der Aufnahme duchlaufen und in der 54. oder 55. Minute wegfliegen, wenn die Theorie stimmt. Hänge bitte auch den Output von dmesg an, kurz nachdem das wieder passiert ist - der e2 debug log hilft hier weniger.

HTH,
Andre.

Quote

Originally posted by drharry
[...] bin nicht davon ausgegangen, das durch Flashen auch mit einem evtl defekten Image ne Platte gehimmelt wird.....

Wird sie auch nicht. Aber so ein Upgrade ist (je nachdem, wie man die Box sonst betreibt) u.U. der erste Power Cycle seit Wochen, wenn nicht Monaten (ich hab hier eine DM800 mit 931 Tagen Uptime, die hat halt keinen FP). Und wenn HDDs mechanisch kaputtgehen, dann meistens bei einem Power Cycle...

Du kannst noch die Rettungswerkzeuge bereit legen und den Kühlschrank probieren, aber ich würde mir wenig Hoffnungen machen. Aktuelle Platten sind mechanisch so hochgezüchtet, dass sie bei solchen Symptomen normalerweise ein Fall für den Elektroschrott sind - oder für Kroll Ontrack und Konsorten, die u.U. Spindeln in Platter zerlegen, neu zusammensetzen[1] und in neue Gehäuse mit anderer Elektronik verfrachten können. Im Reinraum. Für gesalzen viel Geld. Kommt ganz auf den Wert der Daten an...

[1] Wobei ich meine, die Jahre irgendwo gelesen zu haben, dass es damit inzwischen auch vorbei ist. Kriegt man nie wieder so exakt justiert, dass es was nützt. Aber ich kann mich da irren.

HTH,
Andre.

Quote

Originally posted by white_raffaelo
möchte jetzt meine Aufnahmen von der 8000 HD auf die 7080 HD übertragen.
Arbeite mit TotalCommander ( ftp ).
Wenn ich die Datein kopieren möchte ( also von 8000 HD auf 7080 HD ), bekomme ich leider die Fehlermeldung:
Übertragung fehlgeschlagen - entfernte Übertragung wird vom Server wahrscheinlich nicht unterstützt.
Der Umweg über den PC geht, leider nicht von DM auf DM !?

Das ist wohl ein Bug/Misfeature/Entwickler-Ignoranz in vsftpd, ich hatte das hier mal auseinandergenommen. So lange das niemand fixt (oder sich mal anguckt, ob man das beim Build konfigurieren kann und dann OE2.x entsprechend anpasst) wird das mit Proxy-FTP nicht gehen.

Quote

Hat jemand hier einen guten Rat für mich, wie ich am besten direkt übertrage/verschiebe ?

Ich empfehle da rsync, wobei man tunlichst nicht durch SSH tunneln will. Bei solchen Kopieraktionen geht es ja um Terabytes, eine der beteiligten Kisten hat nur 100Base-TX, da ist alles was bremsen kann unerwünscht und es wird sowieso schon Tage dauern. Insofern ist rsync doppelt clever, weil es mehrfach wieder aufsetzen kann.

Um SSH zu umgehen, startet man auf der Empfängerseite den rsync-Daemon und spricht den von der Senderseite aus direkt an. Bei mir hat sich da folgendes in /etc/rsyncd.conf bewährt:

# For rsync access to /media/hdd
[hdd]
        path = /media/hdd
        comment = The Hard Disk Drive
        use chroot = no
        read only = no
        numeric ids = yes
        uid = 0
        gid = 0
        munge symlinks = no
        dont compress = *

Wenn einem das mit dem Daemon zu kompliziert wird, kann man auch einen NFS-Mount zwischen den Kisten etablieren und rsync dann "lokal" kopieren lassen, ist aber ineffizienter.

Ansonsten wäre auch wget nutzbar, um auf der Zielbox die Files von der Quellbox zu ziehen. Musst Du rumprobieren, ob das wieder mal an BusyBox-Lobotomie scheitert oder ob das wget auf der Box alles kann was gebraucht wird. Ich persönlich bevorzuge rsync gegen den Daemon, da weiß man was man hat.

HTH,
Andre.

Quote

Originally posted by cs_e
Das mit den WD Red stimmt...die sollen durchlaufen.

Wieso behauptet das hier neuerdings jeder? Forenspezifisches Mem? Liest kein Mensch mehr Datenblätter? Als ich zuletzt nachgesehen habe, hatte die WD Red doppelt so viele Parkzyklen spezifiziert wie vergleichbare Green, genau weil sie in jedem typischen SOHO-NAS bei Nichtbenutzung in den Standby geschickt werden. Jetzt könnte man argumentieren, dass Power Off nicht das selbe ist wie Standby, aber bevor ich das glaube hätte ich gern eine externe Quelle mit einem zumindest minimalen Vertrauensbonus oberhalb von Schwafelclub. Das einzig Beunruhigende was ich kenne ist die Ausfallrate von WD Red 3TB bei einem Billig-Cloud-Storage-Provider, die hier letztens referenziert wurde - aber dort laufen die 24/7 ohne Standby, kann also kaum als Auslöser für dieses Gerücht dienen. Wo kommt das her?

HTH,
Andre.

Moin,

momentan baut grad gar nix, weil apt_1.0.9.tar.xz von sämtlichen Mirrors verschwunden zu sein scheint. Da liegt nur 1.0.9.1. Wer's noch in sources liegen hat schätze sich glücklich

Anyway, bevor das nicht zuverlässig läuft würde ich's eh nicht flashen...

Andre.

Quote

Originally posted by citysprinter

Code

dns-nameservers 192.168.178.1 132.180.17.1

Hat jemand eine Idee, weshalb der DNS nicht so richtig funktioniert?

Was landet denn wirklich in der /etc/resolv.conf?
Es gibt ja bekanntlich seit OE2.0 ewig Probleme mit DNS, wenn man die IP statisch konfiguriert. Probleme, die mit DHCP verschwinden. Ich hatte die selbst nie (nutze DHCP mit statischer Lease) und hatte bisher gemeint hier rauszulesen, dass die irgendwie dem GUI und resultierenden Bedienfehlern geschuldet sind. Aber vielleicht ist ja auch mehr kaputt. Die Zeile da oben ist schon mal gut, aber sie muss auch nach resolv.conf transformiert werden (in mehrere "nameserver"-Statements), denn nur dort guckt der Resolver wirklich nach, wen er wie fragen soll.

HTH,
Andre.

Quote

Originally posted by krusta
Da die Daten für mich sowieso schon verloren waren habe ich halt einfach wild rumgespielt ohne zu verstehen, was ich denn da mache.

Das wilde Rumspielen ist an sich keine schlechte Idee, nur sollte man das mit einem Image der Platte machen. Beim Erstellen des besagten Image kriegt man auch sehr schnell mit, ob überhaupt noch was zu erwarten ist: Hier ist ja recht offensichtlich (bereits Dein erster dmesg zeigt das) der Anfang der Platte nicht mehr zu lesen. Da in Block 0 die klassische DOS Partition Table steht, war die weg und damit auch die Partitionierung unbekannt. Alle weiteren Beobachtungen resultieren daraus. Das kann nun bedeuten, dass auch kein anderer Block der Platte mehr zu lesen ist (wahrscheinlich), könnte aber auch nur auf einen Schaden im Außenbereich der Platte zurückgehen (unwahrscheinlich).

Generelle Vorgehensweise:
[list=1]
[*]Image
Hier besorgt man sich am besten erstmal eine neue (und damit leere) Platte mit mehr als der doppelten Kapazität des Opfers. Braucht man ja am Ende wahrscheinlich sowieso. Nun an einem Linux-Host mit GNU ddrescue und passenden Error Retry Parametern eine Kopie in ein File oder ggf. ein Logical Volume anstarten und am besten erstmal in den Urlaub fahren. Nach Stunden bis Tagen kristallisiert sich heraus, ob überhaupt noch Blöcke zu lesen sind und ob man das irgendwann gnädig beendet oder abwartet. Falls man am Ende mehr als 80% der Blöcke doch noch gelesen kriegt (ich hatte Fälle, wo es nur wenige MB erwischt hat, die aber ewig an ein paar anderen schwachen Blöcken kauten), dann lohnt es sich weiter rumzuspielen. Die nächste Aktion ist, die originale Platte weit weg zu legen, das Image noch mal zur Sicherheit wegzukopieren und dann alle weiteren Schritte nur an dem Image vorzunehmen.
[*]PTBL Recover
Da nicht mehr damit zu rechnen ist, die PTBL bei (1) noch gelesen zu kriegen, muss man die als nächstes versuchen selbst wieder herzuzaubern. Oft hilft dabei gpart (Guess Partition Table), aber im vorliegenden trivialen Fall (Sektor 0 tot und auch folgende Blöcke nicht lesbar) kann es passieren, dass das nicht mehr klappt. Also rauskriegen, wie die aussah (andere DB-Besitzer mit ähnlicher Box und Platte fragen) und dann manuell anlegen. Auf dem Image kann man ja schreiben.
[*]Filesystem recover
Du bist schon auf dem korrekten Weg, wenn die PTBL wieder steht und in deren ersten Blöcken schon ein Superblock steht, Gratulation. Sonst mit der Suche nach Superblock Backups anfangen. Wie gesagt, wenn >80% der Blöcke noch da sind, stehen die Chancen gut, einen zu finden. Danach das entsprechende fsck (am besten erstmal mit -n zum antesten, dann irgendwann mit -y um das Unvermeidliche hinzunehmen - was weg ist ist weg, die Metadaten müssen wieder begradigt werden). Und dann gucken, was überlebt hat.
[/list=1]
Falls man nach Schritt 3 den Eindruck hat, da wäre mehr gegangen, einfach das verhunzte Image wegwerfen, eine neue Arbeitskopie von der bei (1) gezogenen Sicherheitskopie machen und auf ein Neues.

BTW, wenn man nicht den Eindruck hat, die Platte zerlegt sich zunehmend mechanisch und jeder Leseversuch zehrt an ihr, kann man erstmal ddrescue nach /dev/null fahren, um die Erfolgsaussichten abzuschätzen. Es ist ja nicht unwahrscheinlich, dass das Fehlerbild (Read Errors) sich über die ganze Platte zieht. Wurde ja bisher kaum versucht, da ohne PTBL kein Grund vorlag, mal weiter hinten zu lesen.

HTH,
Andre.