Hello,
I got a Link Station Duo, LS-WX2.0TL/R1-EU (2Tb WXL).
The device worked fine for more than a year, but since it was configured to run in Raid0 mode, I had to reconfigure it to Raid1.
So I copied all the data that was stored on the unit to my other Link Stations - first source of annoyment: during the copying procedure, it went down several times, probably due to heat problems (?)... I had to let it cool down for an hour or more before I could continue to empty it. Well. Two days later it was finally done.
Then, before reconfiguring the disk array, I wanted to update the firmware; it ran on fw1.27, wich prevented me to use the disk backup feature, since it seemed not to be compatible with my newer units, that run on fw1.56.
So I got a file from the European Buffalo website with the name 'userfiles_file_downloads_LS-series-fw162_fwmac.dmg'. I ran the contained firmware installer, and it happyly updated the unit to fw1.62.
I rebooted several times with the new firmware, and tested the unit - up to that point, everything worked fine.
Then I reconfigured the array: started with deleting the Raid0 array, the progress went to 80%, and stayed at that value for 45 minutes. After that time, I tried to log in with a new browser tab, and it told me that there is no storage at all, no disks!
So I rebooted the unit, and that was it - solid red light, no boot, dead.
Tried to reset it with the function button according to the procedures on your website, no luck.
So I thought about booting from tftp, and read all information i found about that on your and other websites; and i unpacked the uImage.buffalo and initrd.buffalo images, set up a tftpd, configured my Mac to be on 192.168.11.1, switched off the firewall, and of course tested if the tftpd works and delivers the files - it does.
In detail, i did 'tftp', and on the tftp prompt i typed 'connect 192.168.11.1', 'status', 'verbose', 'trace', 'bin' and finally 'get uImage.buffalo' - and yes, I got the file delivered from the Mac's tftpd.
Now I powered up the Buffalo unit, and tried every possible combinations of booting with and without function button, pressing the function button after the unit was up, waiting for extended time ranges, with one, two and without disks, I even overwrote the disks with zeros to make shure it does not hang in a corrupted boot procedure read from the disks.
I even borrowed a Windows box from a friend and tried the recovery package available at ftp://24.153.165.234/array1/share/nas-recovery/, of course switching of the Windows firewall and configuring the ethernet port correctly.
No luck. It simply does not work.
Then I wanted to find out what the buffalo unit does on the network level, since there where no requests reported by the tftpd (and it logged the requests i did manually for testing).
To find out, I captured the network traffic, and voila - it does not even try to boot via tftp!
Instead, it seems to send out DHCP discovery packets, then gives itself a private dhcp address (169.254.80.100), does some ARP and finally gives up, sending out syslog packets stating that the internal dhcp client died from frustration (or better, from signal 15).
No packets to the destination 192.168.11.1 where sent out at all.
Since it is 3:30 in the morning and I'm fighting with this unit for 8 hours now, I'm shure that you understand that I am pretty annoyed, and I feel that it is Buffalo's turn now to change the way I think about this now.
Any help with this is welcome, for example:
There is a code (SN?) on the bottom of the unit, which is 1LSWXL100300131 - what is the 'product id' of my unit? I'll probably need this information to find out wich is the right kernel after I set up a dhcpd for the unit to boot from.
Is there any possibility to get this back to working state without the network boot - for example partitioning and initializing the disk myself, so it boots up again?
Any other possibility to get my Linkstation back in working state?
Thank you very much, with greetings...
f liszt
All right, this mother**bleep**er is up and running again.
As stated in the previous post, it tried to configure itself via dhcp.
Fortunately, the Mac comes with a dhcp server, which ist called "bootpd", and can do bootp, dhcp and some other protocols. Unfortunately, there is no configuration file provided, so you have to write one (/etc/bootpd.plist) from scratch... but that's not too hard.
I configured bootpd to act as a dhcp server for the network 192.168.11/24, starting with 192.168.11.2, and left my Macintosh configured as 192.168.11.1.
Besides that, I made shure that the tftpd was up and running.
Then I started the LS-WXL, and BINGO - it booted happyly from my Mac. It ended up in an EM-mode, and I could see it in the NasNavigator.
Then I started the firmware updater again, after I edited two lines in the LSUpdater.ini file:
Changed VersionCheck to 0 and NoFormatting to 0 in the [Flags] section.
The updater could see the WXL (reported NO firmware), and it installed 1.62 ... it came back with some dumb error message about being unable to send a file, but since the unit sounded like initializing the disk, i just waited and let things happen....
Voila, after a time it rebooted itself, and in the NasNavigator now it showed to have fw1.62 installed.
I could log in to the web interface, and the storage was back - both disks combined to a raid0 array, which should be the factory default.
So I shut down the tftpd server on the MacBook (but left bootpd running to provide an IP address for the box), and rebooted again - it came up without any problems.
Then I followed the procedures to change raid0 to raid1, reconnected the thing to my normal network, and there it sits waiting to be used, reconstructing the raid1 at this time.
Well, what's my opinion about this now?
The Buffalo boxes seem to be quite capable, but if you run into problems with them, it can sometimes be hard to solve. I needed to engage a network monitor first to find out what the box wants.
If you only have a Windows machine, you're probably completely **bleep**ed in such a situation, you would at least need a Mac or some other Unix box to get things going again.
Not recommended for the average user, but a good bang for the bucks for an IT pro.
Thanks 4 your help - or at least for praying with me (that helped as well),
greetings and good bye...
f liszt
P.S. good starting point for reading how this works: http://buffalo.nas-central.org/index.php/Revive_your_arm9_box_from_scratch