The other day (22/02/2012), Itryed to update my TS-459 Pro+ with the latest firmware 3.6.0 as the management web interface offered me so. I did (a month ago) the previous update (3.5.2) without any problem. But this time it failed during the update process. I didn't watch while it was doing it but I saw an error. I was busy so I though I would re-launch the update process later but I forgot and when I got back on the web interface a little bit later, it asked me to reboot the NAS for update and I -stupidly- clicked yes . Then, the NAS was not booting anymore.
The short solution that worked for me:
1) I followed the Firmware Recovery method to have the server booting again.
2) Then I followed the NAS Firmware Update When No HDD(s) Installed using QNAP Finder and the TS-459_3.4.3_Build0520.img firmware image (note: I had to use an older release)
3) Then I configured my NAS using an new single hard drive (my original hard drives were kept "offline" at that moment)
4) Then, I did a firmware update using the web interface and the TS-459_3.5.2_Build1126.img image (the last one that was working with my previous hard drives)
5) Finally I put back my original hard drives and everything was back to normal.
Well, I had a look to many many forum pages reporting the same kind of issue. I also tryed many solutions without success.
When my NAS was not booting, I didn't even have the "Booting 'dom Kernel 2.6.2X backup" shown here during step 1. I also had hard time to check if I had the correct primary master disk since I had to hit the "Pause" key at the right time in order to be able to read everything! (needed several reboots! :p )
I also noticed that, in my case, the drives were not the same ones of the procedure says:
/dev/sda is your flash drive.
/dev/sdb or /dev/hda is the DOM drive.
/dev/sdb was my my flash drive.
/dev/sda was my DOM drive.
But that changed back to what the procedure says after my first reboot after copying the dom.img file.
When I was trying several recipes, I also tried the solution here that removes partitions. That may have help but I'm not sure. What I did was, on the shell (of step 1), just before copying the dom.img file, I did (/dev/sdb was my dom drive that time):
Code: Select all
# fdisk /dev/sdb
Then reboot without copying the dom.img file and do the full step 1 procedure (again).
When I tried to update the firmware using QNAP Finder from windows, I noticed an error on the admin console of QNAP. I tryed with the 3.6.0, 3.5.2, 3.5.0 and finally the 3.4.3. Only the last one did work (I tried it because I think it was the original release on my QNAP when I bought it). The others failed. On QNAP Finder 3.... (note: the version before I update it to 3.5.0), the update firmware process (step 2) was able to upload the image file to the NAS. They all hanged at around, 20%, 21% or 22% depending on the image and show an error popup a few minutes later. With QNAP Finder 3.5.0, the error popup appeared right after the 2x%. As I had a screen on the NAS, I was able to see the error that occurred when reaching the 2x%: it was a "quick.cgi segfault" just like reported here with different numbers.
I also tried a manual firmware update from the shell but I was unable to perform it since I had no HDA_ROOT!
And finally, I also noticed an other error message but I don't remember in which context: a segfault with degrade_check. I can't remember if it was when I tried to update the firmware manually or with QNAP Finder when there was no hard drive or if it was when I tried to do it with a non-initialized hard drive (using my USB key as a fake HDA_ROOT drive).
To conclude, I think using an older firmware solved my problem either because it was smaller or did initialize some stuff newer firmwares do not. But it is also possible the removing the dom drive partitions before putting back the dom.img file may have changed something. I don't know what really happened but now, everything is back to normal and I didn't loose any data! ...I just lost a day and a half. 'hope this will help someone.