I recently purchased a MyBookWorld, and after stumbling on this site decided to start modding it.
I also own a Netgear SC101 which for those that dont know is a micro SAN device. My goal is to allow the MBWE to control the SC101. To use this drive from Linux it is required to compile sc101-nbd package. As the name suggest this package requires the nbd kernel module to be loaded.
Herein lied my first difficulty as the nbd module was not included in the WD firmware. So after lengthly research managed to use the WD development toolkit's crosstool to build
the arm crosscompiler with uClibc and install locally. Using this crosscompiler I set about reconfiguring the kernel source included in WD development toolkit to build the nbd.ko (kernel module). (I would like to thank Mario Pascucci for his very informative guide about reviving a mybook) After a successful compile and many unsuccessful ones I then discovered the lack of depmod on MBWE and as far as I can tell from optware as well so had to compile this from source:(. Only one part left to the installation of nbd was to create the /dev/nbd0 special file as the MBWE does not use devfs. This was achieved with the mknod command, registering the device at major 43. After installing the nbd module and modprob'ing it successfully on the MBWE I thought that the hard part was over.
I managed to compile sc101-nbd-0.03 natively, only having to add an extra include to the source files for socket.h, I think. After loading the nbd module successfully and using the sc101-nbd package I managed to attach my sc101 to /dev/nbd0 and then mount this to /mnt/blah. I could browse the files stored on the sc101 from the mybookworld, cat also worked upto a point. Now comes the unexpected part, it appears that after some traffic has been received from the sc101 I start to get IO errors. A quick look in dmesg shows that nbd closed the socket and is now complaining that the socket is closed (control failed -32). After further looking about I think that there is some race condition that is happening as descried here but not entirely sure.
I am now thinking this is a bug with the specific kernel used which is exasperated by the MBWE architecture/scheduling algorithm, I attempted to pull nbd.c and nbd.h from a newer kernel (2.6.24) and place them into the correct places in the WD development toolkit linux-kernel source tree. Compilation failed as some data structures have changed and I am not experienced enough with C nor the linux kernel to start playing about at that level.
An option could be to use the procedure shown here to install Debian Lenny but I have some reservations. I noticed while looking about in the MBWE kernel source a number of modifications to the source that deviate from a vanilla kernel, primarily with respect to the oxnas architecture. But also there are a number of other files such as raid0.c raid1.c that are modified. I cant remember a complete list of these changes. The guide implies that just because arm5el arch is supported by Lenny, all will work. Also a look at the OX800SE on the manufactures website suggests this. Some features such as Java byte code execution is directly supported by the ARM architecture. But other features from the OX800SE chip such as high speed 128bit-AES encryption are lost? Would this be a fair assumption?
So essentially if I choose the Lenny route, I will loose all the software that ships with MBWE and some functions from the OX800SE chip? Also does the power button stops doing funky things? Does any body know what is lost and what is gained? I have head that Lenny is much faster than the default firmware? Are there any problems setting up raid1? I assume that with the default firmware that raid is managed by hardware tho cant find enough literature about the chip.
Any comments are appreciated, did I do something wrong with the nbd compilation/installation, has any body managed to get nbd working? Is there a simple solution I have overlooked?