I picked up a 6TB WD/Hitachi data centre drive pretty cheaply, and was hoping to use it to upgrade my 2TB drive.
I’ve used my cloning script to create the cloned disk, and that all seemed to work without trouble (I’ve tested the script on 1TB and 2TB disks previously).
However, when I hook it up to the controller, it comes up with white light, starts up the HDD, whirrs for a while, and then the light flashes off briefly, and the whole sequence starts again, repeating every couple of minutes or so.
I’ve tried 4s and 40s resets, but no joy.
What I have noticed is that the bigger drive has a higher 12V current requirement than the WD Red (0.8A, rather than 0.45A). Monitoring the 12V input on startup, I do see it dip a little below 12V at first (~11.8V), but it seems to hold steady at 12.1V during the cycling. The 5V and 12V supplies to the drive also look steady (with a DMM: need to monitor with a scope to check for short duration spikes). Assuming 90% efficiency in the SMPS devices for the supplies, that will require about 1.2A at the input. Which doesn’t allow much spare from the 1.5A wall wart to drive the 1.8V and 3.3V supplies for the control electronics. Am rummaging around for a beefier 12V supply…
So, the questions:
any suggestions for other causes of the white light cycle?
what is the maximum rated current you have seen on replacement drives that you have got working?
Make sure the My Cloud is connected to the local network router via Ethernet cable.
Can you access the My Cloud Dashboard using a web browser?
Generally any 3.5 inch hard drive should work. If attempting to use a 2.5 inch hard drive that was removed from a USB enclosure, note that in certain rare cases that 2.5 inch drive won’t work properly outside of the USB enclosure.
It’s a full-size WD/HGST Ultrastar DC HC310 3.5" SATA drive, intended for enterprise data centre use. SMART says it’s got only 8 hours use, and 14 power cycles when I bought it secondhand… It’s the L4 version, without built-in encryption.
It’s not the network cable problem; it’s repeatedly restarting initialisation, hence the brief white LED off repeat cycle. And no, I can’t access the Dashboard; and it never gives me a blue LED. Doesn’t give me red LED, either, though…
I still suspect it’s an overcurrent brownout, causing processor reset. I need to take it into work and use some proper test equipment on it, and see if I can find a psu monitor/watchdog chip.
One troubleshooting step is to use Fox_Exe’s unbrick procedure for your single bay My Cloud version (first gen v4.x or second gen v2.x) as the unbrick procedure is different for each version.
It is entirely possible the drive itself is bad or only designed for certain power supplies. Buying it second hand with just 8 hours and 14 power cycles, I’d be a bit weary of the drive. I’d connect the drive to a PC and run a surface test on the drive to ensure it’s operating properly.
My script is based on fox_exe’s instructions (which you would recognise if you looked at the script). It just automates the process to prevent manual errors, and corrects a couple of typos in fox’s instructions. It works fine, and has been used successfully with other drives.
I’ve tested the drive on a PC; it’s fine, too. It was bought from a commercial secondhand outlet, with a warranty, and they had a stack of them. I suspect some commercial clearance for some reason.
As I said, my main suspicion is the increased 12V current requirement, hence the question to survey what drives others have managed to get to run with the MyCloud controller board. The tps54394 dual SMPS controller can provide the required loads, provided the inductors are chosen suitably. The controller board has two of these devices on board, one to provide the 1V8 and 3V3 for the electronics, and one to provide the 5V and 12V for the HDD. But the limitation may be the 1.5A limit on the wall wart PSU. I’m going to try it with a lab supply, and see how much current it actually takes. It might just need a higher current wall wart.
Yes I know your script is based on Fox_Exe’s routine. At least as a troubleshooting step, by running Fox_Exe’s script one line at at time one can customize it’s actions to fit their system and any weird issues that might crop up like the stopping of the MD command in the script not working right or the failure of the .fresh_install to be performed upon reboot.
What is the model name/number of the drive? Maybe the drive is special designed for a specific server rack that has a higher power output (not something I’ve heard of but who knows). Some WD HGST drives have a 3.3volt pin issue that is solved by using kapton tape over one of the hard drive SATA power pins or by using a molex converter or by cutting one of the power wires (not something I’d do). Although I didn’t have the 3.3v problem with an HGST drive in a first gen single bay My Cloud.
The model I have doesn’t have the 3V3 control facility: HUS726T6TALE6L4
I took it into the lab today, and connected it to a decent lab PSU, which allows precise setting of the current limit. Set to 1.5A, 12V, it went into foldback limit as it tried to spin up the drive. Due to the precise control, it prevented spinup. With the wall wart, this is likely just to result in a drop in12V (as I saw). Increasing the current limit allowed the drive to spin up. However, I had to increase the current limit to 2.5A to prevent brief overcurrent spikes, which, although they didn’t register on the current output meter, did trigger the o/c detect circuit. At 2.5A, no o/c spikes were detected, whilst the average current varied between about 600-800mA.
However, even with the higher current limit, and no o/c spikes detected, it still continued the 42s reset cycle… The LED off cycle looks just like the one that occurs just after you power the drive up; white, off for ~1s, and then white again.
It’s still possible the on-board SMPS is unable to provide the required current (due to inadequte inductor current capability), but I couldn’t see any variation on the SATA power lines. Need to check with a scope.
Beyond that, I’ll modify the script to perform some sort of verification that the dd commnads have worked correctly; maybe an MD5 hash.
After that… hmmm…
I will have a look at running the setup manually. That’s the way I did it first, and then ran the script to overwrite it. It’s possible the RAID setup worked manually okay (because I remember having to do the ‘“watch cat /proc/mdstat” and wait 100%. Then - [ctrl] + [c] for close.’ bit. And the script doesn’t wait…). I thought I’d tried it on a 1TB and 2TB drive, but I found that I hadn’t actually run it on the 2TB drive. May format the 1TB drive under Windows, and then try the script…
The good news is that, even with a 2TB WD Black, with a 12V current rating within that of a WD Red, cloned using the script, the drive still does the 42 second cycle repeat. So it doesn’t look like it’s the PSU or the Ultrastar HDD that’s the problem.
The bad news is that, even when cloning by executing the commands manually, it still does the 42 second cycle. So it looks like there’s a problem with my cloning instructions, or image source.
I was trying to be too clever. I originally used original_v04.01.02-417.tar.gz as the image to run my script. But at some point, I decided it would be nice to clone with the newer image, original_v04.04.05-101.tar.gz, so I edited the script to use that image. But it looks like I never tried that in anger, as I have no logfile of that script. And all my recent cloning efforts have been using the later image and script.
So I went back to the ealier image and script, and ran it on the new disk, with partitions deleted, and it has booted first time. It did one 42-second reset cycle, which I thought was a bad sign, but I waited another 42 seconds, and it didn’t do another one, and then eventually turned blue.
Now set up as previously, and firmware upgraded. Copying all the files from the old disk to the new NAS, using systemrescuecd again.
Couldn’t remember where I’d got the later firmware image from. So I looked back into my ‘logfile.txt’, which is a record I keep of my mucking about with computer stuff:
06/08/18
TestCloud
refined clone_wd script
ran it on WD Blue 160GB
worked first time
decided to make 2TB drive 'clean' with MiB partitions
thought I'd be able to pull images off 1TB drive
did quick factory restore on 1TB drive
pulled images off
dd if=/dev/sda5 of=kernel_5.img
dd if=/dev/sda6 of=kernel_6.img
dd if=/dev/sda7 of=config_7.img
dd if=/dev/sda8 of=config_8.img
mdadm --stop /dev/md*
dd if=/dev/md1 of=rootfs.img
tar cvfz original_v04.04.05-101.tar.gz
edited clone_wd to use these images
ran on 2TB Red
needed to remove partitions and reboot
wouldn't boot
**kept doing 35-40s cycle of white light, blink off**
I seemed to have forgotten the purpose of the logfile, which is to record what worked, and what didn’t…
At least as a troubleshooting step, by running Fox_Exe’s script one line at at time one can customize it’s actions to fit their system and any weird issues that might crop up like the stopping of the MD command in the script not working right or the failure of the .fresh_install to be performed upon reboot.