Re-Init TS-219P+ after HDD change and FW update: HDDs not detected by QTS

I have a QNAP TS-219P+ updated to QTS 4.3.3.2784 and replaced the HDDs with two clean Samsung HD204UI 2 TB drives. Both drives are physically detected by the Linux kernel, but QTS does not recognize them as available disks and does not create the expected partitions.

Relevant diagnostics:

  • /proc/scsi/scsi shows both drives correctly:

    • SATA port 1 / SCSI host 0: Samsung HD204UI, Rev. 1AQ1

    • SATA port 2 / SCSI host 1: Samsung HD204UI, Rev. 1AQ1

  • Kernel block devices:

    • SATA1 → /dev/sdya, 3,907,029,168 sectors

    • SATA2 → /dev/sdza, 3,907,029,168 sectors

  • Both drives are currently completely unpartitioned.

  • /proc/partitions only contains the whole disks, no partitions.

  • QNAP configuration still expects the traditional device names:

    • Drive 1 = sda

    • Drive 2 = sdb

  • /etc/storage.conf still contains old entries for /dev/sda3 and /dev/sdb3, both with status -5.

  • /etc/raidtab is empty.

  • /etc/config/md_brief.conf is empty.

  • /sbin/disk_reorder --patch does not resolve the problem and reports:

    • The raid count in raidtab is 0

    • Disk 1 not found

    • Disk 2 not found

  • /sbin/storage_boot_init 2 reports:

    • Single-disk 1 doesn't exist!

    • Single-disk 2 doesn't exist!

  • The system has only /sys/block/sdya and /sys/block/sdza; both map correctly to SATA ports 1 and 2.

  • get_sg_info confirms the drives when called with /dev/sdya and /dev/sdza.

  • The SCSI generic devices exist in sysfs (sg650 and sg676), although the corresponding /dev nodes are not normally created.

The main question is:

What is the correct QNAP procedure or utility to initialize these two detected HDDs and create the standard QNAP partitions/mapping (sda/sdb) so that QTS recognizes them as available disks?

I would like to have the two HDDs as single volumes available for further use.

I do not want to manually partition the disks unless this is explicitly the recommended QNAP recovery procedure.

There should be no process, clean the drives of all partitions (e.g. diskpart in windows with ‘-clean’ option)

Make sure the NAS starts into setup OK by starting it without disks and see if the websetup is available (find via DHCP server or Qfinder)

Live swap the disks in and go through the setup

I’m a little puzzled by the Samsung HD204UI. They haven’t been manufactured for 15 years, so they can’t be new. Please check them on the PC.

===German translation added by Dolbyman ==

The HDDs are old, but they’ve probably spent most of their time in a cupboard. SMART is perfect, so I want to use them as a backup device for my (also old) TS-219P+.

==== German translation added by Dolbyman===

The HDDs are clean (diskpart clean), the problem is that the QTS web interface only reports “Disk drive missing” and offers no options. Qfinder also doesn’t offer a setup mode, but simply starts the web interface with the error message. Via SSH, I can see that the Linux base system is running properly, the HDDs are accessible, and I can create a filesystem on them, save files, etc. So everything seems fine from that perspective. It’s just that QTS refuses to reinitialize and mount the HDDs.

Please post in English or switch to the German section.

Please start he NAS diskless and report if the websetup comes up (as previously advised)

Sorry, I am quite new here. I posted in English, but it got translated - magic.
I started the empty NAS, but never get any chance to initialize. Qfinder opens just the web interface which comes up telling “no HDD available” and not offering any options. It does not change after inserting one or two HDDs.

By ssh I can see the linux base system is fine, so the querstion is how to force initialization from command line.

Then you should do a firmware recovery (your DOM might be partially shot)

https://www.qnap.com/go/how-to/faq/con_show.php?cid=1965

Hello,

/dev/sdya, /dev/sdza, is really weired, which means there are hundreds of sata drives before your two Samsung HDD being detected by the system. It could be somthing wrong on the system. And what dolbyman mentioned is worth to try.

Hello again,
Thank you for your hints!
I followed the firmware recovery procedure - and all follwing steps

  • automatic firmware update was not working
  • the firmware was manually updated with TS-219_20240619-4.3.3.2784.img
  • the system is re-configured
  • the (beforehand completely cleaned) hard disks are formatted

The power button remains flashing green, QTS comes up with:

while from ssh-linux side there are no error messages to find, the disks are there and are (manually) accessible.

Two partitioned (but not mounted) hard disks can be seen:

[~] # cat /proc/partitions
major minor  #blocks  name

31        0        512 mtdblock0
31        1       2048 mtdblock1
31        2       9216 mtdblock2
31        3       3072 mtdblock3
31        4        256 mtdblock4
31        5       1280 mtdblock5
128      672 1953514584 sdya
128      673     530125 sdya1
128      674     530142 sdya2
128      675 1951945693 sdya3
128      676     498012 sdya4
130      576 1953514584 sdza
130      577     530125 sdza1
130      578     530142 sdza2
130      579 1951945693 sdza3
130      580     498012 sdza4

Is there maybe a chance by installing older QTS versions? The last I had in use was 3.3, but I can’t find any such old firmware images for download.

Any further ideas how to motivate QTS to finalize setup and to start operation are very welcome …

I would open a ticket, the fact that the NAS can access the disks per SSH means that there should be no hardware defect.

If the disks are truly clean and free of any partitions I cannot see why the setup should not recognize the disks.

The Disks are not empty!!! You habe to format the HDDs.

My TS-219P+ is back and operational - with QTS 3.3.6.1109 - after many hours of try-and-error.

Story in short: All single firmware recovery procedures as discusssed above

  • clean HDDs
  • flash live-cd-20130730.iso as defined in https://www.qnap.com/go/how-to/faq/con_show.php?cid=1965
  • firmware update using one of the firmwares available at Download-Center | QNAP
    • TS-219_20240619-4.3.3.2784.img
    • TS-219_20221124-4.3.3.2211.img
    • TS-219_20220303-4.3.3.1945.img
  • resulted in the non-operational system state as documented above:
    • running linux with 2 operational HDDs seen as /dev/sdya and /dev/sdza
    • QTS error message “no HDDs” on web interfaceI

I found my historic original firmware image (on my new TS-216G) and did again

I tried to update this system using one of the firmwares available at Download-Center | QNAP

  • TS-219_20240619-4.3.3.2784.img - was refused
  • TS-219_20221124-4.3.3.2211.img - resulted in non-operationl state as above
  • TS-219_20220303-4.3.3.1945.img - resulted in non-operationl state as above

I found some user stories telling upgrade from 3.3.6 to 4.3.3 would need some intermediate steps, but I could not find any firmware images of the neede intermediate versions. All related old links to Qnap download locations result in “access denied”.

Does anyone have some intermediate versions to share? I would really like to update the old firware to some later release at least to support SMB2

Thank you for the FAQ link!

My problem is to find firmware image files for the intermediate steps from 3.3.6 to 4.3.3 , the direct upgrad fails. Qnap removed them from their download area, so I am looking for somone who could help.

Finally, I opened an official support ticket. I got two intermediate firmware images

  • U_TS-219P+_20110315-3.4.1.img
  • U_TS-219P+_20110719-3.4.4.img

which are perfectly running on my TS-219P+.

After version 3.4.4, the next firmware series is 4.3.3 starting with

  • TS-219_20220303-4.3.3.1945.img

Updated from 3.4.4 to this version, QTS does again not find the HDDs, see my problem description above.

The support could not answer, if any TS-219P+ was successfully updated (or re-installed) to any QTS 4.3.3 version. Their final message is:
Since the NAS model TS-219P+ is EOL (firmware is no longer maintained/updated so cannot escalate issue to developers) and RMA is no longer possible, you can continue to use while in the working firmware 3.4.4.
So I will do …