Hello,
some days ago my WD MyCloud gen1 decided to die. Or rather its harddisk did.
Now, whenever I supply power to the harddisk, there is only a clicking sound every 5-6 seconds. But it is not recognised, neither in its own case, nor via SATA/USB-adaptor, nor via SATA inside desktop-PC.
Well, it lasted more than 6 years after all, and I have got backup.
I already ordered a replacement HDD.
And I read a lot through this forum, how a replacement HDD is supposed to be set up to work in the MyCloud case.
I found that there are basically two separate methods:
With method #1, you manually set up the partitions, create the raid, and then write the rootfs, config, and kernel img’s (coming from original firmware file of your choice) to the corresponding partitions.
With method #2, you write a complete image to the disk (you have to trust the source of the file, I guess, because it is not WD original). That’s almost it. If it was intended for a different disk size, you then have to modify partition 4 to use all of your disk size (or have the MyCloud OS do this final step).
Having read about these two methods, I am now wondering:
What should be consider when choosing between these two methods?
Why would you go for one method, and not the other method?
A third method, if the original My Cloud hard drive is still functioning, is to clone the drive to a new drive of the same or larger size.
As to which method to chose. That’s up to you and your skill set at using Linux. Everyone who has done it more than once, will have their own go to method. Personally having unbricked a number of drives for a first gen (250GB, 500GB, 750GB 2.5 inch drive, 1TB, 8TB and 12TB) over the years mostly as experimentation I just use the Fox_Exe directions (files and directions found here: https://fox-exe.ru/WDMyCloud/WDMyCloud-Gen1/). Can usually unbrick the drive and have it up and running in 20 minutes (to the latest firmware) or so using Ubuntu. I generally use the v3.x file to avoid the out of space error on one of the partitions that I get with the v4.x file. Don’t have to worry about trying to find the “image” file other unbrick directions use.
There are tons of past discussions that explain how to use any of the three unbrick general methods. One can use the forum search feature (magnifying glass icon upper right) to find those many past discussions.
Thank you for your answer.
And thanks for mentioning the third method.
Yes, I am familiar with Linux and its commandline.
In the past days, I have read many threads around here, and the commands and descriptions look quite straight forward to me.
So what you are saying is, that when using Fox’s “Replace HDD”, the advantage is that you can be sure to use files from original WD firmware. I agree that this is somewhat preferable over using an image-file that was downloaded from “somewhere” off the internet.
Not saying that at all. The files one uses (for example first gen: original_v03.04.01-230.tar.gz or original_v04.01.02-417.tar.gz) to unbrick are downloaded from user Fox_exe’s website, not from the My Cloud website. After successfully unbricking the My Cloud one can update the My Cloud to the latest firmware from the My Cloud website.
Usually where people fail during the unbrick process is not following the steps exactly. People will forget steps, enter them wrong, or change the partition sizes to match their hard drive size. Generally if one follows the directions exactly they can unbrick the My Cloud device.
Oh, I see. I thought you could download these older firmware files also from WD and verify that they are identical with the files on Fox’ website.
But it seems that only the most recent firmware file is downloadable from WD site.
And apparently, the WD firmware files only contain the rootfs.img, but not the other two files.
So I am curious: Where do kernel.img and config.img originally come from? Have they been created from existing MyCloud installations at some time?
I admit I was a bit concerned and irritated about the following.
When using the method, where you manually do the partitioning, you apparently set partition 5 and 6 to identical sizes by using these commands, because there is 100M from start to end, for both partitions:
This seemed to be in contrast to the partition table of my original WD MyCloud drive (I did a screenshot a few a weeks ago when it was still alive), where it showed partition 5 to have 95M (194560 sectors) and partition 6 to have 96M (196608 sectors). However all went fine with the method, because the difference is created directly by parted during the process, due to alignment.
Interestingly, kernel.img from Fox_exe’s v3 files exactly matches the size of partition 5 (95M) and is a little bit smaller than partition 6.
And kernel.img from Fox_exe’s v4 files exactly matches the size of partition 6 (96M), but is then of course a little bit too big for partition 5 (95M). This is most likely the reason for the errors (you mentioned in other threads) which you receive when you do the process with the v4 files.
I used the v3 files and all went as expected.
In the end, I still got a red light, and in the working web-UI it displayed only 1,5TB instead of my ~4TB. But then I did the quick factory restore, and now everything seems fine
Btw, the different partitions thing only matters for kernel.img and partitions 5/6.
Because the config.img (1M) is small enough to fit both partition 7 (1M) and partition 8 (2M).
And partitions 1 and 2 have exactly the same size after all (3999744 sectors)
