QNAP TVS-1271U Top Row of Drives (drives 9-12) do not start on boot/reboot of the NAS appliance

System Requirements:

  • QNAP TVS-1271U
  • QTS 4.3

The Problem:

A brand new, out of the box 12 drive 2u NAS appliance, with the “firmware” up to date gets thrown into production. During its first maintenance cycle, the firmware is updated again and it is rebooted.

On completion of the reboot, the array is offline. Visual inspection of the appliance reveals that the top row of drives in the array, drives 9, 10, 11 and 12 are offline. They just are not powered. Drives 1-8 are online and all green.

Rebooting the array shows the diagnostic LED’s on all 12 drives flash red, but the 4 drives in question then go into a powered down state and the boot completes with an inconsistent volume layout.

  1. Hot swapping the drives did not make a difference
  2. Rebooting the array did not make a difference.
  3. Testing all of the top rows worth of drives externally showed no errors in any drives
  4. Performing a couple of hard power downs and cold booting did solve the problem and allowed the array to start normally.

The same thing happened during the next test and diagnostics window.

The Fix

Disgruntled customer note: I want to add at this point that trying to phone QNAP UK is an exercise in futility. I sat in their queue system for more than half an hour listening to the same loop of music without getting anywhere. By the time that I gave up, I’d managed to get the thing to start through cold boot cycles and done quick SMART tests on all of the drives. When it came to this occurring the second time, I used the online chat feature with their people in Taiwan, who were more responsive and most helpful, but would not entertain speaking on the phone come what may.

My bigger issue is that QNAP support seems to have little sympathy for the needs of a production IT department, where as you would have thought that QNAP would be the kings of working to such constraints.


Once I had got to second line, the fix in itself was quite simple in the end, but its implementation leaves something to be desired. The system needed a BIOS update.

You might assume that when you are updating your “firmware“, this sort of things is being accommodated for in those updates. Apparently not! It seems as this new device may have been sitting in a warehouse for some time so was out of date, but it was immediately firmware serviced as soon as it was first booted. You would have expected that this sort of well know about, intermittent issue was being dealt with through the update delivery mechanism.

As soon as the BIOS of the TVS-1271U was updated to version QW10IR12 and rebooted, the problem was fixed. Why QNAP have not put information on this on their website knowledge base I do not know. This would seem more than sensible. QNAP does itself more reputational damage by trying to hide the issue and hope that only a few people see it. The reality is that they are likely causing stress and grief to end users and unnecessary RMA’s to their suppliers.

After checking power rails, our initial response was that it was a dead backplane and we were assuming it would have to be an RMA. Fortunately, it wasn’t and fortunately I went to QNAP before I went back to the supplier, but you do not always, especially with companies increasingly insisting that you deal with suppliers for RMA processes. A little public disclosure about this known issue would have just saved a lot of headaches (and disclosure makes you look good QNAP!).

The execution of the BIOS update itself was unfortunately quite cumbersome, requiring the support tech to back-up and then re-programme all of the NIC MAC addresses built into the motherboard. Something that could have easily have been sorted in a shall script and then transparently bundled into the firmware delivery, saving QNAP Taiwan more than an hours’ worth of time on this and some 8 emails.

It did however fix the problem and the Taiwan support team were pretty accomodating about doing it at 7am UK time.

Here for the benefit of the rest of the world, is the process that the tech went through to flash the BIOS. I have substituted real MAC addresses with fake ones below.

Note: I strongly recommend that you do not try this yourself and that you contact QNAP via their web chat support if you have a need to perform this procedure. If you try it, it is entirely at your own risk.

login as: admin
admin@'s password:
[~] # md_checker Welcome to MD superblock checker (v1.4) - have a nice day~ Scanning system... HAL firmware detected!
Scanning Enclosure 0...
RAID metadata found!
UUID: 3e5d7c85:95d82d3e:42647860:c0aaec32
Level: raid6
Devices: 12
Name: md2
Chunk Size: 512K
md Version: 1.0
Creation Time: Apr 19 11:57:42 2017
Disk | Device | # | Status | Last Update Time | Events | Array State
1 /dev/sdc3 0 Active Jun 16 07:15:08 2017 156 AAAAAAAAAAAA
2 /dev/sdd3 1 Active Jun 16 07:15:08 2017 156 AAAAAAAAAAAA
3 /dev/sde3 2 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
4 /dev/sdf3 3 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
5 /dev/sdk3 4 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
6 /dev/sdl3 5 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
7 /dev/sdm3 6 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
8 /dev/sdn3 7 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
9 /dev/sdg3 8 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
10 /dev/sdh3 9 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
11 /dev/sdi3 10 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
12 /dev/sdj3 11 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
=============================================================================== [~] # cd /share/CACHEDEV2_DATA/Public/
[/share/CACHEDEV2_DATA/Public] # ls
@Recycle/ messages
[/share/CACHEDEV2_DATA/Public] # wget http://download.qnap.com/Storage/tsd/bios/TVS-1271U_QW10IR12.zip
--2017-06-16 07:16:51-- http://download.qnap.com/Storage/tsd/bios/TVS-1271U_QW10IR12.zip
Resolving download.qnap.com (download.qnap.com)..., 2a02:26f0:ec:38c::1b52, 2a02:26f0:ec:398::1b52
Connecting to download.qnap.com (download.qnap.com)||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5931607 (5.7M) [application/zip]
Saving to: ‘TVS-1271U_QW10IR12.zip’ TVS-1271U_QW10IR12.zip 100%[=====================================================================>] 5.66M 5.50MB/s in 1.0s 2017-06-16 07:16:52 (5.50 MB/s) - ‘TVS-1271U_QW10IR12.zip’ saved [5931607/5931607] [/share/CACHEDEV2_DATA/Public] # chmod +x TVS-1271U_QW10IR12.zip
[/share/CACHEDEV2_DATA/Public] # unzip TVS-1271U_QW10IR12.zip
Archive: TVS-1271U_QW10IR12.zip
creating: BIOS_QW10IR12/
inflating: BIOS_QW10IR12/flashrom
inflating: BIOS_QW10IR12/QW10IR12.bin
[/share/CACHEDEV2_DATA/Public] # ls
@Recycle/ BIOS_QW10IR12/ TVS-1271U_QW10IR12.zip* messages
[/share/CACHEDEV2_DATA/Public] # dmidecode -t bios | grep version
[/share/CACHEDEV2_DATA/Public] # cd
[~] # cd /
[/] # dmidecode -t bios | grep version
[/] # cd -
[~] # cd /share/CACHEDEV2_DATA/Public/
[/share/CACHEDEV2_DATA/Public] # head /etc/config/uLinux.conf
Model = TS-X71U
Internal Model = TS-X71
Server comment =
Version = 4.3.3
Build Number = 20170606
Number = 0224
Time Zone = Europe/London
Enable Daylight Saving Time = TRUE
Workgroup = QNAP
[/share/CACHEDEV2_DATA/Public] # cat /etc/model.conf | grep INTERNAL_NET_PORT_NUM
[/share/CACHEDEV2_DATA/Public] # hal_app --se_sys_get_mac obj_index=0
[/share/CACHEDEV2_DATA/Public] # hal_app --se_sys_get_mac obj_index=1
[/share/CACHEDEV2_DATA/Public] # hal_app --se_sys_get_mac obj_index=2
[/share/CACHEDEV2_DATA/Public] # hal_app --se_sys_get_mac obj_index=3
[/share/CACHEDEV2_DATA/Public] # cd
[~] # cd /share/Public
[/share/Public] # ls
@Recycle/ BIOS_QW10IR12/ TVS-1271U_QW10IR12.zip* messages
[/share/Public] # cd BIOS_QW10IR12/
[/share/Public/BIOS_QW10IR12] # ls
QW10IR12.bin flashrom
[/share/Public/BIOS_QW10IR12] # ls
QW10IR12.bin flashrom
[/share/Public/BIOS_QW10IR12] # chmod +x *
[/share/Public/BIOS_QW10IR12] # ls
QW10IR12.bin* flashrom*
[/share/Public/BIOS_QW10IR12] # ./flashrom -c MX25L128050 --programmer internal -w QW10IR12.bin
flashrom v0.9.8-unknown on Linux 4.2.8 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org Error: Unknown chip 'MX25L128050' specified.
Run flashrom -L to view the hardware supported in this flashrom version.
[/share/Public/BIOS_QW10IR12] # ./flashrom -c MX25L12805D --programmer internal -w QW10IR12.bin
flashrom v0.9.8-unknown on Linux 4.2.8 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK.
Found chipset "Intel C226".
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with it,
then please email a report to flashrom@flashrom.org including a verbose (-V) log.
Thank you!
Enabling flash write... Warning: SPI Configuration Lockdown activated.
Found Macronix flash chip "MX25L12805D" (16384 kB, SPI) mapped at physical address 0xff000000.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
[/share/Public/BIOS_QW10IR12] # hal_app --se_sys_set_mac obj_index=0,value=35:35:35:35:36:81
eth port = 0, Set MAC address = 35:35:35:35:36:31,ret = 0
[/share/Public/BIOS_QW10IR12] # hal_app --se_sys_set_mac obj_index=1,value=35:35:35:35:36:82
eth port = 1, Set MAC address = 35:35:35:35:36:32,ret = 0
[/share/Public/BIOS_QW10IR12] # hal_app --se_sys_set_mac obj_index=2,value=35:35:35:35:36:83
eth port = 2, Set MAC address = 35:35:35:35:36:33,ret = 0
[/share/Public/BIOS_QW10IR12] # hal_app --se_sys_set_mac obj_index=3,value=35:35:35:35:36:84
eth port = 3, Set MAC address = 35:35:35:35:36:34,ret = 0
[/share/Public/BIOS_QW10IR12] # reboot


Asus P4C800-E Deluxe and BIOS flashing higher than revision 1019

System Requirements:

  • Asus P4C800-E Deluxe


The Problem:

I admit it, I spooked myself doing this the first time and never came back to it.

It seems that a common problem with the P4C800 board range stems from people attempting to BIOS flash anything higher than the 2004 release 1019.004 ROM file.

If you do this you (may) as some have reported completely black screens or, as I did when I attempted to flash 1024.001 (beta), 1023, 1022 and 1021 – each time it spat out at the POST an error about experiencing an overclocking related error.

This is nonsense as my board has never been overclocked, there was no reason for this error. In the end I restored from the 1019 backup, which worked.


The Fix:

I wont forgive myself for saying this, but I think the problem is really down in the AFlash utility, I used the latest version of it at the time, and each time it dived – apart from 1019.

All this time later when I came back to look at it, having worked up the courage to look into it again, I thought I would go from a bootable 1019 and try the Asus Live Update utility. You cannot use versions lower than about 5.3, Asus say that much themselves in regards to these newer flash files. I found version 7.10.03 floating around on their FTP server and gave it a go.

I should state at this juncture that there have not been any significant hardware changes in the system configuration.

The auto update does not work: “Cannot find update files”, so it has to be done manually.

  1. Pull down 1023 or if you want the beta 1024.001, inflate whichever ROM you want.
    NB: If you use 1024.001 you must rename it .ROM instead of .001
  2. Use Live Update to update from file
  3. Reboot when asked
  4. Worked for me when the DOS utility persisted in telling me I was a bad overclocker
  5. Uninstall Asus Live and let us never speak of this again

If I had to make an observational, gut feeling statement of whether I think there is any point in risking the above, aside form my obsession with firmware build dates. I would have to say that my reaction is that the IDE seems to be that little bit more responsive than it was before.

In addition, the highest version of Asus Probe which works for this board is 2.25.02. ProbeII does not work.

Error: “Error during write buffer commit. Please check all cables and connections. Also verify that proper drive termination is used” while attempting to upgrade the firmware on Dell PowerVault 100T DDS4

System Requirements:

  • Dell PowerVault 100T DDS4

The Problem:

While attempting to upgrade the firmware on a PowerVault 100T DDS4 you receive the following error message from the Dell Windows updater.


The firmware updater exits from the session without upgrading the firmware.

More Information:

I have two Dell PowerVault 100T DDS drives, one in a PowerEdge 2600 and the other in the legend that is my PowerEdge 2400. Both systems run Windows Server 2003 and are pretty much vanilla Microsoft setups. The 2600 quite happily takes the firmware updates for the 100T DDS4, while the 2400 always drops out of the update procedure with the error message listed above.

Luckily the drive suffers no ill effects from encountering the error so far as I can see.


Obviously do pay attention to the error message. Check your termination and cabling if necessary. However there is a more simple solution. You’re flashing the wrong firmware.

There are two different versions of the 100T DDS4, and in their infinite wisdom (and for some reason) Dell didn’t think to add “v2” to the hardware name. What it boils down to is that there are two firmware kernels, the v8000 and the v9000. If you have an older drive then you have a v8000… and the Windows firmware updater is designed only for the v9000 drive.


How do I know which drive I have?

You can either scoot off and look in the PnP ID’s for the system, you could reboot the system and watch the POST… but that means downtime!

The lazy way to do it is to re-run the Windows updater package for the v9000. Before the flash begins you will be prompted with the following dialogue:

DDS4 Version Check

If the Installed Version string begins with an 8 (825B in this case) you have the older v8000 drive. If you have a v9000 drive at this juncture you really do need to check your termination and cabling.


Updating the firmware

Once you are secure in the knowledge that you have a v8000, the procedure is quite simply to download the hard drive install package and follow the instructions initiate the flash through the (provided) terminal application.

I have checked from A05 through to the latest A17 (at the time of writing) and while the highest FWID firmware revision seems to be labeled as 825B, the date time stamps on the images are being updated which makes me suspect that Dell simply aren’t updating the build number if they are indeed doing anything with it. In contrast the v9000 series is receiving incremental versions numbering. None the less, grab yourself the latest and greatest and get flashing!


Update 31st December 2007: There is now an A18, and while the version number is identical the date stamps have again changed.