I did get several of the MyBookWorld, 500 GB, units, in connections with home and work, in a period from the end of 2007 until now. Early on, I found the information on this forum, and it has been very useful; in particular, the initial hack to get the ssh. I've also had the time to investigate the hardware further, and found some interesting things there, that might be useful. I'm also really grateful for this forum, as I found much useful information here, and I'd like to add some of what I have done.
The first three units I got all have what I believe is the 1.01.18 firmware on them, and one of these did, nearly unmodified, serve as a backup unit on the network, until this summer when the disk was full. Later, I got hold of some more disks, but these all have the 2.00.15 or so, firmware on them, and these would fail to allow more than about 10 GB of data to be stored; a lot less useful than the earlier units. As I noticed here, there are several reasons why this has been happening.
I have used the "firmware update" from Martin Hinner on all these devices, after having created a non-root user through the web interface. The trick to avoid the "device busy" message that signify that the update cannot be done, is to make sure that none of the shares are being accessed from other machines on the network. In particular, that means no Windows machines should be looking for, or have any mapped drives to this share defined. But apart from that, I did get the ssh shell access, and could then switch user to root (su -) and make the ssh daemon permanent, as well as a proper login directory for the non-root user.
I found that the simplest way to do that is to enable the commented-out lines in /etc/inetd.conf for the ssh and telnet daemons. I did enable both, just for convenience.
I also turned off mionet by commenting out the line for starting it in /etc/init.d/post_network_start.sh. I have not investigated mionet much further though; just read all the bad things about it…
The presence of the C compiler on the earliest (firmware 1.01.x) devices is nice; to get it back on the later devices (firmware 2.01.x) where it was missing, I just compared all the files on the two units and copied the ones that were missing across; that made the compiler work there as well.
The username of my non-root user is all uppercase on the later units, that is however easy enough to change once you know about it.
The rev.2 disks have a couple other, and more serious, problems than just the missing compiler; after some time, there are journaling errors on the ext3 filesystems, both /dev/md3 and /dev/md4 shows these. Having not had the problem with the earliest units, this was very noticeable on the later ones. And I've seen plenty of information in this forum about these problems.
I took one device, went straight from unwrapping the box, get the ssh access, then unmount and then do fsck on /dev/md4 and the filesystem showed errors right away. This is not very good….
What seems to work is to re-format the /dev/md4 and /dev/md3 partitions — the "recipe" shown here under troubleshooting works fine for /dev/md4, and a similar job needs to be done on /dev/md3. The main difference is that /dev/md3 which is mounted on /var, has a lot of "lock-files" being used by daemons such as samba, lighttpd, and ntp. Thus, in order to get /dev/md3 unmounted, at least these must be stopped:
If things like ftp has been added later on, their daemons also need to be stopped. I used the command 'lsof | grep var' to find out which processes that were having files open on /var,
Now once /var is released, it is possible to continue with
and see all the errors that fsck found. I answered yes to everything. Unlike the large space on /dev/md4, this is only 950M so fsck is a fairly quick job. After it has been declared clean, it can be re-mounted, mount /dev/md3, but like the fix for /dev/md4, this volume should be backed-up, then re-formatted and restored.
It is too bad that the file-systems are bad as they come in the package. It can be argued that these devices are useless until these formatting jobs have been done. Makes for great hacking however…
And I found out one more thing about hardware hacking. In addition to hooking up a 3232 level translator and getting the serial port connected, there is another internal device bus available, that can be put to use.
This is an i2c-style bus, (or at least, the subset called "smbus") that apparently only was used for a non-existent Real-Time-Clock chip. Maybe some early version of these units had an on-board clock that would run when not powered on, and be used for setting date and time on start-up. Otherwise, the system would start at January 1 1970 … There are loaded modules and operating system support for this, but one of the mesages coming on the serial port on startup indicates that the clock chip is missing. Instead, the units use ntp (network time protocol) to get the date and time correct from the Internet.
Thus, it is possible to connect I2C peripherals, such as the PCF8574 digital IO circuit, DS1621 temperature sensor, or any of a large set of others to the MyBookWorld, and run programs there that access the hardware. The position on the circuit board, marked as U9, should have been this clock chip of the type M41T00, but it, and its supporting components are omitted in all the eight units that I have access to here. The two signal lines making up the I2C bus are SCL on pin 6 of U9, and SDA on pin 5 of U9. I also connected to ground, common, to pin 4 of U9. In addition, I used the 3.3V supply available from the serial port connection. This I2C bus runs on 3.3V, it is possible to make a voltage level translator with two NMOS transistors and some resistors, to run this at 5 V.
And even if this chip should be present, the I2C-bus is still available as long as we have devices with other slave addresses than the 0x68 that the clock chip uses. I have tested connecting a DS1621 and a PCF8574 to this I2C bus, and everything works as expected. You will have to do some careful "surgery" on the device to make these connections, and observe static discharge protection guidelines, so as not to kill the electronics, and of course, this will void any remaining warranty that might have survived the initial ssh-access hack.
Thanks for this very useful site!