Beiträge von tyco

    Danke für die ausführliche Anleitung!


    Nun habe ich aber schon - nach fast einer Woche verzweifelter Versuche den TS-409 von Raid1 auf Raid5 zu migrieren - das System nach vorheriger Datensicherung neu aufgesetzt.


    EDIT:
    Raid5 funktioniert also jetzt. Nach dem neu aufsetzen hat das neue Raid5 erstmal 12 Stunden synchronisiert. Ich bin jetzt dabei meine Daten - die ich aus Platzmangel auf vier Rechner im Netzwerk verteilt hatte - zurückzuspielen.


    Nochmals vielen Dank. Vielleicht hilft die Anleitung mit dem Swapspeicher anderen geplagten und verzweifelten Anwendern.


    Schritt 1 bis 4 habe ich auch gemacht und dann den 6. Schritt. Wie funktioniert das mit dem 5. Schritt "Hinzufügen eines USB-Stick als Swap-Speicher"?


    Seit 15 Minuten ist die Migration wieder bei 49% angelangt. Ich lasse den TS-409 mal über Nacht migrieren, in der Hoffnung das es doch noch was wird. :-/

    Zitat von "brausepaul"

    3ter Versuch ist wieder fehlgeschlagen und bei 49% hängen geblieben :(


    Seit 5 Tagen habe ich exakt dasselbe Problem. Bei der Migration von Raid 1 (mit 2 Festplatten) auf ein Raid 5 (mit 3. Festplatte) bleibt die Migration auch nach Tagen bei 49% hängen.


    Habe schon fast alles versucht:


    Firmwareupdate auf die neueste BETA-Firmware
    autorun.sh deaktiviert
    Reset des Qnap TS-409 Pro
    und ich weiß nicht was sonst noch


    Jetzt habe ich hier gelesen, dass die neue Festplatte erst formatiert werden muss und das NAS dies nicht automatisch macht. CHPatrick hatte exakt das Problem, dass die Migration bei 49% hängen blieb. Nach einer Formatierung der neuen Festplatte, konnte er die Migration von Raid1 auf Raid5 erfolgreich durchführen.


    Ich meine ich hätte die Festplatte zu Beginn formatiert, bin mir nach 5 Tagen Gefummel an dem System jetzt auch nicht zu 100% sicher. Nach der Formatierung der Festplatte ist die Migration aktuell bei 18% angekommen.


    Werde mich melden ob es funktioniert hat oder nicht.


    Sonstige Vorschläge zur Problemlösung wären nett.

    Zitat von "hottube"


    Hi, wie geht dass, ich hab einiges ausprobiert, aber mit "oconf init" bin ich nicht richtig weitergekommen. Ist das ein Befehl des cpan?


    An dem Projekt arbeite ich momentan nicht mehr. Soweit ich mich entsinne ist dies ein Befehl von CPAN.


    Allerdings fehlt bei dir ein Leerzeichen zwischen dem o und conf: Somit lautet der Befehl:o conf init

    Zitat von "legolas192"

    Man kann den Spindown der Festplatte deutlich hören, aber die HDD-LED geht nicht aus.


    Die HDD-LED geht auch nicht aus sondern nur die Status-LED.


    Allerdings habe ich auch das Problem, dass die Festplatten nicht in den Sleep-Modus verfallen. Ich habe einen TS 409Pro Turbo mit zwei Seagate-Platten aus der Kompatibilitätsliste. Der Sleep-Modus hat vor einigen Monaten auch schon fehlerfrei funktioniert.


    Mindestens seit dem letzten Firmwareupdate (aktuelle Firmware 2.1.0 Build_080624) funktioniert es seit Juni nicht mehr. Ob es vor dem Firmwareupdate noch funktioniert hat, kann ich heute nicht mehr sagen.


    Ich habe auch schon alles mögliche ohne Erfolg deaktiviert. Was kann die Ursache sein?


    Upps....just in diesem Moment sind die Festplatten in den Sleep-Modus gegangen.


    Ursache: Ich habe die Uhrzeit automatisch über das Internet synchronisieren ganz deaktiviert.

    Zitat von "Eraser-EMC2-"


    Schon, eigentlich sollte im Ernstfall ein Neustart ausreichen.


    Klar! Nach einem Neustart ist /dev/ram0 leer.


    Ich habe es jetzt ganz anders gelöst.


    Die Konfiguration von CPAN aufgerufen (o conf init) und folgendes geändert:


    CPAN build und cache directory?


    von /root/.cpan auf /mnt/HDA_ROOT/cpan_dir geändert.


    Nun geht es. Zumindest ist der Fehler "No space on device" weg.


    Die Installation des UserAgent klappte auch. Wenn auch nur über die harte Methode:


    force install LPW::UserAgent


    Ich kämpfe noch mit einigen Problemen. Die können aber auch vom Script herrühren.

    Zitat von "Eraser-EMC2-"


    Da kann ich dir leider nicht weiterhelfen, da unter /dev/ram System-Dateien liegen.
    Dort eine falsche Datei löschen, kann tödlich sein.


    RAM (Random Access Memory) ist flüchtiger Speicher (doch noch was vom Studium behalten :D ). Da kann man nichts kaputtmachen, denke ich.


    Mit Symlink könnte ich das doch irgendwie auslagern. Wie lagere ich aber eine Partition aus oder welches Verzeichnis bzw. welche Datei?

    Ich habe den TS-409 komplett neu reinitialisiert. Am Ergebnis hat sich nichts geändert.


    Dies sind die letzten Fehlermeldungen des Systems:


    Code
    /bin/tar: Compress-Zlib-2.011/t/Test/More.pm: Cannot write: No space left on deviceCompress-Zlib-2.011/t/Test/Simple.pm/bin/tar: Compress-Zlib-2.011/t/Test/Simple.pm: Cannot write: No space left on deviceCompress-Zlib-2.011/t/Test/Builder.pm/bin/tar: Compress-Zlib-2.011/t/Test/Builder.pm: Cannot write: No space left on deviceCompress-Zlib-2.011/t/06gzsetp.t/bin/tar: Compress-Zlib-2.011/t/06gzsetp.t: Cannot write: No space left on deviceCompress-Zlib-2.011/t/08encoding.t/bin/tar: Compress-Zlib-2.011/t/08encoding.t: Cannot write: No space left on deviceCompress-Zlib-2.011/t/99pod.tCompress-Zlib-2.011/t/01version.t/bin/tar: Compress-Zlib-2.011/t/01version.t: Cannot write: No space left on deviceCompress-Zlib-2.011/t/14gzopen.t/bin/tar: Compress-Zlib-2.011/t/14gzopen.t: Cannot write: No space left on deviceCompress-Zlib-2.011/t/compress//bin/tar: Compress-Zlib-2.011/t/compress: Cannot mkdir: No space left on deviceCompress-Zlib-2.011/t/compress/CompTestUtils.pm/bin/tar: Compress-Zlib-2.011/t/compress/CompTestUtils.pm: Cannot open: No such file or directoryCompress-Zlib-2.011/t/05examples.t/bin/tar: Compress-Zlib-2.011/t/05examples.t: Cannot write: No space left on deviceCompress-Zlib-2.011/lib//bin/tar: Compress-Zlib-2.011/lib: Cannot mkdir: No space left on deviceCompress-Zlib-2.011/lib/Compress//bin/tar: Compress-Zlib-2.011/lib/Compress: Cannot mkdir: No such file or directoryCompress-Zlib-2.011/lib/Compress/Zlib.pm/bin/tar: Compress-Zlib-2.011/lib/Compress/Zlib.pm: Cannot open: No such file or directoryCompress-Zlib-2.011/Changes/bin/tar: Compress-Zlib-2.011/Changes: Cannot write: No space left on deviceCompress-Zlib-2.011/MANIFEST/bin/tar: Compress-Zlib-2.011/MANIFEST: Cannot write: No space left on deviceCompress-Zlib-2.011/private//bin/tar: Compress-Zlib-2.011/private: Cannot mkdir: No space left on deviceCompress-Zlib-2.011/private/MakeUtil.pm/bin/tar: Compress-Zlib-2.011/private/MakeUtil.pm: Cannot open: No such file or directoryCompress-Zlib-2.011/META.yml/bin/tar: Compress-Zlib-2.011/META.yml: Cannot write: No space left on deviceCompress-Zlib-2.011/pod//bin/tar: Compress-Zlib-2.011/pod: Cannot mkdir: No space left on deviceCompress-Zlib-2.011/pod/FAQ.pod/bin/tar: Compress-Zlib-2.011/pod/FAQ.pod: Cannot open: No such file or directoryCompress-Zlib-2.011/README/bin/tar: Compress-Zlib-2.011/README: Cannot write: No space left on deviceCompress-Zlib-2.011/Makefile.PL/bin/tar: Compress-Zlib-2.011/Makefile.PL: Cannot write: No space left on device/bin/tar: Error exit delayed from previous errorsgzip: stdout: No space left on deviceCouldn't uncompress /root/.cpan/sources/authors/id/P/PM/PMQS/Compress-Zlib-2.011.tar.gzcpan>


    Mir ist aufgefallen, dass /dev/ram0 zu 100 % voll ist. Da müsste doch die Ursache liegen?


    Zitat von "Eraser-EMC2-"

    Hast du ein O "ohhhh" oder eine 0 "Null" geschrieben ?


    Das O war schon ein "ohhhh"


    Über den anderen Weg klappt es auch nicht.


    Code
    # cd /mnt/HDA_ROOT/
    [/mnt/HDA_ROOT] # mv perl /share/MDO_DATA/perl
    mv: cannot create directory `/share/MDO_DATA/perl': No space left on device

    So sehen meine Partitionen aus:


    Code
    [~] # dfFilesystem                Size      Used Available Use% Mounted on/dev/ram0                 9.7M      9.7M      1.0k 100% /tmpfs                    16.0M     60.0k     15.9M   0% /tmp/dev/sda4                62.0M     44.1M     17.9M  71% /mnt/ext/dev/md9                509.5M    136.2M    373.2M  27% /mnt/HDA_ROOT/dev/md0                457.4G    117.7G    339.7G  26% /share/MD0_DATAtmpfs                    32.0M         0     32.0M   0% /.eaccelerator.tmp/dev/ram0                 9.7M      9.7M      1.0k 100% /mnt/HDA_ROOT/rootfs_2_3_6/bin/dev/ram0                 9.7M      9.7M      1.0k 100% /mnt/HDA_ROOT/rootfs_2_3_6/dev/dev/md9                509.5M    136.2M    373.2M  27% /mnt/HDA_ROOT/rootfs_2_3_6/etc/config/dev/md0                457.4G    117.7G    339.7G  26% /mnt/HDA_ROOT/rootfs_2_3_6/share/Qdownloadtmpfs                    16.0M     60.0k     15.9M   0% /mnt/HDA_ROOT/rootfs_2_3_6/tmp/dev/ram0                 9.7M      9.7M      1.0k 100% /share/MD0_DATA/optware/dev/dev/md0                457.4G    117.7G    339.7G  26% /share/MD0_DATA/optware/mnt/ext/Qmultimedia/dev/md0                457.4G    117.7G    339.7G  26% /share/MD0_DATA/optware/mnt/ext/Qdownload/dev/md0                457.4G    117.7G    339.7G  26% /share/MD0_DATA/optware/mnt/ext/Qweb/dev/md0                457.4G    117.7G    339.7G  26% /share/MD0_DATA/optware/mnt/ext/Qusb/dev/md0                457.4G    117.7G    339.7G  26% /share/MD0_DATA/optware/mnt/ext/Public


    Reicht das nicht aus?


    btw. Auf /share/HDA_DATA/ ist auch kein Platz mehr. Das kann doch nicht sein.


    Code
    [/mnt/HDA_ROOT] # mv /mnt/HDA_ROOT/perl /share/HDA_DATA/
    mv: cannot create directory `/share/HDA_DATA/perl': No space left on device

    Das Problem ist gelöst. Es lag an gzip.


    Dies hatte wohl nicht die benötigten Funktionen. Deshalb habe ich ipkg installiert und damit ein vollständiges gzip heruntergeladen und auf dem TS-409Pro installiert. Allerdings musste der Pfad in der Konfiguration von CPAN (o conf init) für gzip noch angepasst werden. Den Pfad habe ich von /bin/gzip auf /opt/bin/gzip geändert.


    Nun habe ich aber das die Meldung
    No space left on device at /mnt/HDA_ROOT/perl/lib/5.8.8/CPAN.pm
    bei der Installation von UserAgent.


    Zitat von "tyco"


    Nun habe ich das Script mit vi neu geschrieben und den crontab mit crontab -e editiert. Ein neues Einlesen des crontab war nicht erforderlich.


    Leider muss ich mich korrigieren. Der crontab blieb nur bis zu einem Neustart des QNAP erhalten. Danach waren meine Einträge verschwunden. Nun habe ich es so wie Eraser-EMC2- und christian gemacht:


    Code
    cd /etc/config


    Code
    vi crontab


    Dann habe ich crontab meinen Erfordernissen angepasst, abgespeichert und neu eingelesen.


    Code
    crontab /etc/config/crontab


    Nun bleibt crontab auch nach einem Neustart unverändert.

    Nach dieser Anleitung habe ich Perl 5.8.8 installiert.


    Mein Perlscript ruft täglich einmal Daten von Webseiten (http) ab und bildet aus diesen Daten wieder eigene Webseiten (Statistik). Unter Windows hat das bisher auch prima geklappt. Für meinen Qnap TS 409Pro musste ich die Files noch für Linux anpassen (dos2unix), das auch geklappt hat.


    Wenn ich jetzt meine Datei mit ./Fetch-Data.pl starte - später soll das der Cronjob erledigen - erhalte ich folgende Meldung:


    In Zeile 7 der Fetch-Data.pl steht: use LWP::UserAgent;


    Also fehlt mir das Modul LWP UserAgent. Ich habe es auch schon heruntergeladen und versucht zu installieren: libwww-perl-5.812.tar.gz


    Manuell klappt das irgendwie gar nicht. Das kann natürlich an mangelnder Kenntnis liegen...wo...was...wie...zu entpacken, zu kopieren oder zu installieren ist.


    Eigentlich sollte die Installation auch online möglich sein. Das klappt leider auch nicht. Habe es eben noch mit diesem Befehl versucht:

    Code
    perl -MCPAN -e "install Bundle::LWP"


    Die ellenlange Anwort auf diesen Befehl möchte ich euch nicht vorenthalten. Vielleicht sieht ja jemand die Ursache des Problems:


    Endlich kann ich auch Erfolg melden.


    Wie schon erwähnt lief das Script nicht, weil es mit dem Editor von Windows erstellt wurde. In vi war zu sehen, dass der Editor an das Ende jeder Zeile ein ^M hinzufügte. Ebenso an den Anfang und des Ende des Scriptes ein ^M.


    Nun habe ich das Script mit vi neu geschrieben und den crontab mit crontab -e editiert. Ein neues Einlesen des crontab war nicht erforderlich.


    Zu erwähnen ist noch, dass das Script vorher noch die erforderlichen Datei Lese-/Schreib- & Ausführ-Rechte bekommen muss. Dazu habe ich den Befehl chmod 750 hwe_backup.sh verwendet.


    Danke an alle!