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:
- The hard disk drive on the NAS is being formatted
- The NAS is being initialized
- The system firmware is being updated
- RAID rebuilding is in process
- Online RAID capacity expansion is in process
- 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 partitionMit 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 TRUESiehe 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/updateDer 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/updateoder, falls nicht möglich, unmounten:
umount /mnt/updateNun 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.imgAls nächstes erstellt man einen Symlink zum update Verzeichnis:
ln -sf /mnt/HDA_ROOT/update /mnt/updateAls 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:
rebootUnd 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.
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
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
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…
[/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] #
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).
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
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“ 🙂
login as: admin
admin@192.168.178.48’s password:
[~] # config_util 1 #Mirror ROOT partition
Start to mirror ROOT part…
config_util: HD1 config Match serial_no of HD1.
config_util: HD2 config Match serial_no of HD2.
config_util: HD3 config Match serial_no of HD3.
config_util: HD4 config Match serial_no of HD4.
mdadm: /dev/md9 has been started with 4 drives.
Mirror of ROOT succeeded.
[~] # storage_boot_init 1 #mount ROOT partition
storage_boot_init 1 …
[~] # mdadm: /dev/sda2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Fri Nov 24 20:47:17 2017
mdadm: array /dev/md4 started.
storage_boot_init 2 #mount DATA partition
storage_boot_init 2 …
mdadm: /dev/md3 not identified in config file.
mdadm: stopped /dev/md3
mdadm: /dev/md3 has been started with 4 drives.
storage_boot_init.c: Start raid device /dev/md3 successfully
md3 : active raid10 sda3[0] sdd3[3] sdb3[2] sdc3[4]
md3 : active raid10 sda3[0] sdd3[3] sdb3[2] sdc3[4]
md3 : active raid10 sda3[0] sdd3[3] sdb3[2] sdc3[4]
md3 : active raid10 sda3[0] sdd3[3] sdb3[2] sdc3[4]
storage_boot_init.c: /dev/md3 is active.
storage_boot_init.c: Check filesystem on /dev/md3.
md5sum: /etc/config/proftpd.conf: No such file or directory
Restore default shares on vol[1]
storage_boot_init.c: check_last_degrade_error…
[~] # config_util 4
Start to mirror RFS_EXT part…
config_util: HD1 is TS-NASARM.
config_util: HD2 is TS-NASARM.
config_util: HD3 is TS-NASARM.
config_util: HD4 is TS-NASARM.
mdadm: /dev/sda4 has been started with 4 drives.
config_util: (0) /dev/sda4 size = 458880
Mirror of RFS_EXT succeeded.
[~] # 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
[~] # rm -rf /mnt/update
[~] # ln -sf /mnt/HDA_ROOT/update /mnt/update
[~] # /etc/init.d/update.sh /share/Public/TS-410_20171026-4.2.6.img
cksum=988757932
Using 120-bit encryption – (QNAPNASVERSION4)
len=1048576
model name = TS-410
version = 4.2.6
/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
OLD MODEL NAME = TS-410
Allow upgrade
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
/mnt/HDA_ROOT/update
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
Update Finished.
Make a Backup
/share/MD3_DATA
rootfs_ext.tgz cksum … Pass
qpkg.tar cksum … Pass
/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 ../tmp/
-rw-r–r– 1 admin admins 5 Jan 11 2008 .bash_history
-rw-r–r– 1 admin admins 175 Oct 9 2004 .bash_logout
-rw-r–r– 1 admin admins 161 Oct 9 2004 .bash_profile
-rw-r–r– 1 admin admins 1687 Jul 18 2007 .bashrc
-rw-r–r– 1 admin admins 27 Jan 29 2007 .profile
drwx—— 2 admin admins 1024 Jun 24 2008 .ssh/
lrwxrwxrwx 1 admin admins 12 Nov 24 22:35 halt -> /bin/busybox*
-rw-r–r– 1 admin admins 6526 Jul 11 2007 index_default.html
lrwxrwxrwx 1 admin admins 12 Nov 24 22:35 poweroff -> /bin/busybox*
lrwxrwxrwx 1 admin admins 12 Nov 24 22:35 reboot -> /bin/busybox*
[~] # reboot
[~] #
Nach dem Reboot funktioniert es leider immer noch nicht – kenn‘ mich leider mit Linux nicht aus. Hast Du noch einen Tipp für mich? Probiere bereits seit Stunden…..
So, nach einem weiteren Versuch, kam das TS-410 nach Deiner beschriebenen Lösung wieder „hoch“ – die Fehlermeldung blieb zwar am Ende die gleiche, aber nach einem „langen Boot“ schien dann endlich wieder alles gut! Danke dafür!
Freut mich, dass es noch funktioniert hat 🙂
Soweit hat es funktioniert, doch komme ich an meine alten Daten nicht heran. Ich sehe, dass Datenpakete auf den Festplatten sind, kann sie aber nicht ansprechen oder abrufen.
Hast du die Verschlüsselung vielleicht aktiviert?
Falls nicht, solltest du auf jeden Fall per SSH oder z.B. WinSCP durch deine Daten durchgehen können und diese ggf. auch herunterladen.
Hallo zusammen,
ich komme leider überhaupt nicht weiter. Ich habe eine TS-410 von einen bekannten geschenkt bekommen dieser meinte sie ginge nicht mehr. Ich habe keine HDDs dazu bekommen, lediglich die Blanke NAS. Komischerweise hat die TS-410 genau das selbe Problem.
Meine vorgehensweise :
1# NAS Hochfahren lassen. Sie mach sowohl den Kurzen Beep als auch nach ein paar Minuten den Langen Beep. Die Status LED Leuchtet und Anschließend Blinkt sie Grün.
2# Qfinder fand die NAS und wollte diese gleich initialisieren. Version war 4.0.1 dies habe ich dann auch gemacht, mein ganzes Zeug eingegeben Firmware ausgewählt ect.
3# Als letzter Schritt ist diese dann Neugestartet. Im Webinterface stand ein Timer mit 300sek und das die NAS neugestartet wird. Dies hat Sie dann auch , allerdings ist es bei den kurzen Beep geblieben. Die Status LED Blinkt im 1 Sek Takt Rot/Grün.
Ich habe versucht die Anleitung zu folgen. Leider kenne ich mich mit Linux gar nicht aus. Ich habe sowohl mit Putty als auch mit WinSCP eine verbindung hinbekommen. Das Problem was ich nun habe ist die IMG Datei auf die Platte zu bekommen. Ich bekomme immer eine Fehlermeldung im WinSCP :
SCP konnte für den Start der Übertragung nicht ausgeführt werden. Bitte stellen Sie sicher, dass SCP auf dem Server installiert ist und die $PFAD- Variable den Pfad zu SCP enthält. Anstatt SCP können Sie auch SFTP probieren.
Befehl gescheitert mit Beendigungscode 127.
Jemand ne idee ? Oder ist ist das ganze bei der TS-410 ein anderes Problem ?
Sollte keiner ne idee haben, werde ich das teil bei der nächsten Fahrt mit auf den Schrottplatz nehmen und in die Große Tonne hauen.
Danke schonmal
Sorry erstmal für die lange Responsetime, war etwas im Stress letztens.
Hm, wenn du die NAS ohne Platten bekommen hast, dann hast du immerhin nicht das Problem des Datenverlusts und damit kannst du etwas besser „experimentieren“ ohne Angst haben zu müssen.
Zudem kannst du erst mal ausschließen, dass die Platten deine Probleme verursachen (so wie bei mir und den meisten anderen hier).
Das heißt ich würde erstmal die „Firmware Recovery“ Versuchen:
-> Platten raus und einmal das Recovery durchspielen.
http://wiki.qnap.com/wiki/Firmware_Recovery
Danach schiebst du die Platten rein und versuchst zu booten. Hast du dann immer noch das selbe?
Falls du noch nichts wichtiges auf den Platten hast, kannst du auch einfach nochmal versuchen alles Platt zu machen und nochmal die Initialisierung durchspielen (NACH dem Upgrade 😉 dann hast du schon eine Neuere Version drauf)
Auch über 5 Jahre nach deinem Post hat es jemanden viel Zeit erspart, sein QNAP wieder flott zu bekommen.
Vielen Dank!
Hallo zusammen,
ich bräuchte auch Hilfe, hab das selbe Problem.
Aber ich komme mit Putty schon gar nicht drauf, obwohl das NAS gestartet ist. Anpingen kann ich das NAS. Muss man bei Putty noch auf irgendwelche Einstellungen achten?
Gruß
Hm eigentlich nicht. Es sollte reichen die richtige IP in Putty einzutragen.
Der Port muss zwar stimmen (22) aber das ist eigentlich voreingestellt in Putty. Daher müsste die IP wie gesagt ausreichen und wenn ein ping auch geht ist das schon merkwürdig. Vielleicht wurde SSH auf der NAS deaktiviert oder der Port verändert? Allerdings ist es schwer das zu überprüfen, wenn das Interface der NAS nicht erreichbar ist.