Returning to the NSLU2 in 2010

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:

It defaults to DHCP, and doesn't fall back to 192.168.1.77
It doesn't appear to like the "sysconf" data left by 3.10 or the stock firmware

I've installed version 3.10 and SSH succeeds.

login as: root
root@192.168.1.77's password:
Host name:           LKG2C2BA6
Domain name:         workgroup
Host MAC:
Network boot method: dhcp
Use 'turnup init' to reset the configuration
Use 'turnup preserve' to save the configuration permanently
Use 'turnup restore' to restore a previously saved configuration
Use 'turnup disk|nfs -i <device> options to initialise a non-flash root
Use 'turnup help' for more information

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.

          WARNING: saved configuration files not restored
/etc/rcS.d/S12sysconfsetup: some of the saved configuration files must be
examined before restoration

The configuration of this machine has been reinitialised using the values
from /etc/default/sysconf, however configuration files saved in the SysConf
partition have not been restored.

You can restore these files by correcting any reported errors then running

  sysconf restore

from the command line.  This will completely reinitialise the configuration
using the information in the SysConf partition.

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.

Update:

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 upgrade tool and re-flash. It might be possible to simply reboot it though.

Also as the Windows 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.