Recovering a QNAP TS-412 after Firmware-upgrade fail

Was ist passiert?

Ein ganz normaler Sonntag. Ich musste kurz was auf dem Webinterface meiner QNAP TS-412 NAS einstellen und bekomme die Meldung eines neuen Firware-upgrades (4.0.1 auf 4.1.0, ja ich wei├č, nicht mehr ganz aktuell ­čśë ). Da ich bisher noch keinerlei Probleme hatte und doch schon h├Ąufig ein Upgrade durchgef├╝hrt hab, dachte ich mir „klar, das geht kurz“.

Wie sich herausstellte ein Fehler. Ich habe leider keine Ahnung was genau schief gelaufen ist, aber nach dem typischen Reboot hat nur noch die Status LED der NAS rot/gr├╝n abwechselnd geblinkt. Laut Internet ein Zeichen f├╝r eines der folgenden Probleme:

  1. The hard disk drive on the NAS is being formatted
  2. The NAS is being initialized
  3. The system firmware is being updated
  4. RAID rebuilding is in process
  5. Online RAID capacity expansion is in process
  6. Online RAID level migration is in process

Abgesehen von der Initialisierung – die allerdings keine 60 Minuten dauern sollte – und dem Firmware-upgrade – das eigentlich schon durchgelaufen sein sollte – keine sch├Ânen Vorstellungen…

Ich dachte mir na gut, kann ja sein das braucht einfach seine Zeit und dieses Mal dauert es halt l├Ąnger. Aber auch nach einer Essenspause keine Verbesserung. Also hab ich mich dem Problem angenommen und mich im Internet schlau gemacht.

Symptome

Falls jemand hier vorbei kommt und das selbe Problem hat, in kurz meine Probleme:

  • NAS bootet nicht mehr -> taucht nicht im QFinder auf, kein Webinterface, kein SSH, kein Zugriff auf die Shares
  • Status LED blinkt gr├╝n/rot abwechselnd
  • Ohne HDDs bootet dies NAS einwandfrei und auch der QFinder findet die NAS und will neu initialisieren

Versuche

Versuch 1: Firmware-recovery

Als erstes kam mir die Firmware-recovery in den Sinn. Nach einem abgebrochenen Firmware-upgrade kommt genau dieses Problem wohl ├Âfters vor. Allerdings sollte die NAS dann auch ohne HDDs nicht booten, was sie aber einwandfrei tut. In diversen Foreneintr├Ągen stand, dass es – auch wenn das System ohne HDDs noch bootet – trotzdem helfen kann. Da die Firmware aber offensichtlich auf den HDDs ist – da es ohne mit einer alten Firmware bootet – machte es f├╝r mich nicht viel Sinn die Firmware-recovery ohne HDDs durchzuf├╝hren. Aber dachte ich mir „Was solls, ein Versuch ist’s wert, wenn’s mal jemand geholfen hat, warum nicht auch mir?“. Also hab ich einmal die komplette Firmware-recovery durchgespielt.

Das Ergebnis: Ohne HDDs hab ich jetzt eine Firmware 4.0.1, mit den Platten komm ich allerdings immer noch nicht ├╝ber die gr├╝n/rote LED…

Versuch 2: Firmware-upgrade ohne HDDs

Kurz: Nicht empfohlen und es funktionierte auch nicht.

Ergebnis: „Upgrade Failed“, n├Ąchster Versuch.

Versuch 3: Config reset

Basierend auf einem Thread im QNAP Forum hat der Support bei einem ├Ąhnlichen Problem empfohlen die Configs per SSH und Hotplug zu l├Âschen und mit default configs zu ersetzen. Die Idee ist gut, hab mich schon aufgeregt, dass ich nicht selber auf die SSH Hotplug Idee kam. Also einfach mal ganze Programm durchgezogen.

Ergebnis: Kein Unterschied beim starten mit den HDDs.

L├Âsung

Wenn man so viel wie ich mit Linux Systemen arbeitet wird man irgendwann kreativ. Ich hatte mich schon fast mit einem Reset der NAS abgefunden, aber ein letzten Versuch wollte ich mir noch geben, da ich was von „manuellem Systemupgrade“ gelesen hatte.

Wer genau das beschrieben Problem hat, sollte folgendes versuchen, mir hat’s geholfen.

#1 NAS ans Netzwerk anschlie├čen (damit sie eine IP vom DHCP Server bekommt)

#2 Die NAS starten ohne HDDs (einfach ein zur H├Ąlfte raus-ziehen)

#3 Hotplug aller Platten in richtiger Reihenfolge (1-4) und warten bis alle HDD LEDs gr├╝n leuchten und nicht mehr blinken (also einfach alle Platten wieder rein-schieben, bis sie richtig drin stecken)

#4 IP per Qfinder oder Router/DHCP Server herausfinden

#5 SSH Verbindung per Putty (Windows) oder ssh (Linux) aufbauen

Die Logindaten sind:
User: admin
Passwort: admin

#6 Festplatten mounten mit folgenden Befehlen:

config_util 1 #Mirror ROOT partition
storage_boot_init 1 #mount ROOT partition
storage_boot_init 2 #mount DATA partition

Mit diesen Befehlen werden alle Festplatten wieder in das System eingebunden und sind anschlie├čend wieder verf├╝gbar.

Update:
Bei mir gab es keine Fehler bei diesen 3 Befehlen, falls doch sollte man folgendes versuchen:

config_util 4
mount /dev/sda4 /mnt/ext
cp /etc/default_config/uLinux.conf /mnt/HDA_ROOT/.config/
rm -r /etc/config
ln -sf /mnt/HDA_ROOT/.config /etc/config
setcfg -f /etc/config/uLinux.conf Misc configured TRUE

Siehe Comments

#7 Download der neusten Firmware von QNAP und anschlie├čend entpacken (.img Datei)

#8 Kopieren der Firmware (.img) auf eine der jetzt eingebundenen Festplatten (NICHT auf die root-Partition, die ist zu klein!) in der NAS per scp oder in Windows per WinSCP (da meine Firmware kein wget hatte). In meinem Falle hab ich das ganze auf eine RAID Partition geschoben: /share/MD0_DATA/

Update:

Falls das Kopieren fehlschl├Ągt, empfiehlt es sich die Firmware-Recovery einmal ohne die HDDs durchzuf├╝hren, um das „vorinstallierte“ OS auf eine aktuelle Version zu bringen (Firmware-recovery). F├╝r mehr Details, siehe Comments.

#9 Durchf├╝hren eines manuellen System-upgrades:

Zuerst muss man ├╝berpr├╝fen ob der Ordner /mnt/HDA_ROOT/update verf├╝gbar ist, falls nicht wird dieser zuerst erstellt:

mkdir /mnt/HDA_ROOT/update

Der zweite Check, den man durchf├╝hren muss bevor man das Upgrade starten kann ist die ├ťberpr├╝fung ob der Ordner /mnt/update im System vorhanden ist. Falls ja muss man diesen zuerst l├Âschen mit:

rm -rf /mnt/update

oder, falls nicht m├Âglich, unmounten:

umount /mnt/update

Nun kann man das manuelle Firmware-upgrade durchf├╝hren. Daf├╝r kopiert man zuerst die .img Datei in /share/public, bei mir war das:

cp /share/MD0_DATA/TS-412_20140612-4.1.0.img /share/Public/TS-412_20140612-4.1.0.img

Als n├Ąchstes erstellt man einen Symlink zum update Verzeichnis:

ln -sf /mnt/HDA_ROOT/update /mnt/update

Als letztes wird das Update Script ausgef├╝hrt:

/etc/init.d/update.sh /share/Public/TS-412_20140612-4.1.0.img

#10 Warten bis das Upgrade komplett durchgelaufen ist und folgende Zeile auftaucht:

Update Finished.

#11 Neustarten per:

reboot

Und siehe da, meine NAS kam endlich ├╝ber die gr├╝n/rote LED raus und hat das System wieder wie vorher gebootet. Man muss nur einfallsreich sein und viele Foreneintr├Ąge lesen ­čśë

Ich hoffe meine kleine Odyssee hilft Anderen schneller ans Ziel zu kommen, falls bei euch nach einem Firmware-upgrade das selbe Problem aufgetaucht ist.

114 thoughts on “Recovering a QNAP TS-412 after Firmware-upgrade fail

  1. Cyberuser says:

    Tausend Dank!!!

    Heute Morgen um 9 Uhr ein Termin gehabt und um 8:45 Uhr gehetzt einfach ohne nachzudenken Firmware Update ├╝ber Webinterface weggedr├╝ckt mit „ja“… Nat├╝rlich als Ergebnis: nicht vor Ort, TS-419P+ nicht mehr erreichbar und die gew├╝nschte Daten trotzdem nicht heruntergeladen.

    Um 17 Uhr vor Ort gewesen und QNAP konnte auch ohne Festplatten nicht mehr gestartet werden. Also ein Firmware Recovery durchgef├╝hrt laut http://wiki.qnap.com/wiki/Firmware_Recovery und ewige beleidigende Forenbeitr├Ąge. Trotzdem reagierte der QNAP nicht, allerdings ohne Festplatten nun doch erreichbar und bereit f├╝r ein Zugriff ├╝ber QFinder.

    Dieser Blogeintrag war meine Rettung! Simple, verst├Ąndlich, ohne ewige Forenbeitr├Ągen wie man einfach nur so unvern├╝nftig bl├Âd sein kann um ein Firmwareupdate durchzuf├╝hren kann ohne Backup zu machen oder typische Kommentaren die bei der Probleml├Âsung nicht weiter helfen und einen nur noch mehr ├Ąrgert.

    Zwar habe ich gerade so Ahnung von Linux das ich weiss was „ls“ tut und trotzdem habe ich es geschafft mein QNAP mit diesen Artikel wieder zum laufen zu kriegen.

    Tausend Dank nochmal.

  2. stephanowitsch says:

    Hallo waterstorm,

    vielen Dank f├╝r diesen hilfreichen Artikel!

    Leider hab ich mit meiner TS-231 und (aktuellsten) FW 4.20 ein Problem: ich f├╝hre deine Anleitung bis zu #5 aus aber die Befehle unter #6 werden mit einem „command not found“ quittiert. Was kann ich da tun?

    Ich wei├č nicht, warum das Ger├Ąt pl├Âtzlich nicht mehr im Netzwerk auffindbar ist; es ist kein FW-Update fehlgeschlagen. Jedoch habe ich die gleichen Symptome wie du sie beschrieben hast (rot/gr├╝nes Blinken, startet ohne Platten bis zur Aufforderung zum FW-Update, manuelles Update schl├Ągt fehl per Webinterface, jedoch Ger├Ąt bei Start mit Platten im QFinder nicht auffindbar).

    An den Festplatten sollte es nicht liegen, RAID 1 mit 2x 2TB WD Red.

    Hilfe bitte ­čÖü

  3. waterstorm says:

    Danke ­čÖé

    Du sagst im QFinder taucht die NAS nicht auf, dann hast du die IP fest vergeben oder per Router herausgefunden? Die SSH Verbindung ging aber einwandfrei?

    Tipp mal folgendes ein:
    df

    Das sollte alle gemounteten Platten auflisten. Schritt #6 ist daf├╝r da, dass alle Platten wieder verf├╝gbar sind. Was gibt der „df“ aus?

  4. Jenia says:

    Danke – danke – danke!!!
    Ohne diese super hilfreiche Anleitung h├Ątte ich ein richtig gro├čes Problem gehabt.

    Auf einem anderen Blatt steht aber, warum l├Ąsst QNAP ├╝berhaupt zu, dass es zu diesem Problem kommen kann?

  5. benoegen says:

    ├ťberragendes Tutorial, vielen Dank! Rettete hier ein TS-212 vorm verdroschen werden ­čśë

  6. Solrac says:

    hi, hab das Problem bei meinTS-412 das die Datei update.sh nicht findet und Sie ist auch nicht vorhanden.
    Danke im Voraus

  7. waterstorm says:

    Aber bis zu diesem Punkt konntest du alle Schritte die ich beschrieben hatte erfolgreich durchf├╝hren? K├Ânnte sein, dass sie das Script verschoben haben oder, dass etwas vorher nicht funktioniert hat.
    Kannst du per Qnap Finder sehen welche Version bei dir drauf ist?

  8. Solrac says:

    Hab die 4.0.2 drauf. Die Schritte vorher hat er mir keine Fehlermeldung angezeigt.

  9. waterstorm says:

    Etwas stressig die letzen Tage, sorry f├╝r die sp├Ąte Antwort ­čÖé
    Hab jetzt nochmals bei mir geschaut. Die Datei m├╝sste in /etc/init.d/ liegen. Was ist denn bei dir in dem Ordner so drin?
    Gib mal folgendes ein:

    ls -la /etc/init.d/u*

    Das zeigt dir alle Dateien die mit „u“ beginnen im Ordner an (der ist recht gro├č). Was gibt er dir zur├╝ck?

    Bei mir sieht das wie folgt aus:

    [~] # ls -la /etc/init.d/u*
    lrwxrwxrwx 1 admin administ 53 Jan 4 20:35 /etc/init.d/ubuntu-hd.sh -> /share/CE_CACHEDEV1_DATA/.qpkg/ubuntu-hd/ubuntu-hd.sh*
    -rwxr-xr-x 1 admin administ 12920 Dec 15 17:58 /etc/init.d/udev_run.sh*
    -rwxr-xr-x 1 admin administ 8035 Dec 15 17:58 /etc/init.d/unit_test.sh*
    -rwxr-xr-x 1 admin administ 18379 Dec 15 17:58 /etc/init.d/update.sh*
    -rwxr-xr-x 1 admin administ 1023 Dec 15 17:58 /etc/init.d/update_def_share.sh*
    -rwxr-xr-x 1 admin administ 34074 Dec 15 17:58 /etc/init.d/update_img.sh*
    -rwxr-xr-x 1 admin administ 8686 Dec 15 17:58 /etc/init.d/updatedb.sh*
    -rwxr-xr-x 1 admin administ 3859 Dec 15 17:58 /etc/init.d/upnpd.sh*
    -rwxr-xr-x 1 admin administ 1012 Dec 15 22:59 /etc/init.d/ups.sh*
    -rwxr-xr-x 1 admin administ 1108 Dec 15 17:58 /etc/init.d/urandom*
    -rwxr-xr-x 1 admin administ 11811 Dec 15 17:58 /etc/init.d/usb_device_check.sh*
    -rwxr-xr-x 1 admin administ 5968 Dec 15 22:59 /etc/init.d/usb_ups.sh*

  10. Solrac says:

    [~] # ls -la /etc/init.d/u*
    -rwxr-xr-x 1 admin administ 825 May 18 2012 /etc/init.d/update_def_share.sh*
    -rwxr-xr-x 1 admin administ 22041 Jul 25 2013 /etc/init.d/update_img.sh*
    -rwxr-xr-x 1 admin administ 8685 Jun 18 2013 /etc/init.d/updatedb.sh*
    -rwxr-xr-x 1 admin administ 2490 Feb 16 2012 /etc/init.d/upnpd.sh*
    -rwxr-xr-x 1 admin administ 945 Jul 26 2013 /etc/init.d/ups.sh*
    -rwxr-xr-x 1 admin administ 1108 Jan 14 2008 /etc/init.d/urandom*
    -rwxr-xr-x 1 admin administ 4550 Jun 28 2013 /etc/init.d/usb_device_check.sh*
    -rwxr-xr-x 1 admin administ 5607 Jul 26 2013 /etc/init.d/usb_ups.sh*

  11. waterstorm says:

    Puh, okay das ist sehr komisch.

    Hast du versucht eine Firmware Recovery zu machen? Das m├╝sste deine OS Version ohne HDDs upgraden:

    https://wiki.qnap.com/wiki/Firmware_Recovery

    Danach hast du vielleicht wieder das Update Script. Sonst kann ich auch versuchen dir meins zu kopieren, aber ich glaub das ist auf Grund der unterschiedlichen Version keine sonderlich gute Idee :/

  12. Solrac says:

    habe noch nicht gemacht, werde es mal versuchen.
    Danke dir trotzdem schon mal f├╝r die Hilfe

  13. Solrac says:

    Hi, hab jetzt das Problem das er im Ram nicht genug platz hat. Deswegen geht jetzt die Installation immer schief.

  14. waterstorm says:

    Puh ­čÖé Jetzt wirds „lustig“.

    Die Qnap wiki sagt:
    If updating from 4.0.x to 4.0.5, 4.0.6, 4.0.7, 4.1 or newer, do not copy or move the image to HDA_ROOT/update, let’s make a work copy on public. This is required avoid any „System update failed. No enough space on RAM/ disk available for firmware update.“ errors

    Liegt bei dir was in HDA_ROOT bzw. HDA_ROOT/update? Falls ja scheint das dein Problem zu erzeugen, versuch das mal wie hier im Artikel beschrieben (ggf. musst du das jetzt verschieben (mv statt cp) oder l├Âschen):
    https://wiki.qnap.com/wiki/Manually_Updating_Firmware

  15. Solrac says:

    habs versucht Manuel am Terminal zu installieren.

    MODEL NAME = TS-412,new version = 4.2.3
    limit version = 3.8.2
    Allow upgrade
    /bin/tar: /mnt/update: Cannot chdir: No such file or directory
    /bin/tar: Error is not recoverable: exiting now
    Failed.
    [~] # /etc/init.d/update.sh /share/Public/TS-412_20170121-4.2.3.img
    Failed. File format error.
    [~] # /etc/init.d/update.sh /share/Public/TS-412_20170121-4.2.3.img
    Failed. File format error.
    [~] # /etc/init.d/update.sh /share/Public/TS-412_20170121-4.2.3.img
    cksum=3903072136
    Check disk space available for FW update: OK.
    Using 120-bit encryption – (QNAPNASVERSION4)
    len=1048576
    model name = TS-412
    version = 4.2.3
    boot/
    config/
    fw_info
    initrd.boot
    initrd.boot.cksum
    libcrypto.so.1.0.0
    libssl.so.1.0.0
    qpkg.tar
    qpkg.tar.cksum
    rootfs2.img
    rootfs2.img.cksum
    rootfs_ext.tgz
    rootfs_ext.tgz.cksum
    uImage
    uImage.cksum
    update/
    update_img.sh

    MODEL NAME = TS-412,new version = 4.2.3
    limit version = 3.8.2
    Allow upgrade
    /bin/tar: /mnt/update: Cannot chdir: No such file or directory
    /bin/tar: Error is not recoverable: exiting now
    Failed.

  16. waterstorm says:

    Sieht so aus als w├Ąre der Ordner /mnt/update nicht gelinked worden. Hast du dashier vorher durchgef├╝hrt?

    ln -sf /mnt/HDA_ROOT/update /mnt/update

    Ggf. musst du auch wie oben beschrieben dies vorher machen:

    mkdir /mnt/HDA_ROOT/update

  17. Solrac says:

    Hab das auch gemacht, hab mich wohl irgendwo vertippt.
    Hab das nochmal gemacht und jetzt mach er denn update. und hat in auch beendet ohne Fehler.
    Jetzt nur noch reboot, dann weiss ich ob es geklappt hat.

  18. Tobi says:

    Hallo Waterstorm,

    Danke, Danke, Danke!!!
    Ich habe genau nach Deiner Anleitung mein Qnap TS-210 heute wieder ans rennen bekommen! Hat alles genauso geklappt, wie Du es beschrieben hast.

    Puhh… Ich hatte mich schon von all meinen Daten verabschiedet ( von denen ich nat├╝rlich keine Sicherheitskopie hatte. Daf├╝r habe ich ja das NAS mit Raid System, so mein Denken ;- )
    In Zukunft bin ich da lieber etwas vorsichtiger. Traue niemals Deinem NAS und die goldene Regel: „Never Change a running System“!

    Viele liebe Gr├╝├če,
    Tobi

  19. Stefan S says:

    Habe mit der Anleitung hier mein TP-419P+ nach einem misslungenen Firmware Update wieder herstellen k├Ânnen.

    Ich musste vorher die Firmware-recovery machen, da mein NAS anfangs ohne HDDs auch nicht mehr startete.

    Vielen Dank!

  20. Gerd says:

    Hallo Waterstorm,

    oje, ich galube ich habe Bockmist gebaut. F├╝r den Firmware Update auf 4.3.3 bei meinem TP-419P+ habe ich versehentlich die zip-Datei statt der img-Datei hochgeladen und den Firmware Update mit der zip-Datei gemacht. Dann hat der reboot ewig gedauert mit rot/gr├╝n LED im Wechsel.

    Jetzt habe ich versucht, nach deiner Empfehlung vorzugehen. Ich habe also den Power-Knopf 4sec gehalten, bis das System sich ausschaltet. Dann habe ich die 4 HDDs zur H├Ąlfte herausgenommen und neu eingeschaltet. Allerdings rebootet die TP419P+ auch ohne HDDs nicht: Status leuchtet abwechselnd rot/gr├╝n und LAN blinkt. QFINDER PRO zeigt nichts an.

    Was kann ich noch tun? Nat├╝rlich habe ich kein Backup….. ­čÖä­čś▒

    Ich muss das NAS wieder zum Laufen kriegen….

    Viele Gr├╝├če und vielen Dank, wenn du mir helfen kannst Gerd

  21. waterstorm says:

    Puh, das ist ja komisch. Ich h├Ątte erwartet, dass die Software entweder testet ob es ein g├╝ltiges Image ist oder die Zip Datei entpackt, falls es ein Zip ist und den Inhalt ├╝berpr├╝ft… (Wer wei├č, vielleicht ist auch genau das passiert).

    Dann wollen wir mal schauen.
    Hast du die Anleitung hier schon versucht?
    https://wiki.qnap.com/wiki/Firmware_Recovery
    Das ist genau f├╝r einen Fall wie deinen. Da wird das „Grund OS“ neu aufgesetzt, falls die NAS ├╝berhaupt nicht bootet.
    Du musst nur drauf achten, dass du die Platten vorher raus ziehst (steht auch in der Anleitung).

  22. Gerd says:

    Ich h├Ątte auch gedacht, dass die QNAP Software die Firmware pr├╝fen w├╝rde, aber wird dann wohl nicht gemacht. Wahrscheinlich k├Ânnte man Goethes Faust als Firmware hochladen…

    Mit der Firmware_Recovery fange ich an. Allerdings bin ich auf der Suche nach einem Windows Notebook mit CD Laufwerk, um das durchzuf├╝hren. Ich hoffe ich bekomme heute eins.

    Auf jeden Fall vielen Dank f├╝r die Tipps.

  23. Gerd says:

    Also, ich habe meine QNAP TS419-P+ wieder oben – ohne Datenverlust…wie sch├Ân. Ich habe die Firmware Recovery Prozedur durchlaufen mit demselben Ergebnis: Ohne HDDs lie├č sich QNAP hochfahren, aber nicht mit. Also dann nach waterstorms Prozedur. Ich hatte ein paar Schwierigkeiten, da ich nur einen iMac habe. Aber SSH funktionierte gut bis #6. SCP habe ich nicht hinbekommen – also wie ich die img-Datei auf das QNAP bekomme…. ­čÖü

    Ich habe dann einen Trick versucht, der beim zweiten Mal gleich geklappt hat: Firmware-Update ├╝ber QFINDER. Hat funktioniert… :-))) Alles ist wieder oben. DIe Schritte ab #7 waren dann nicht mehr notwendig.

    Vielleicht als alternativer Pfad f├╝r deine L├Âsung, waterstorm.

    Jedenfalls vielen Dank – ohne die Hinweise hier w├Ąre meine Daten auf dem QNAP verloren gewesen.

  24. vladoo says:

    Hallo. Tolle Anleitung.
    Ich bekomme jedoch die img Datei nicht ├╝ber scp auf die NAS geladen. Die beiden Laufwerke habe ich geladen und /share/MD0_DATA ist vorhanden. Jedoch scheint die QNAP kein SCP an Bord zu haben. Es kommt „command not found“. Ich kann auch ipkg openssh nicht laden.
    Hast du einen Tip, wie die img drauf lade kann oder scp auf die NAS bekommen?
    Gru├č vladoo

  25. waterstorm says:

    Ja, ich wollte damals die Firmware mit wget / curl runterladen, aber die NAS selbst halt leider eine Minimal-Ausstattung an Tools. Daher hab ich das von „der anderen Seite aus“ gemacht. Mit SCP kann man Daten von einem PC auf einen anderen (in dem Falle die NAS) kopieren. Falls du ein Linux hast kannst du auf deinem Computer den Befehl SCP aufrufen, falls du Windows hast empfehle ich ein Tool wie WinSCP (https://winscp.net).
    Das ist recht einfach zu nutzen und mit diesem kannst du die Firmware von deinem Computer auf die NAS ├╝bertragen ohne, dass die NAS tools wie wget oder curl braucht ;-).
    Solltest du noch Hilfe brauchen, lass es mich wissen.

  26. vladoo says:

    Hallo waterstorm. Danke f├╝r die R├╝ckmeldung, jedoch habe ich ja schon oben geschrieben, dass ich ├╝ber SCP (nutze dazu mein Macbook und das Terminal) die Datei nicht ├╝bertragen kann. Fehlermeldung „command not found“. Ich habe auch Windows WinSCP versucht. Geht auch nicht. Es scheint, dass die QNAP das SCP Protokoll nicht an Bord hat. Hab die Syntax des SCP Befehls mehrfach kontrolliert. Alles scheint ok. Was kann ich noch tun? Habe das TS-412 mit aktueller 4.3.3 laufen.

  27. waterstorm says:

    Sorry, habe ich wohl falsch verstanden.

    Ich habe auch nie per ipkg irgendwas installiert, das ist ziemlich seltsam.
    Ich habe kurz gegoogled und das Problem scheint ├Âfter aufzutauchen, die „Hilfen“ sind allerdings echt l├Ącherlich:
    https://forum.qnap.com/viewtopic.php?t=71679

    Antworten in der Art von „warum versuchst du das ├╝berhaupt“. Super Hilfreich…

    Nur kurz damit ich auf dem selben Stand bin wie du:
    Du hast die Platten rausgezogen und das Teil gebootet und genau in dem Moment findet es den SCP Command nicht?
    Du kannst aber per SSH problemlos auf die NAS verbinden?

    Einer im Forum hat von der PATH variable geredet, das k├Ânnte theoretisch ein Problem sein. Hast du die ├╝berpr├╝ft und ggf. per ls in den Ordner geschaut?

    Mein erster Tipp:
    Hast du versucht das „BaseOS“, welches auf der NAS ist wenn die Platten nicht eingesteckt sind, upzugraden? Das k├Ânnte helfen, dass in der „neuen“/reparierten Version scp mit an Board ist.
    Die Anleitung dazu gibts hier:
    https://wiki.qnap.com/wiki/Firmware_Recovery

    Ich hab das vor meiner Anleitung „unwissentlich“ gemacht, das hei├čt es k├Ânnte schon sein, dass ich das deswegen hatte und du jetzt nicht.

    Tipp 2:
    Wenn SSH geht SCP aber nicht, kannst du nat├╝rlich gute alte Shell tricks versuchen. Sowas wie:
    cat file | ssh user@nas „cat > remote“

    Falls das nicht hilft, lass mich wissen wie’s ausschaut ­čÖé

  28. vladoo says:

    Waterstorm, es ist spitze dass du so schnell hilfst. Danke.
    Ja genau. Ich ziehe Platten raus und boote. Dann krieg ich die IP ├╝ber die Fritzbox heraus und gehe per ssh auf die NAS mit admin admin. Soweit alles gut. Dann gehe deine Anleitung bis Schritt 6. Ich schaue im Share/MD0_DATA ob alles da. Habe sogar einen Ordner angelegt f├╝r das img. Im zweiten Terminal Fenster versuche ich dann von der lokalen maschine mit scp das img auf die nas in den angelegten Ordner zu schieben und dann kommt die Meldung.

    Nein das Recovery hab ich noch nicht gemacht. Habe jetzt die aktuelle 4.3.3 drauf. Soll ich dann ne Version darunter installieren? Oder neinst du mit BaseOS was anderes? Die Daten werden dabei nicht gel├Âscht oder?

    Gr├╝├če vladoo

  29. waterstorm says:

    Ah super, das hilft.
    Gerne doch, mir gings ja genau so. Ich h├Ątte mich auch gefreut, wenn’s mir jemand erkl├Ąrt h├Ątte.

    Okay, wenn SSH geht w├╝rde ich an deiner Stelle erstmal kurz den Trick mit dem SSH „kopieren“ testen, das scheint mir die schnellste L├Âsung.
    An der Stelle an der du sonst SCP machen w├╝rdest machst du folgendes:
    Du gehst an deinem Mac in den Ordner mit dem Image, statt SCP auszuf├╝hren machst du

    cat image.img | ssh admin@ipDerNas ÔÇ×cat > /share/MD0_DATA/image.imgÔÇť

    Damit sollte er die Datei auslesen, eine Verbindung per SSH aufbauen und dann ├╝ber die SSH Verbindung die Datei wieder einlesen.

    Falls das nicht klappt versuch das „Base Upgrade“. Damit ist folgendes gemeint:
    Soweit ich das verstanden und getestet habe, speichert die NAS das „richtige“ OS inklusive Updates irgendwo auf einer Partition auf den Festplatten. Wenn die Platten beim Booten aber nicht drin sind, kann er auch das OS nicht laden und weicht sozusagen auf ein Integriertes im Flash-Speicher aus. Das benutzt man auch zur Neuinstallation etc.
    Das war bei mir eine deutlich ├Ąltere Version als die, die ich auf der Platte hatte.
    Diese Version konnte ich update, OHNE die Platten ├╝berhaupt einzubauen. Das hei├čt du machst die Firmware Recovery ohne die Platten einzubauen (siehe vorheriger Link).
    Daher kann das auch zu keinem Datenverlust f├╝hren, weil die Platten gar nicht drin sind ­čśë (Garantien gibt’s aber nat├╝rlich wie immer bei solchen Geschichten keine)

  30. vladoo says:

    Ich habe meine Box jetzt wieder am Start!!!!
    Der ssh cat Befehl hat leider nicht funktioniert. Trotzdem danke f├╝r den Tip.
    Ich habe das Grund OS ohne eingeschobene Platten durchgef├╝hrt. Alles wie im Wiki beschrieben. Dann wieder ohne Platten gebootet und den Schritte bis 6 durchgef├╝hrt und Platten gemountet bis /share/MD0-DATA wieder da war. Dann mit WinSCP verbunden (wichtig ist mit SCP Protokoll verbinden) und die Datei tats├Ąchlich r├╝bergeschoben. Es war wohl wirklich so, dass ├Ąltere Grundversionen das SCP Protokoll nicht an Bord haben.
    Dann deine Schritte weiter bis zum Schluss und rebbot. Dann lange warten bis das rot/gr├╝n Blinken zum gr├╝n wurde. Es war das sch├Ânste gr├╝n das ich seit langem gesehen habe. Dann konnte ich wieder per Web zugreifen.

    Vielen vielen Dank dir warestorm. Super Anleitung und Hilfestellung bei meinem Problem.
    Einfach Top!!!

  31. waterstorm says:

    Sehr sch├Ân! Freut mich, dass es wieder funktioniert.
    Ich habe auf Grund deines Problems auch gleich den Post angepasst ;-).

    Seitdem ich die Upgrades per QFinder mache, hatte ich auch keinerlei Probleme mehr, kann ich bisher nur empfehlen!

  32. Georg says:

    Hallo waterstorm!

    Vorab GROSSE DANKE f├╝r deine ausf├╝hrliche Beschreibung f├╝r die NAS Rettung. Nur habe ich leider ein kleines Problem mit dem Ablauf!

    Ich habe alles so gemacht wie von dir beschrieben. Habe auch die aktuellste Firmware auf die NAS Box kopiert, nur beim Update bekomme ich folgende Fehlermeldungen:

    # /etc/init.d/update.sh /share/Public/image.img
    cksum=640029095
    Using 120-bit encryption – (QNAPNASVERSION4)
    sig: q????d?? icpnas
    /usr/bin/du: invalid option — b
    BusyBox v1.01 (2013.05.28-19:09+0000) multi-call binary

    Usage: du [-aHLdclsxhmk] [FILE]…

    Summarizes disk space used for each FILE and/or directory.
    Disk space is printed in units of 1024 bytes.

    Options:
    -a show sizes of files in addition to directories
    -H follow symbolic links that are FILE command line args
    -L follow all symbolic links encountered
    -d N limit output to directories (and files with -a) of depth < N
    -c output a grand total
    -l count sizes many times if hard linked
    -s display only a total for each argument
    -x skip directories on different filesystems
    -h print sizes in human readable format (e.g., 1K 243M 2G )
    -m print sizes in megabytes
    -k print sizes in kilobytes(default)

    expr: syntax error
    expr: syntax error

    MODEL NAME = TS-219P+,DDR3
    Limited Upgrade
    cat: /mnt/update/newver: No such file or directory
    cat: /mnt/update/newbn: No such file or directory
    [/share/Public] #

    Was l├Ąuft da schief? Kannst du mir ev. hier weiterhelfen? Das w├Ąre super! Ich bin leider kein Unix Guru…

    Danke vorab und lieben Gru├č

    Georg

  33. waterstorm says:

    Hi,

    hast du mir noch ein paar mehr Infos?
    Du hast alle Schritte vorher durchgef├╝hrt? Inklusive der ganzen „/mnt/update“ Geschichten und da kam kein Fehler bei irgendeinen Befehl?

    Auf den ersten Blick sieht es f├╝r mich so aus als w├Ąre die Image Datei kaputt/korrupt oder der Ordner (/mnt/update) nicht da / korrekt verlinkt.
    Also w├Ąre mein erster Versuch nochmals die Firmware neu von der Qnap Website zu laden (falls es die gibt auch per checksum md5/sha1 pr├╝fen) und dann die ganze Geschichte nochmals versuchen.

    Allerdings sagt er auch, dass „du -b“ kein g├╝ltiger Befehl sei, was in meinem lokalen du aber sehr wohl einer ist:
    -b, --bytes equivalent to '--apparent-size --block-size=1'

    Es k├Ânnte daher auch sein, dass du das selbe Problem hast wie vladoo hatte und du ggf. die NAS vorher einmal ohne Platten upgraden musst (siehe Comments vor diesem).

    Daher mein Tipp:
    #1 Lad das Image nochmals neu und versuchs ein 2. Mal
    #2 Geht das nicht versuch wie oben besprochen das Upgrade der NAS ohne Platten und danach nochmals mit

  34. Georg says:

    Hi,

    ja ich wei├č, die Angaben sind sp├Ąrlich…

    Also, ich habe alles so gemacht wie von dir beschrieben (inkl. Firmware Reset ohne HDDs) und danach habe ich auch versucht, die Firmware OHNE HDDs upzugraden. Ich habe Zugriff auf die QNAP (ssh und Qfinder), kann aber die Firmware im Qfinder nicht hochziehen, da ich nach Auswahl der image Datei den Fehler „Die ausgew├Ąhlte Firmware stimmt nicht“ erhalte. Ich verwende einen iMac (Mac OS X El Capitan). Die Firmware Datei habe ich bereits mehrmals von der QNAP Seite geladen, nur bekomme ich jedes Mal dieselben Fehler…

    Ein ├Ąhnliches Problem scheint hier (https://forum.qnap.com/viewtopic.php?t=69641) beschrieben zu sein. Der Kollege hatte einen Fehler mit der Disk Partition Table… Hilft dir das ev weiter?

    Was brauchst du noch?

    Danke!!!

    Georg

  35. Georg says:

    Erg├Ąnzung: Zugriff von einem iOS Device (mit der Qfinder App) funktioniert gar nicht, da bekomme ich jedes Mal einen Verbindungsfehler. Und Zugriff via Browser und GUI bringt nur den Download einer .cgi Datei!

  36. waterstorm says:

    Okay, die Leute im Forum tippen dort aber auch auf ein kaputtes Image file.
    Mit dem „dd“ command musst du EXTREM vorsichtig sein! Wenn du dich da vertippst oder deine Platten/Partitionszuweisung zuf├Ąllig anders ist, kann sein du l├Âschst aus versehen alle deine Daten!!!

    Lass uns noch was anderes ├╝berpr├╝fen. Du hast ja per SCP die image Datei auf die NAS kopiert richtig? Das hei├čt von deinem MAC aus.
    Das hast du wie ich beschrieben hatten in /share/MD0_DATA/ kopiert oder?

    Kannst du dich mal per SSH auf der NAS in diesen Ordner gehen und „du“ aufrufen?
    cd /share/MD0_DATA/
    du -h -d1 /share/MD0_DATA/

    K├Ânnte sein dass dort voll ist, das w├╝rde auch erkl├Ąren warum jedes Mal der Image Fehler kommt.

  37. Georg says:

    Hi,
    nein ist es anscheinend nicht…
    [/share/MD0_DATA] # du -h -d1 /share/MD0_DATA/
    1.4M /share/MD0_DATA/homes
    4.0k /share/MD0_DATA/.@__thumb
    700.0k /share/MD0_DATA/Usb
    4.0k /share/MD0_DATA/.@centerim
    66.6M /share/MD0_DATA/.system
    35.0G /share/MD0_DATA/Download
    4.0k /share/MD0_DATA/.@qmonitor
    8.0k /share/MD0_DATA/.team_folder
    4.0k /share/MD0_DATA/.@backup_qbox
    12.0k /share/MD0_DATA/.versioning
    523.8G /share/MD0_DATA/.timemachine
    780.0G /share/MD0_DATA/Multimedia
    16.0k /share/MD0_DATA/lost+found
    4.0k /share/MD0_DATA/.php_session
    700.0k /share/MD0_DATA/Network Recycle Bin
    4.0k /share/MD0_DATA/.@mysql
    4.0k /share/MD0_DATA/.tmp
    11.3M /share/MD0_DATA/.@twonkymedia.db
    712.0k /share/MD0_DATA/Web
    4.0k /share/MD0_DATA/.php_session_sys
    155.3M /share/MD0_DATA/.sys_update_backup
    556.0M /share/MD0_DATA/.qpkg
    2.6M /share/MD0_DATA/.@backup_config
    12.0k /share/MD0_DATA/.@qsync
    700.0k /share/MD0_DATA/Recordings
    112.1M /share/MD0_DATA/.@cnid
    8.0k /share/MD0_DATA/.ldapdb
    4.0k /share/MD0_DATA/.idmap
    685.4M /share/MD0_DATA/.antivirus
    8.0k /share/MD0_DATA/.qbox_log_queue
    2.5M /share/MD0_DATA/Backup
    44.0k /share/MD0_DATA/.spool
    764.0k /share/MD0_DATA/.locks
    28.5M /share/MD0_DATA/Public
    160.0k /share/MD0_DATA/.torrent
    29.7M /share/MD0_DATA/.qbox
    8.0k /share/MD0_DATA/.appDB
    2.4M /share/MD0_DATA/.samba
    16777215.3T /share/MD0_DATA

  38. waterstorm says:

    16777215.3T ?

    Kannst du mal ein
    df -h
    machen?

    Ich hab grade gesehen, dass QNAP die MD5 sum mit angibt beim Download. Hast du die auf der NAS gepr├╝ft?
    Also ZIP auf die NAS kopiert per SCP und dann analog zu meinem Test:

    jens@Yavin [09:37:33] [~/Downloads]
    -> % md5sum TS-219_20170703-4.3.3.0238.zip
    2838a0436edc04c6a65e70cda6a6d022 TS-219_20170703-4.3.3.0238.zip

    Die „korrekte“ Checksum steht immer beim Download dabei:
    https://www.qnap.com/en/download?model=TS-219P&category=firmware

  39. Georg says:

    Beim fieltransfer bekomme ich das:
    image2.img 100% 167MB 9.8MB/s 00:17
    scp: ./image2.img: No space left on device
    Hilft dir das? Ist da der scp ordnungsgem├Ą├č abgelaufen?

  40. waterstorm says:

    scp: ./image2.img: No space left on device

    Ah das best├Ątigt die Vermutung.
    Das kommt wenn es kein Platz mehr hat und das kopieren abbricht. Dann passiert genau das was du beschrieben hast.
    Er kopiert bis kein Platz mehr ist und h├Ârt auf. Dann hast du eine korrupte Datei die die beschriebenen Fehler bringt.
    Du musst per SCP in einen Ordner / Partition kopieren auf der mehr Platz ist!

  41. Georg says:

    Eigenartig die Checksum stimmt nicht ├╝berein!!!

    [/share/MD0_DATA] # df -h
    Filesystem Size Used Available Use% Mounted on
    /dev/ram0 32.9M 32.9M 1.0k 100% /
    tmpfs 32.0M 132.0k 31.9M 0% /tmp
    tmpfs 32.0M 0 32.0M 0% /.eaccelerator.tmp
    /dev/md9 509.5M 17.0M 492.5M 3% /mnt/HDA_ROOT
    /dev/md0 2.7T 1.3T 1.4T 49% /share/MD0_DATA
    /dev/sda4 371.0M 272.6M 98.4M 73% /mnt/ext

  42. waterstorm says:

    Kannst du mal den SCP Befehl posten den du nutzt?
    Auf MD0_DATA sollte es eigentlich genug Platz haben.


    /dev/md0 2.7T 1.3T 1.4T 49% /share/MD0_DATA

  43. Georg says:

    Ja aber wenn kein Platz mehr ist, warum kann ich das File mehr als einmal kopieren und immer wieder ist es gleich gro├č? M├╝sste nicht irgendwann einmal Schluss sein und er gar nichts mehr kopieren kann?

  44. waterstorm says:

    Jup, das sollte das Problem sein ­čśë
    Versuch mal dashier:


    scp img.zip admin@192.168.1.106:/share/MD0_DATA/img.zip
    cd /share/MD0_DATA/
    unzip img.zip
    cp /share/MD0_DATA/imagefilename.img /share/Public/imagefilename.img
    ln -sf /mnt/HDA_ROOT/update /mnt/update
    /etc/init.d/update.sh /share/Public/imagefilename.img

  45. Georg says:

    Habe das ZIP file via SCP (siehe oben) kopiert und das Update gestartet, neuer Fehler:
    <it.d/update.sh /share/Public/TS-219_20170703-4.3.3.0238.img
    cat: /mnt/update/newver: No such file or directory
    cat: /mnt/update/newbn: No such file or directory

    Was passt jetzt schon wieder nicht?

    PS: Es tut mir leid, wenn ich dich so ├Ąrgere/qu├Ąle…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht ver├Âffentlicht. Erforderliche Felder sind mit * markiert.

Time limit is exhausted. Please reload CAPTCHA.