THIS GUIDE COULD SERIOUSLY SCREW YOUR NAS - you will be connecting a serial device directly to the main PCB of the NAS, and fiddling around in its bootloader. If you brick it even more than it already is, or blow it up, that’s on you! Don’t bother coming crying to me, I bear no responsibility for the validity or repeatability of this guide, it is just what I did to get my NAS back up and running. IT WILL ALSO COMPLETELY TOTALLY AND UTTERLY VOID YOUR WD WARRANTY, but you signed up for that when you installed custom firmware. If you didn’t installed custom firmware and your NAS is bricked, ask WD to see if they will fix it.
If you brick your EX2, it _ *may* _ be possible to recover it.
To do so however, you need to connect to the serial port inside the device. You will find if you take the EX2 apart that on the reverse of the PCB there is a connector J2.
On mine it wasn’t populated, but there is the footprint a 5 pin 2.54mm header with one pin missing and lines marked on the PCB.
If you do not have a header, solder one on.
The connector has the following pin map:
5 o ← RX Data
4 (No pin)
3 o — N/C (3.3V)
2 o — GND
1 o → TX Data
Connect this to a 3.3V USB to serial device such as a sparkfun FTDI 3.3V breakout board/cable. Make sure the RX pin connects to the TX pin of the FTDI board. Don’t connect anything to the 3.3V pin!
Using something like PuTTY, open the serial port at 115200,8,N,1 (no flow control).
Now boot your bricked NAS. You should see a whole lot of information being printed out of the terminal. If you don’t, check your connections are correct and you have RX/TX the correct way around.
Hopefully you should see uBoot loading - there will be a breif second where it says “press any key to stop autoboot”. This is a bit misleading as you cannot press just any key!
We need to make sure we send the correct keys in time to avoid uBoot from automatically loading the dead kernel from the NAND flash.
To do this, turn off the NAS, leaving the serial connection open. Then turn it back on again. As soo as you turn it on start repeatedly sending the following key combination through the serial port:
then ‘1’ then ‘1’ and so on. i.e.:
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
You should see it get to the line saying ‘press any key to stop autoboot’, only this time, the next line should be:
Marvell>>
If you see that prompt, then you were successful. You are now in an interactive uBoot console. WOO.
Just to check it is working enter at the prompt
Marvell>> ?
and press enter.
You should see a list of commands. If you do, great!
Connect your network cable and enter the command:
Marvell>> dhcp
It should now connect to the network and get an IP address.
#############################################################
Now we need to get it to boot a working kernel/filesystem. To do this, you need access to a tftp server, the easiest way of getting this is by booting a linux distribution such as Ubuntu on your computer. If you don’t want to install linux, you can use a live CD.
I am using Ubuntu, so if you are not, the next instructions might differ.
First install the tftp packages:
~$ sudo apt-get install xinetd tftpd tftp
Next, create a tftp service file using:
~$ sudo nano /etc/xinetd.d/tftp
Add into that file the following:
service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = <directory to your service files, e.g. /tftpboot>
disable = no
}
Save the file, then create the directory specified in server_args. e.g.
sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot
Then restart the xinetd service
sudo /etc/init.d/xinetd restart
To test the tftp server, you can do the following:
First, create a test file:
echo Hi > /tftpboot/test
Then, get the ip address of your computer:
ifconfig
then do:
tftp
get test
quit
cat test
It should say “Hi”.
The above setting up the tftp server was found here:
http://askubuntu.com/questions/201505/how-do-i-install-and-run-a-tftp-server
Next, add the working kernel uImage and uRamdisk files (can be found in the firmware/merge folder of a fresh copy of the GPL source from WD - don’t use the copy you used to compile your firmware as that one is buggered!) to the /tftpboot folder
For some reason, in order for this to work, you need to set the owner and permissions of the /tftpboot folder and all its contents to group nobody:root, and permissions 766
sudo chmod 766 /tftpboot
sudo chmod 766 /tftpboot/*
sudo chown nobody:root /tftpboot
sudo chown nobody:root /tftpboot/*
Otherwise you will get “Access Error (2)” when trying to run tftp on the Nas.
####################################################################
As an alternative to the above, all of the next steps, including the TFTP stuff can be done in Windows if you prefer, you just need PuTTY to connect the the serial port, and to download tftpd32. Just set up tftpd32 to be only a tftp server, and select the network interface that is on the same network as your NAS. Make a folder called ‘tftpboot’ and point tftpd32 to that directory as its root.
Next, add the working kernel uImage and uRamdisk files (can be found in the firmware/merge folder of a fresh copy of the GPL source from WD - don’t use the copy you used to compile your firmware as that one is buggered!) to the /tftpboot folder
####################################################################
Now, on the Nas, to tell if the IP address of your tftp server, do:
Marvel>> setenv serverip
Next we set up the boot arguments so that uBoot will load the two files from the tftp server and then boot them.
Marvel>> setenv bootargs console=ttyS0,115200 root=/dev/ram rw ip=dhcp eth=${ethaddr}
Marvel>> setenv bootcmd ‘tftp 0x2000000 uImage; tftp 0x3000000 uRamdisk; bootm 0x2000000 0x3000000’
Now we boot into linux:
Marvel>> boot
Boot will fail to find image.cfs, but will prompt to activate console. Press enter
The default password of admin is nothing, just press enter. You now have a console!
!The next commands should be run on your NAS, not your host pc!
For the next part to work, we need to get mount and umount commands working. It appears that library dependencies are missing. So from the firmware/module/crfs folder of the GPL source code, we need to get our missing files.
The following are required:
firmware/module/crfs/lib/libblkid.so.1.0
firmware/module/crfs/lib/libuuid.so.1.3.0
Place those files in your /tftpboot folder
Copy that to the Nas /lib folder using:
cd /lib
tftp -l libblkid.so.1.0 -g 192.168.1.2 #or your
tftp -l libuuid.so.1.3.0 -g 192.168.1.2 #or your
Unfortunately there are symbolic links now which are missing so now we need to recreate them.
Run the following commands:
ln -s libblkid.so.1.0 libblkid.so.1
ln -s libblkid.so.1 libblkid.so
ln -s libuuid.so.1.3.0 libuuid.so.1.3
ln -s libuuid.so.1.3 libuuid.so.1
Try running umount like:
umount
And hopefully it shouldn’t complain about missing libraries now.
The image.cfs file from the flash is still mounted at this point as umount was screwed when it tried to unmount it, so do:
umount /dev/loop0
umount /proc
umount /usr/local/modules
umount /usr/local/config
umount /sys/fs/cgroup
/etc/rc.sh
You should probably do the above lines *twice*. When I was working out how to get this all to boot, it seemed that some times doing it once wasn’t enough. I never had to do it more than twice.
Now we have the problem that all the files in /usr/local/modules/script are read only! That is truly great for an operating system to have all its executable files not being able to execute and which /etc/rc.sh fails miserably. It comes down to the fact that it is a squashfs filesystem mounted as read-only.
So, we need to extract the file system to somewhere with enough space to take it so that we have read/write/execute permissions - RAM does not as it is over 600MB!
So, lets mount one of the nice big HDDs that are in the Nas!
!!!Warning!!!
THIS WILL NOT WORK IF YOU USE RAID 0 !! Mounting the HDD like this will likely corrupt your striped array. Even for RAID 1 it is risky as it will result in the two drives getting out of sync, but at least that *should* be recoverable by rebuilding the mirror array once everything is fixed.
!!!
mkdir /media
mkdir /media/bob
mount /dev/sda2 /media/bob
df -h
(p.s. you don’t have to call it bob, I was just bored)
You should see that the hard drive has been mounted.
So, lets copy the filesystem to it!
mkdir /media/bob/recoverysys
cp -R /usr/local/modules/ /media/bob/recoverysys/
Now we unmount the image and instead put a symbolic link to our HDD copy:
umount /usr/local/modules
rm /usr/local/modules -R
ln -s /media/bob/recoverysys/modules /usr/local/modules
Now lets correct those file permissions!
cd /usr/local/modules/
chmod -R 700 *
Now granted the above is a terrible thing to do in an operating system, but at this point it really doesn’t matter as the OS is just installed in RAM so will be erased next time we reboot. I couldn’t be bothered to go through and work out which files needed there permissions changing, so I did the lot.
Now they are executable, lets run the startup script.
cd /
/usr/local/modules/script/system_init
Well it sort of worked. Seems that libsqlite bauked out. Shucks.
On the plus side it is now running the WDMyCloudEX2 firmware. But because stuff failed, the webpage is completely unusable - I just got a blank grey screen.
But it seems that it is enough. It is possible to flash the WD firmware via SSH without the webpage. Of course we are connected via Serial, but the only difference between us and SSH is the interface, they are both command line terminals.
So, lets copy the firmware across. (First you need to download it from WD)
I am using version 1.05.30 as it is the latest at time of writing.
Download the file, extract it and you are left with a bin file. Place this bin file in your /tftpboot directory on your server so that we can copy it across using TFTP.
So copy it to the WD nas:
cd /shares/Public
tftp -l My_Cloud_KC2A_1.05.30.bin -g
Now the moment of truth. I was **bleep**ting myself at this point…
/usr/local/sbin/updateFirmwareFromFile.sh My_Cloud_KC2A_1.05.30.bin
It started off seeming as if all was going well, I watched it erasing the NAND partition and all looked good. Then it stopped. It was sitting there doing nothing. So I had a choice between either cancelling and trying again, or waiting. Thankfully I decided to wait.
About 2 minutes later, the process exited and I saw a nice message saying that the NAS is scheduling for restart.
But then once again nothing happened. It just sat there. After 5 minutes of this I got bored and pressed the enter key. And happily the prompt appeared again. So I manually rebooted the NAS using:
reboot
Back to uBoot it went, but this time I didn’t stop autoload, so it started booting from the flash.
Could it be?!?
Is it working?!?!
*shakes in anticipation*
IT BOOTED!
Ok, so now there is at least a good firmware image in the flash and it can boot from it. The front LED was blinking orange at this point, much like when I turned it on for the very first time. After a bit of waiting for any sign of it doing something, I got bored and decided to go to the device webpage. What do you know, it’s ALIVE!
I set up the My Cloud account and user account again and it’s back to stock firmware!
At this point I got some nice messages saying the RAID was degraded, but I knew that was going to happen as I was using the HDD without a RAID controller. But that was nothing that going to the advanced options and rebuilding the array didn’t fix.
Hopefully someone will find this useful.
