Hallo zusammen,
ich habe ein ähnliches Problem und hatte gehofft es mit einer der diversen Anleitungen zu beheben.
Ich habe in einem Anfall geistiger Umnachtung per SSH mehrere Verzeichnisse auf einem TS-682 gelöscht. Ein "." kann unter UNIX soviel ändern...
Nun ist es passiert und ich wollte mein NAS wiederherstellen.
Ich habe die diversen Anleitungen aus diesem Thread sowie die offizielle Anleitung von QNAP befolgt. Leider immer mit dem gleichen Ergebnis. Das NAS bootet, piept zurerst einmal kurz, dann dauert es ca. 30 Sekunden (könnte auch länger sein...) und es piept 3 mal kurz.
Laut Anleitung hieße das, dass ich versuche Daten auf den an den Front angesteckten USB-Stick zu kopieren. Dort steckt aber auch kein USB-Stick. Komischerweise läuft der Lüfter auch sehr merkwürdig. Er dreht für 3-4 Sekunden komplett auf und geht dann wieder auf normale Drehzahl zurück. Dieses Verhalten macht er dauerthaft.
Das habe ich aber erstmal so hingenommen und mache mit dem Update per QFinder weiter.
Dieser findet das NAS auch und ich kann das Update der Firmware starten. Dies scheitert aber immer bei 20%. Ich kann zwar auf das Webinterface des Gerätes zugreifen, aber ich bekomme nur eine blaue Seite ohne jegliche Login-Möglichkeit angezeigt.
Daraufhin habe ich versucht das Firmware-Update lokal auf dem NAS durchzuführen. Das sagt mir aber nur, dass nicht genug Speicherplatz auf dem NAS zur Verfügung steht und es bricht mit dem Fehlercode FW006 ab.
Daraufhin habe ich mir mal die Ausgabe von "df -h" auf einem baugleichen TS-682 (mit exakt der gleichen Festplattenbestückung) angeschaut und dort sieht die Ausgabe ganz anders aus.
Hier die Ausgabe des korrupten Systems (ohne eingebaute Festplatten):
Disk /dev/sda: 515 MB, 515899392 bytes
8 heads, 32 sectors/track, 3936 cylinders
Units = cylinders of 256 * 512 = 131072 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 17 2160 83 Linux
/dev/sda2 * 18 1910 242304 83 Linux
/dev/sda3 1911 3803 242304 83 Linux
/dev/sda4 3804 3936 17024 5 Extended
/dev/sda5 3804 3868 8304 83 Linux
/dev/sda6 3869 3936 8688 83 Linux
Alles anzeigen
Hier die Ausgabe des laufenden Systems:
Filesystem Size Used Available Use% Mounted on
none 400.0M 299.6M 100.4M 75% /
devtmpfs 1.9G 8.0K 1.9G 0% /dev
tmpfs 64.0M 484.0K 63.5M 1% /tmp
tmpfs 1.9G 132.0K 1.9G 0% /dev/shm
tmpfs 16.0M 0 16.0M 0% /share
tmpfs 16.0M 0 16.0M 0% /mnt/snapshot/export
/dev/md9 493.5M 155.9M 337.6M 32% /mnt/HDA_ROOT
cgroup_root 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/mapper/cachedev1
16.2T 5.4T 10.9T 33% /share/CACHEDEV1_DATA
/dev/md13 417.0M 360.4M 56.6M 86% /mnt/ext
tmpfs 1.0M 0 1.0M 0% /mnt/rf/nd
Alles anzeigen
Dort fiel mir auf, dass "/dev/md9" in "/mnt/HDA_ROOT" gemountet ist. Nach der Anleitung für das lokale Update muss das auch so sein, damit entsprechend Platz für das Firmware-Image ist. "/dev/md9" habe ich auf meinem korrupten System aber garnicht.
Ich habe das Update auch mal mit eingesetzten Festplatten durchgeführt, da ich per "/proc/mdstat" gesehen hab, dass /dev/md9 aus den regulären Festplatten besteht. Leider hat das aber auch keine Änderung gebracht. /Dev/md9 wird nicht gemountet.
[Update]
Ich habe hier eine andere Anleitung gefunden, wie ich /dev/md9 per mdadm erstellen könnte. Die Anleitung ist eigentlich dafür gedacht, sollten die eingebauten Festplatten, die unter /share/CACHEDEV1_DATA eingebunden sind, komplett voll sein.
Hier ein kurzer Auszug:
Turn off your QNAP NAS
Pull out all HDD’s
Restart QNAP without the HDD’s
Use QFinder to detect the IP
Put back the HDD’s
Don’t follow the installation wizard (web)! Instead, connect via SSH (use putty?), login credentials will probably be admin/admin
Execute these commands (mount the raid):
mdadm -A /dev/md9 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm -A /dev/md0 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
cd /mnt
(Under /mnt)
mkdir HDA_ROOT
cd /share
(Under /share)
mkdir MD0_DATA
mount /dev/md9 /mnt/HDA_ROOT
mount /dev/md0 /share/MD0_DATA -t ext4
(or mount /dev/md0 /share/MD_DATA -t ext3)
Alles anzeigen
Meint ihr, ich könnte das ausprobieren, ohne meine Daten, die auf den Festplatten sind, zu verlieren? Grundsätzlich würde ich sagen, dass das kein Problem darstellen sollte, da die Daten ja nur eingebunden werden und die gleichen Partitionen auch auf meinem aktiven NAS für /dev/md9 genutzt werden. Fraglich ist nur, was mit meinen Daten bei dem Firmware-Update passiert.
[Update Ende]
Das zweite System ist bis auf einen Ordner eigentlich eine 1:1 Kopie des aktuellen Systems und diente mir als Backup für das erste QNAP. Dort fehlen mir nur die Daten von ca. 8 Stunden, da ich meinen Fehler genau vor dem nächsten Backup gemacht hab. (Die Daten möchte ich natürlich nicht verlieren). Könnte ich die Festplatten aus meinem korrupten System auch in das andere NAS einbauen und dort ganz normal auf die letzten Daten zugreifen? (Bis auf die Systemkonfiguration, die ich vermutlich noch zu tätigen hätte)
Ich hoffe, ihr könnt mir weiterhelfen und habt vielleicht ein paar Tipps für mich.