The thing is your not asking to RMA the device. you’re asking for the image to be fixed. raise a ticket and point them to your forums posts.
Thanks for your message, @Toxic ! I have now opened a ticket as you suggested and linked to the forum post. I also made clear in the ticket I didn’t want to send the device back.
Did the staff agree to have Tech Support confirm the findings?
Thanks again for your help!
not heard a thing as yet. we are getting close Chinese and Lunar new Years so QNAP may be silent soon.
Hello,
I have an almost identical issue and I think it’s best to continue using this thread. It’s often claimed that the recovery image is corrupt. I don’t believe that’s the case, and QNAP themselves apparently can’t reproduce the issue either. I’ve spent several days working on the problem and trying different things. In my case, it’s a TS-559 Pro+. I re-flashed the DOM with the appropriate recovery image and still received error messages about missing libraries.
I tried to bypass the DOM by removing it and writing the image to a USB stick instead — same problem. Both the DOM and the USB stick were tested multiple times for faults, but no issues were found. Additionally I also tested the RAM, just to be safe. Fortunately, I still have a working TS-559 Pro+. I cloned its DOM and used it in the faulty device, so at the very latest from that point onward everything should have worked again — but I still received the same error about missing libraries.
So it’s definitely NOT the image, no matter which one I use. In my desperate attempt to figure this out, I extracted and compared the initrd from both the recovery image and the working NAS. In the /etc/default_config directory, there is a file called uLinux.conf. It explicitly defines the “System Device” as /dev/sdx.
And this is the part that’s driving me crazy: no matter if it’s the DOM or the USB stick, and no matter which USB port I use — it is NEVER recognized as /dev/sdx. Sometimes it shows up as /dev/sdt, sometimes /dev/sdv, but never the expected /dev/sdx. I suspect this is the root cause of the issue.
How can I make the only connected storage device — the HDDs are of course disconnected as the recovery instructions recommend — be recognized as /dev/sdx? I’ve already loaded BIOS defaults, pressed the NAS reset button every way imaginable — with power, without power, short press, long press. Nothing helps.
Maybe this information will help to narrow down the issue. Right now I have a dead NAS and am seriously considering just installing TrueNAS or something similar. Any help is much appreciated.
Have you tried replacing the DOM? (in case only DOM modules receive that designation) The old QNAP forum also had a large topic on how to use a USB stick as alternative DOM
For this ancient NAS, I don’t think an alternative OS will be a solution, it would just be too slow.
Thanks for the quick reply. No, I haven’t replaced the DOM. However, it can be written to, zeroed, and read without any issues. I even once loaded the Damn Small Linux image onto it — as recommended in the recovery guide — and it booted without any problems.
But when I use the recovery image or the image cloned from the working device, the DOM — or a USB stick, for that matter — is not recognized as /dev/sdx, but instead as /dev/sdt or something else.
Just for fun, I tried booting the recovery image in a virtual machine. Even there, the storage device is recognized as /dev/sdf, not /dev/sdx.
I guess you have seen this topic…but maybe you find something helpful in there
Hi @Mort1 , in case you are wondering, I never solved the problem. There was a lot of back and forth with support, but they didn’t have one of these TS-1253U-RP units and they had to ask the escalation team, who claimed they couldn’t reproduce it and that the image is good.
As you mentioned you are receiving error messages about missing libraries, you could check if you have a /usr folder.
In my case, I don’t have a /usr folder (even if I rule out the DOM and directly image their firmware recovery image to a USB stick), which explains why there are messages about missing libuLinux_Util.so.0!
Unfortunately, despite not even having a /usr folder, regardless of whether the image is imaged to the DOM or to a USB stick, after many months (starting from Jan 22 and the last message was a few days ago on May 30) I am still unable to convince the escalation team that the recovery image https://download.qnap.com/Storage/tsd/fullimage/F_TS-X53U_20141125-1.2.8.img is bad, which is very frustrating!
(The image for your unit is different than the image for my unit, so it could be a different issue entirely for you. You mentioned you were considering installing TrueNAS. I was able to successfully install TrueNAS, as well as other non-compatible Qnap firmwares, on my TS-1253U-RP, indicating the DOM of my unit is working properly.)
Hello to everyone with the same or a similar problem,
Over the past few weeks, whenever I had time, I’ve been working on the issue, because I simply refuse to accept that a system can be manually loaded with all sorts of operating systems via USB stick, yet the original firmware doesn’t work. The good news is that I managed to successfully boot the recovery firmware so that the NAS can be detected by QNAP Finder. The bad news is that after a firmware upgrade, everything is just like before, the system doesn’t boot properly. In the following, I’d like to share my findings and the workaround with you, and I hope someone here has an idea on how to ultimately fix the root cause of the issue.
What I’ve learned from my investigations and experiments:
- The QNAP recovery firmware is not corrupt. It works exactly as it’s supposed to (whether that’s good or bad is up to you to decide).
- During boot, the file
/boot/rootfs2.bzis supposed to be unpacked and imported into the RAM-based filesystem. This file contains, among other things, the library files needed to start services like Telnet, SSH, the web server, etc., which otherwise fail to launch. - The system looks for the file
/boot/rootfs2.bzon device/dev/sdx2. /dev/sdxis not present./dev/sdxis only present when a DOM or a USB stick is connected to the 9-pin header of the DOM on the mainboard. No other port is ever recognized as/dev/sdx.
Thanks to @Dolbyman for the link, I actually hadn’t seen that yet. Since I was seriously starting to doubt myself and felt like I was going crazy, I became obsessed with figuring this out instead of just writing off the NAS as defective. I got a 9-pin USB connector and plugged in a USB stick with the recovery firmware to the DOM port. This is then recognized after boot as /dev/sdx. So it’s definitely the case that only this port can create a /dev/sdx.
But if /dev/sdx is present, why isn’t the file /boot/rootfs2.bz being unpacked as it should?
The answer is as simple as it is problematic: the device is detected too late. The system searches for /dev/sdx2 before /dev/sdx is recognized. As a result, the libraries cannot be loaded.
Once I understood this delay, I modified the initial ramdisk (initrd) of the recovery firmware. In the file /etc/init.d/init_check.sh, QNAP inserts a 10-second pause after loading various kernel modules (including USB). As far as I could tell, it really just waits for 10 seconds without doing anything. Then the familiar but non-functioning process is started.
I simply inserted a loop before the point where /boot/rootfs2.bz is unpacked. This loop tries once every second, for 15 seconds, to mount /dev/sdx2.
When I boot with this change, everything works flawlessly because the kernel has enough time to recognize the device.
However, the problem remains after a firmware update. Once the recovery firmware successfully boots thanks to the modification, the regular firmware needs to be reloaded. This process overwrites the kernel and the initrd, meaning that although the firmware is up to date, the system again fails to boot.
Between the recovery firmware and the latest version, some things have changed, so my simple workaround doesn’t apply 1:1. Now I need to insert my wait loop into the file /etc/init.d/mountall, within the function extract_rootfs2(). I’ll include the code for the wait loop at the end of this post. After making that change, the NAS also boots successfully with the latest firmware and works as it should, but no further updates must be installed, otherwise the device will stop booting again.
So, what now?
By modifying the initrd, the system can be repaired, but the root cause still exists, and I have no idea what it could be. The device /dev/sdx is detected later than on a normally functioning NAS. In my case, the problem occurred after a power outage, so the NAS probably suffered some kind of damage but one that doesn’t affect general functionality. Based on my experiments, the DOM itself can definitely be ruled out as the cause.
Does anyone have an idea of what else might be going on or what else I could test?
It’s great and satisfying that there’s a workaround and that I’m not completely crazy, but I would love to truly fix the underlying issue. It can’t be anything too special, since the overall functionality is fully intact and there are no errors when detecting USB devices, they’re just recognized too slowly.
I hope this sheds some light on the issue and helps rule out a few potential causes. I apologize for the long post, but I wanted to share my findings as clearly and thoroughly as possible. Maybe, together, we can breathe new life into these old NAS devices.
It would be a shame to throw away a device that’s actually still fine and only doesn’t work because of a missing wait loop in the firmware.
Here’s the wait loop I added, with output so you can see whether the device was mounted or not:
# Code to insert into /etc/init.d/init_check.sh (right before /sbin/gen_hostname)
# OR in recent Firmware /etc/init.d/mountall (right after opening bracket of extract_rootfs2())
# modified to wait for /dev/sdx device to appear
WAITED=0
MOUNTED=0
/bin/mkdir /testSDX
/bin/echo "Testing for device /dev/sdx to appear..."
while [ $WAITED -lt 15 ]; do
if /bin/mount -o ro /dev/sdx2 /testSDX 2>/dev/null; then
/bin/echo "Testmount successful: /dev/sdx2 to /testSDX after $WAITED seconds."
/bin/umount /testSDX 1>>/dev/null 2>>/dev/null
/bin/rmdir /testSDX
MOUNTED=1
break
fi
sleep 1
WAITED=$((WAITED + 1))
done
if [ $MOUNTED -eq 0 ]; then
/bin/echo "ERROR: /dev/sdx2 could not be mounted after 15 seconds."
fi
# end modification