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.

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

  1. waterstorm says:

    Hast du dashier gemacht:

    mkdir /mnt/HDA_ROOT/update
    umount /mnt/update
    rm -rf /mnt/update
    ln -sf /mnt/HDA_ROOT/update /mnt/update

    Falls ja mach mal

    cd /mnt/update/
    ls -la

  2. waterstorm says:

    Im Forum schlÀgt jemand das hier vor (kurz vor dem eigentlich Update):

    echo NIL > /mnt/update/newver
    /etc/init.d/update.sh /mnt/HDA_ROOT/update/TS-xxxxxxxx.img

  3. Georg says:

    Nochmaliger Versuch: Update hat gestartet, ist aber nicht erfolgreich gewesen (zuwenig Platz? Directories nicht gefunden?):

    /share/MD0_DATA] # /etc/init.d/update.sh /share/Public/TS-219_20170703-4.3.3.0238.img
    cksum=2570482538
    Using 120-bit encryption – (QNAPNASVERSION4)
    len=1048576
    model name = TS-219
    version = 4.3.3
    /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
    new version = 4.3.3
    limit version = 3.3.4
    Allow upgrade
    boot/
    config/
    fw_info
    fw_info.conf
    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
    /mnt/HDA_ROOT/update
    error writing /etc/mtab.tmp: No space left on device
    tune2fs 1.41.4 (27-Jan-2009)
    Setting maximal mount count to -1
    Setting interval between checks to 0 seconds
    Update image using HDD …
    uImage cksum … Pass
    initrd.boot cksum … Pass
    rootfs2.img cksum … Pass
    rootfs_ext.tgz cksum … Pass
    qpkg.tar cksum … Pass
    Check uImage size … Pass
    Check initrd.boot size … Pass
    Check rootfs2.img size … Pass
    Check Flash ROM
    Update Kernel …
    Update Basic RootFS …
    Update Basic RootFS2 …
    1+0 records in
    1+0 records out
    error writing /etc/mtab.tmp: No space left on device
    Update Finished.
    Make a Backup
    /share/MD0_DATA
    rootfs_ext.tgz cksum … Pass
    qpkg.tar cksum … Pass
    BusyBox v1.01 (2013.05.28-19:09+0000) multi-call binary

    Usage: dirname FILENAME

    Strips non-directory suffix from FILENAME

    cat: /mnt/HDA_ROOT/update/newver: No such file or directory
    cat: /mnt/update/newver: No such file or directory
    cat: /mnt/update/newbn: No such file or directory
    set cksum [2570482538]
    [/share/MD0_DATA] #

    Sorry, ich weiß es ist mĂŒhsam…

  4. Georg says:

    [/mnt/update] # ls -la
    drwxr-xr-x 4 admin administ 4096 Jul 25 10:06 ./
    drwxr-xr-x 7 admin administ 4096 Jul 25 10:06 ../
    drwxr-xr-x 2 admin administ 4096 Jul 3 04:51 boot/
    drwxr-xr-x 2 admin administ 4096 Jul 3 04:51 config/
    -rw-r–r– 1 admin administ 33 Jul 3 04:51 fw_info
    -rw-r–r– 1 admin administ 87 Jul 3 04:51 fw_info.conf
    -rw-r–r– 1 admin administ107939840 Jul 3 04:51 qpkg.tar
    -rw-r–r– 1 admin administ 79 Jul 3 04:51 qpkg.tar.cksum
    -rw-r–r– 1 admin administ 54818257 Jul 3 04:51 rootfs_ext.tgz
    -rw-r–r– 1 admin administ 85 Jul 3 04:51 rootfs_ext.tgz.cksum
    lrwxrwxrwx 1 admin administ 20 Jul 25 10:02 update -> /mnt/HDA_ROOT/update/
    [/mnt/update] #

  5. waterstorm says:

    Hm, es kann gut sein, dass jetzt noch alter Krams da ist und er nicht mag weil die Partition voll ist.
    Ich wĂŒrde mal nochmals neustarten und alles „clean“ nochmals versuchen. Evtl musst du die alten Images manuell löschen, ich weiß nicht ob die nach einem Restart weg sind (sollten sie aber eigentlich).

  6. Georg says:

    Hi,

    nach einem Reboot ist die QNAP wieder hochgekommen. Daten sind da, nur leider sind die gesamten Configs weg (dh. muss neu konfiguriert werden, inkl. Apps). Gibt’s da eine Chance, auf die alten Daten zu zugreifen oder muss ich den steinigen Weg der Neukonfig gehen?

    Und NOCHMALS: GROSSES DANKE! Du hast mir sehr, sehr geholfen!

    Georg

  7. waterstorm says:

    Gerne 🙂 Freut mich, dass die Daten noch alle da sind, das ist ja mal das Wichtigste!

    Bei den Configs kenne ich mich nicht so gut aus, aber schau doch mal per SSH in folgenden Ordner:

    /mnt/HDA_ROOT/.config

    Da sollten eigentlich die Config-Files liegen. Vielleicht findest du ja dort auch die Alten. Ansonsten weiß ich da keinen Weg, das Problem hatte ich bisher nicht. Da musst du wohl noch etwas die Suchmaschine bemĂŒhen oder neu einrichten (geht vielleicht sogar schneller als ewig zu Suchen 😉 ).
    Aber immer noch besser als alle Daten weg, die kann man nicht „kurz neu Einrichten“ 🙂

Schreibe einen Kommentar

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

Time limit is exhausted. Please reload CAPTCHA.