hmm now when i looked at the white light kernel source, it seems like it can be configured to work on blue ring, the ox800 modules are still there
ok i tried it now and the ox800sata module is not compiling, didn't see any obvious solution to it and so i gave up.

Sorry for asking a probably stupid question, but I can't unmount /shares/internal.
I reverted back to the original samba, ssh and lighttpd servers (I had upgraded versions installed with opt).
As far as I know I now use the original config files.
This is running processes (no occurences of smb, opt or shares there):

Indeed, looks pretty odd. I guess, the safest way to solve this problem is to comment out /dev/md4 line in /etc/fstab and reboot. It should work as long as there's no init script that explicitly does the mount, like 'mount /dev/md4 /shares/internal'.

I guess that the groups command is supposed to return the group ids for the groups that the user is a part of.
But if I call id -g USER which is what the error message seems to want me to do, I only get the group id for the group with the same name as the user, not all groups the user is a member of.
It feels like it would be quite simple to fix this, to edit the groups command to do what I want, but I have no idea how. Any help would be very apprecerated!

Well, looks like /usr/bin/groups script is designed to be used with the GNU id and isn't compatible with the busybox's one. You can either download it from here, configure and compile it yourself or wait till I do it for you. Wrong link. What we need is to compile coreutils. Thanks for the notice, I will have it pre-installed in the next version.

It is great when someone actually knows what he is talking about!
After having done a find for the groups command and viewed it, I saw that the groups command try to use the id command with options -Gn which the installed id command does not have. After your reply I understand why.
I will wait for the next version with anticipation.

I'm thinking it won't hurt to add them as well. What I am concerned about is whether replacing this many binaries can actually break something… I mean, they appear to work fine in qemu-emulated chroot environment on my PC, but I can't test them on the box, since I'm running debian there.

UPD: if fixing this groups issue is an emergency, I can upload the binary this very moment - just tell me if you need to

I am sorry, but I do not have the possibility to do an image of my mybook and restore it if somethings goes wrong. I do not have any Linux OS installed at home (except on the mybook :-), which makes it difficult to handle the drive properly even when I plug it into a desktop directly. If there is no other way I guess I could make a try on your new firmware upgrade sometime in the future when I have a bit more time to repair if things go wrong.

Since you are building a new firmware version anyway, I have another bug fix request for the new firmware (if you want to fix it):

Before I did the firmware upgrade my hard drive used to spin down and the mybook went silent when I was not using it for a while (during the night for example). It would spin up by it self, but only occationally.
After I did the firmware upgrade my hard drive never spins down. You said you updated hdparm in v2. Something about that must have broken the spin down feature.

Before I did the firmware upgrade my hard drive used to spin down and the mybook went silent when I was not using it for a while (during the night for example). It would spin up by it self, but only occationally.
After I did the firmware upgrade my hard drive never spins down. You said you updated hdparm in v2. Something about that must have broken the spin down feature.

What you're talking about is probably not a bug: this firmware simply has no pre-install spin-down mechanisms. I did consider adding them at some point, but decided against doing so, since it can potentially become a serious threat. Imagine some user unknowingly installs something that regularly writes some loge entries to some place other then a ram disk. If the period of writing those entries is neither too big nor too small, drive(s) will probably spin down and then spin up again quite often, which is REALLY BAD and will probably cause a hardware failure pretty soon. Certainly, we don't want this to happen :-)

But, if you want, you can install those mechanisms manually just like you did with the original fw. If you already did and it doesn't work, it's probably because some busybox implementations are used where they're not expected to be used. Wait till I release the next version, and try it again.

Btw, I'm done with building util-linux. Here's the list of upgraded binaries:

But, if you want, you can install those [spin-down] mechanisms manually just like you did with the original fw

The reason I mentioned it was because I had not installed any additional spin-down mechanisms before applying your firmware. The spin-down worked anyway (no matter what kyyhkynen says about the original hdparm being broken). And after applying your firmware, the spin-down stopped working.

This is really not a big deal. I will try with kyyhkynen smart spin down.
I just wanted you to know that I am still guessing that it might be a bug.

I am really greatful for all the work you put down into this! (no matter what you choose to do about the spin-down :-)
I will try to install it during the weekend.
I will report:

Thanks a lot for your feedback and credits! In fact, I'm still a student and currently don't even have a girlfriend, not to mention having kids :-) To tell you the truth, though, I don't really have a lot of free time, since I'm receiving my bachelor's degree this summer.

Regarding spin-down, like I said, it can potentially be a serious threat, so imho it's good the way it is now.

As for WinSCP, I already tried it myself (believe or not, but I do have to run Windows on my laptop). Looks good to me.

I applied your firmware. I got a strange error after mionet.tar something. It just said something similar to unrecoverable error, exiting, but it did not say what the error was. (I accidentely closed the Putty-window before I saved the log)
Anyway, it still applied your firmware. Everything seemed fine. SSH worked, Samba worked, Lighttpd worked, WinSCP worked.
So I edited /etc/inetd.conf to start my updated opt version of ssh (I did a symbolic link to my opt installation like you said in the tutorial):

After restarting I could not access SSH and Samba. Web interface still up. Shit. Fourth time I lost SSH connection since I started hacking. Had to be be because of my change of inetd.conf.
Tried restarting MyBook again (don't ask me why). This time I came in with Putty… sort of. I was asked for username and password then got the following error (before starting shell):

Server refused to allocate pty

Tried with WinSCP. It worked! I came in with WinSCP. Looked up inetd.con and viewed it. Nothing seemed strange. Cannot change it though, since I cannot su to root (or log on as root. Blank password.)
Very strange everything.
Restarted third time. Locked out totally again (except web interface).
Restarted fourth time. Same error from Putty as after second restart. But! Samba suddenly works. And WinSCP like after second restart.

Will not touch anything for now. Since I can access my files again.
What do you think?
The drive is a little bit warm, but does not feel to hot. (thought about possible overheating)

Well, replacing stock ssh by optware's one is a VERY bad idea. What if it breaks after some upgrade? Sticking to the stock one is a better idea. If there's some serious reason why you would want to upgrade ssh to some newer version, better post it here - and I will probably have it updated in the next release.

Thanks for your reply alllexx, but it did not solve the problem.
Your command reverted back to using stock ssh. Putty asked about weather to trust the new keys (or whatever it asks).
But I still get the same error after entering my username and password:

Ok, problem confirmed. v4 removed for now. Since access as root is available using WinSCP, I should be able to fix this problem without taking drive(s) out of the box. Will look into it as soon as I can. I'm very sorry for this inconvenience.

No problem. First I was a bit worried, but now the drive seems stable and everything works except for Putty. It seems like a solvable problem.
After this post I will not bother you with my guesses. But this seems like the most promising bit of info from my googling (http://foo-projects.org/pipermail/lunar/2005-February/005042.html):

I ran your custom script set the root password to 'welc0me', but it did not work
I have have run it twice and try to log on with username 'root' and password 'welc0me'
I have tried both without restarting and with restarting (I understand that it should not matter).
I have tried with WinSCP using SFTP and SCP and with Putty.
I also tried with a sudo command from WinSCP as a part of the login, but it did not work.

The script has to be incorrect. I googled on password change through script and found this:

echo -e "welc0me\welc0me" | (passwd --stdin root)

Will it work?
I do not dare to screw up the root user without asking you first :-)

Finally!
Logged in and able to su.
Changed permissions on /etc/inittab like you suggested.
Could log in with Putty after that but not su. Complaining about no "valid shadow password".
So I changed the permission on the /etc/shadow so I could edit that as well.
The row about root ended with a '/' and since there should be a number there (days since 1 Jan 1970) I felt confident enough to remove it and then I could su!!!! :-)
(So small bug in your root password update script. Remove ending '/'.)
So. Ready for the next firmware upgrade then :-)

It's just the way the stock upgrade scripts are configured: upgrade1.sh, which prepares the system to enter upgrade mode, copies /var/upgrade/rootfs.ext2 to /var/lib/rootfs.ext2.pending, which in turn is moved to /var/lib/rootfs.ext2 (together with some other upgrade files) by upgrade2.sh after the upgrade is done. The reason it fails with ldso-runpath-enabled fw is that the rootfs.ext2 image is much larger then the stock ones (~300 MB), so there's simply not enough space on /dev/md3 to make this backup. I guess, I'll disable it in the next release :)

I was wondering if this firmware upgrade is compatible with the Web server firmware upgrade?

Hi again!
This is a better observation than the one I sent you in the message.syslogd was running even if the following rows were commented out in /etc/inittab as suggested by kyyhkynen (they were commented out from start by your firmware upgrade I guess):

# ::respawn:/sbin/syslogd -n -m 0
# ::respawn:/sbin/klogd -n

I guessed the problem was in /etc and made a grep for syslogd there and guess what I found: /etc/init.d/S25syslog
So syslogd is started with an init.d script instead. Since there is no forum post with the string "/etc/init.d/S25syslog" I guess it is added by your firmware?
After stopping it the spindown went fine:

/etc/init.d/S25syslog stop

I fixed the problem the kyyhkynen way by just commenting out the start commands in /etc/init.d/S25syslog:

You're right about /etc/init.d/S25syslog - I did add it myself after upgrading syslog. It's best to have syslog running so that you can have some log entries to look at after something crashed. To avoid issues with spinning down, you should probably mount a ram disk on /var/log and use smth like ramlog to move the logs to /var/log.hdd on the hdd whenever drive(s) spin up. Since the same goes for /opt/var, it's getting a bit tricky, so you can either try it yourself, or wait till I have some time to figure it out and write a how-to.

have encountered a few problems already, but i am in the process of working past the minor ones. my share passwords were not saved and i have to manually restore users. i also had to manually install lighttpd and reconfigure that. but what really ticks me is that the swap is not activated. do i have to put swapon -a into a startup script? why would the swap not be on by default? heck, why does this firmware need so much work to be done after applying it before i can get my system running again? i hope the upgrade to use webdav is worth it. i do like the other features it includes too.