Hello, I'm having the exact same problem as AntoxaVR6. I opened up my shiny new MyBook Live 2TB, found out that it was running Debian and that you could easily enable SSH. Seeing as squeeze is officially released, I think "Hey, I should add the squeeze repos and do an apt-get dist-upgrade", so I look at the sources.list, see that the squeeze repo is already there and do an apt-get update. It was missing the squeeze gpg key, which I thought was strange but decided to ignore and simply downloaded it from http://ftp-master.debian.org/keys/archive-key-6.0.asc and installed it. I then decided to do an apt-get upgrade before going for an all out dist-upgrade, and when it was done the WebUI had stopped working. Using the information on the main page I figured out how to get it back up and running (php ini thing), but I decided I should revert to official firmware using the technique posted here. When all was said and done though, I got the same bad checksum error so I re-downloaded 4 times and compared the md5 to the one posted here http://community.wdc.com/t5/My-Book-Live/What-did-I-break-quot-Upgrade-copy-failure-quot-when-updating/td-p/200472 (seems to be the same problem on the official boards), and they all failed (even though the md5 matched the aforementioned sum). Based on that discussion and my own observations, I would guess it is an incompatible version of dpkg or md5sum (more likely md5sum since the person in the other thread reverted dpkg to the initial one, md5sum is the program reporting the initial error, and coreutils was updated). The versions I have are dpkg 1.15.8.10 and md5sum 8.5 (coreutils 8.5-1). If somebody with a clean system could check the versions of these it would be much appreciated. Its not super critical at the moment (everything, including the WebUI seems to be working fine), but I'm afraid to restart the device, or even disconnect my ssh session. Any help would be great, thanks.
OK, I tried downgrading to the latest coreutils from Lenny (6.10-6), and I got the same problem. If I was sure that the everything was actually correct I would replace md5sum with a simple program to return 0 to the shell, but I have a feeling that something may actually be screwing up somewhere. It may still be as simple as having to have exactly the right version of coreutils, but something like how htye generate md5 sums shouldn't change (if it does, that is a serious problem).
I have no idea what is going wrong. I riped apart the deb file, and the md5 of the rootfs.img matches that found in the rootfs.md5 file (4d2551e3133bfe3180051d7ef0e58e17). The file size of the rootfs.img exactly matches that found in the postinstall script (2047803392). I have read the script in question like 10 times and the only pertinent part is:
echo "Copy image to upgrade device ${upgradeDevice}"
dd if=${imageFile} of=${upgradeDevice} > /dev/null 2> /dev/null
echo "Compare checksum"
dd if=${upgradeDevice} bs=${blockSize} count=${blockCount} 2> /dev/null | md5sum -c ${imageMd5}
checksumOk=$?
echo "ok ${checksumOk}"
so unless the copy actually fails (for example upgradeDevice doesn't have enough space, or the local device doesn't have enough space to extract the deb) I don't see any reason this would not work. I may have to add a bunch of debug echo statements to their install scripts, repackage the deb and see what is going wrong.
On another note, I'm not entirely sure how this works at all considering it extracts the img to / (and thus /CacheBolume/upgrade) and the rootfs.img is like 2GB, but the rootfs is only like 1.9G total, in fact the only mount large enough to hold it is the Data Volume (unless it keeps an extra partition for installing the new rootfs to). (Edit: after some experimenting I determined that it does store the data on the Data Volume.)
Ok, by editing the post install script (which does all the legwork) to add some more debug statements I have determined that it is infact not copying the entire img file, dd is only writing 31231 64k blocks when it needs to copy 31247 blocks (yes it is off by like one MB). I have no idea why this worked the first time I installed this update (first thing I did out of the box), and not now (except for possibly the fact that the newer packages might be larger and are taking up space needed by other stuff).
So, for some reason the new rootfs is being created just a little bit too small. Latter today I will try to debug the creation process. I tried removing some unnecessary packages to free up space, but that didn't help at all, so the additional space used by the newer packages is almost certainly not the issue. It is possible that the end of that image is just padding anyway and it wouldn't matter if I just force the installer past it, but I really don't want to do that. If anybody else has any ideas they would be greatly appreciated. I apologize for the giant wall of text this post has become, but I hate double posting.