I am returning to NSLU2 experimentation after a long break. The unit in question is being "Retasked", it had been used for a considerable time with openslug 3.10 (Big Endian), then was reflashed with stock firmware for a short while.
Now it has had the "Sysconf" memory erased and rebuilt so it will return to its default IP of 192.168.1.77.
It is my intention to install the latest build which appears to be version 5.3, however I appear unable to run this at this time, it almost boots but on reaching user mode it beeps three times and does not accept an SSH connection. It turns out that:
I've installed version 3.10 and SSH succeeds.
Inspiration dawns, DHCP is enabled, and whereas 3.10 is falling back to default 5.3 is either stuck waiting for DHCP or using a different unknown default.
OK you got me there, I'll try turnup init and see if that helps.
OK its looking better but still the three beeps, have I got the "beeps of doom" or is this normal?
turnup memstick -i /dev/sda1 seemed to run painlessly this time.
The swap partition appears to be recognised and used.
There is no obvious "build" package, "slugos-native" is not found.
Sadly my "Openslug" NSLU2 has been out of action for a while due to power supply failure. I've just obtained a replacement but now I'm wondering how long the brick that powers my server will last. The replacement is a generic 5V 2.5A unit that came with a 5.5/2.1mm connector. Unfortunately it appears as if the slug uses 5.5/2.5 style as I've just had to cut off and replace the connector. Its thick wire so its not easy.
Further update and a new use for old devices:
The NSLU2 has a new purpose!!
Running vanilla firmware with NO DISKS PRESENT it will function as "Master Browser" in small Windows 10 networks. This will stop Windows 10 machines from trying to be Master Browser and fix the ghastly network visibility problem.
Also note using it as a server there are some problems with using password protected folders with Windows 10. The solution is to turn off 'Convert failed logins to "guest" logins (Windows networks)' and possibly 'Enable Guest Logins' just to be sure.
What seems to happen is that if the NSLU2 is "visible" then Windows tries to access the shares, and will invisibly log in as guest. It appears impossible to log out as guest to enable a private log in, but banning guest appears to fix it, for now.
Dealing with corrupt configuration
Both my units had previously been used for non-stock firmware, meaning the configuration area contained unrecognisable data. As a result they were refusing to accept configuration commands.
The solution proved to be to use the "Telnet into Redboot" procedure from the nslu2-linux.org guide then "ResetSysConf".
Specifically the method I used was to set the computer to 192.168.0.10, connect it directly relying on auto-reverse to deal with polarity and ping the NSLU2 on 192.168.0.1 to detect the Redboot access window, then quickly open port 9000 using a Putty session during the couple of seconds when it accepted connections Putty has the advantage of an easy "restart session" option.
If you have an old 10baseT HUB (not a switch as a switch may take too long) then this will help as the computer will recognize the hub immediately without waiting for the NSLU2 to appear.
The above method is unreliable and it took 4 tries before I managed to send the "Control-C" in time to catch it, but it only has to work once.
The redboot command to erase sysconf is:
fis erase -f 0x50040000 -l 0x20000
Generally you would follow this with "upgrade" then run the Sercomm upgrade tool and reflash. It might be possible to simply reboot it though.
Also as the Sercom utility is incompatible with newer Windows versions it may be worth trying using Redboot to do the upgrade: http://www.nslu2-linux.org/wiki/pmwiki.php?pagename=HowTo/ReflashUsingRedbootAndTFTP
Unfortunately the firmware and tools are hard to find now. I can't help with that unless you can find me on one of the message boards I'm reachable on.
Dealing with DHCP problems
The stock firmware doesn't seem to accept an address via DHCP. Whether this has always been broken or whether it is a recent thing I couldn't say. Use a static IP.
I STRONGLY ADVISE WRITING THE IP ON A LABEL. Devices that use unknown non-stock IP and can't be reset tend to get junked even if perfectly usable.