NSLU2-Linux
view · edit · print · history

Debian.TroubleShooting History

Hide minor edits - Show changes to markup

January 18, 2014, at 10:59 PM by nandhp -- How to install lenny in 2014
Added lines 295-319:

lenny installer won't detect your USB disks

As one of the last to transition to armel (in 2014!), I encountered some new problems using lenny's debian-installer. I had tried to use the debian-armel-5.0.9.zip version of the installer that includes the firmware for the onboard Ethernet, but it wouldn't recognize my USB disk. Checking dmesg, I had errors like this:
sd_mod: Unknown symbol scsi_verify_blk_ioctl
sd_mod: Unknown symbol scsi_cmd_blk_ioctl
The problem is that the Debian installer kernel received an update in 2012, which means that the kernel modules downloaded by the installer are newer than the kernel in the installer image, and contain incompatible changes to the SCSI disk support (used for USB disks). You have to use a newer version of the installer. Download the official installer image from the Debian archives and patch the image to add the firmware for the built-in Ethernet to the initrd:
$ slugimage -u -i nslu2.bin
$ devio '<< ramdisk.gz; xp $ 4' > ramdisk-swap.gz
$ zcat ramdisk-swap.gz > ramdisk.cpio
$ mkdir -p initrd-extra/lib/firmware
# Install the firmware into this directory
$ ls initrd-extra/lib/firmware
lrwxrwxrwx 1  14 Jan 18 12:54 NPE-B -> NPE-B.01020201
-rw-r--r-- 1 16K Jan 18 12:54 NPE-B.01020201
$ cd initrd-extra
$ find lib | fakeroot cpio -o --append -H newc -O ../ramdisk.cpio
$ cd ..
$ gzip -9 < ../ramdisk.cpio > ../ramdisk2.cpio.gz
$ dd if=ramdisk2.cpio.gz of=ramdisk2.cpio.gz.padded ibs=6291440 conv=sync
$ devio "<<"ramdisk2.cpio.gz.padded > ramdisk2.cpio.gz.swapped "xp $,4"
$ slugimage -p -o di-nslu2-current.img -k vmlinuz -L apex.bin -r ramdisk2.cpio.gz.swapped
November 08, 2008, at 02:11 PM by Ryan McLean -- Added note about eth0 changing to eth1 upon upgrading from etch to lenny
Changed lines 255-256 from:
At some point the onboard nic switched from eth0 to eth1. Turn off the slug. Take your usb disk out and mount it on another machine, edit /etc/network/interfaces. Duplicate your eth0 config to eth1. Unmount the disk. Plug it back into the slug. Power the slug on.
to:
At some point the onboard nic switched from eth0 to eth1 (This can happen upon upgrading from etch to lenny). Turn off the slug. Take your usb disk out and mount it on another machine, edit /etc/network/interfaces. Duplicate your eth0 config to eth1. Unmount the disk. Plug it back into the slug. Power the slug on.
October 29, 2008, at 06:33 PM by frank -- clarify another reason why the line auto eth0 might be needed
Changed lines 42-43 from:
Update: This occurs when apt attempts to install the "hotplug" package.
to:
Update: This occurs when apt attempts to install the "hotplug" package. Or possibly after removing the default dhcp3-client and switching over to a static inet config.
October 26, 2008, at 08:21 AM by Martin Manscher -- Typo
Changed lines 14-15 from:
Comment: In my case, the IP address was lost when rebooting after a firmware upgrade. It's possibe that this is because I allocated an IP range not containing 192.168.1.77 to the DHCP server while the NSLU2 was sunning (uptime was around 150 days when I rebooted).
to:
Comment: In my case, the IP address was lost when rebooting after a firmware upgrade. It's possibe that this is because I allocated an IP range not containing 192.168.1.77 to the DHCP server while the NSLU2 was running (uptime was around 150 days when I rebooted).
October 26, 2008, at 08:21 AM by Martin Manscher -- Added comment on how to restore IP address
Added lines 14-16:
Comment: In my case, the IP address was lost when rebooting after a firmware upgrade. It's possibe that this is because I allocated an IP range not containing 192.168.1.77 to the DHCP server while the NSLU2 was sunning (uptime was around 150 days when I rebooted).
When "stuck" with an unknown IP address, one way is to log into your router or other DHCP server (if this is possible for you) and find the IP address assigned to your NSLU2 device. If possible, you may want to set up DHCP such that an IP address (e.g. 192.168.1.77) is reserved for your NSLU2's MAC address (which you can find on the bottom of the case or using upslug2). If you cannot recover this way, a (drastic) way to recover is to flash the original Linksys firmware, press and hold the reset button for two seconds to reset the IP address to 192.168.1.77 (the NSLU2 device should beep once to confirm this), log into the web-based interface and configure the IP address from there. Then you can flash the installer and re-install. Use manual partitioning to configure mount points; you can keep your existing data in /home etc., but you may run into problems if you do not remove the system dirs or format the root partition (assuming this is a different partion from /home).
September 01, 2008, at 01:55 PM by fcarolo -- undid spam
Changed lines 1-291 from:

Really good site!

to:

Troubleshooting Debian on the NSLU2


After flashing the installer, I cannot ssh or ping the NSLU2.

Quoting from Martin Michlmayr's installation instructions (with some additional formatting),
"Regardless of which image you intend to use, you should configure your network settings (IP address, DNS, hostname) using the web interface before flashing the debian-installer image in case you do not want to use DHCP. Debian's installer will use those settings to bring up the network.
"Please note that if you use a static IP configuration, you have to specify all information, including netmask, gateway and DNS. If you don't specify all information, debian-installer will not be able to bring up the network and there's currently no way to tell the user that an error has occurred. An incomplete network configuration has so far been the most common reasons for problems with these images, so please make sure you have filled in all values."
The 4.0rc2 installer will use DHCP if you leave default IP address (192.168.1.77). See this thread for more information.

Installation fails when the installer starts to format the new ext3 partition. What can I do?

This can happen at 33% for example and the SSH connection closes. The reason is probably that the format process runs out of memory.
Solution: Restart the installer by power cycling the NSLU2. Wait for the beeps, then ssh in as before. Follow the steps up to disk partitioning, and then use the partman manual partitioning mode to do the following:
  1. Delete all partitions the installer has created.
  2. Create a new primary swap partition that is at least 256MB.
  3. Create a new primary EXT3 partition, to be mounted on "/", and set it active.
  4. Write the new settings to the drive and installation should continue normally
Alternate solution: I had that problem with my 500 GB WD My Book. The format process ran out of memory because I wanted to format a 500 GB partition. When I created a smaller 40 GB partition as / mount point it worked well.
It has been reported that creating a swap partition a primary partition, SSH will fail during formatting every time, but if you make it a logical partition it works.
Another possibility: Create the partitions on another Linux machine using (c)fdisk and mk2fs.ext3 and then start the NSLU2 debian installer, choose manual partitioning and set the ext3 partition as root (/).

Loss of Network Connectivity

Jim Buzbee reported here
Case in point is that I had been successfully running my new Debian Slug for a couple of days, booting and rebooting a number of times. At some point, I noticed that I couldn't reach the slug on the network. I don't remember exactly what I had done last, but to bring it back, I just unplugged and re-plugged the power. As it booted back up, everything looked normal. The LEDs flashed, the disk clicked and all seemed right with the world. But when the boot finished, the NSLU2 was again nowhere to be found on my network.
Update: This occurs when apt attempts to install the "hotplug" package.
And the Fix:
The only way I could see what was happening was to add debug statements to the boot, building my own boot log. This was a tedious process of adding statements, unplugging the drive from my MacBook, plugging it back into my NSLU2, rebooting the NSLU2, putting the disk back on my MacBook, examining the logs, etc. What I finally found is that everything was normal except that the interfaces file, which tells the Debian boot which network interfaces to bring up, was missing the one line that told it to automatically configure the internal Ethernet device. Once I added this line, I rebooted and was back to normal.
From my experience, this was the file was missing an auto eth0 line.
In windows arp -a reported the NSLU2 IP Address with a MAC Address of 00-00-00-00-00-00 and that it was Invalid. I was unable to ping it, and therefore no SSH
If you know what you are doing, you only need to add auto eth0 to /etc/network/interfaces, using vi, nano, or what ever other text editor you are familiar with.
My Old/default Debian Etch RC1 /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 192.168.0.70
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
        dns-search example.org
Fixed /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
auto eth0
iface eth0 inet static
        address 192.168.0.70
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
        dns-search example.org
I also commented #allow-hotplug eth0 out upon suggestion in NSLU2-General IRC Channel.
After changing this, on reboot, I was able to ping during boot, ARP -a was reporting correctly, and when start up was complete - I had SSH. I have reported this on the debian-arm mailing list, as my config was like the top one from installation.
-I also lost network connection, and the above fix didn't solve it. By attaching the harddisk to a different computer I soon realized that the S40networking link was gone, god knows why. I recreated the link and got back the network connection.
cd /etc/rcS.d/ \\
ln -s ../init.d/networking S40networking \\
[[~Patrik Hermansson]]

After successfully logging in to the Etch RC2 installer, via SSH over the NSLU2's onboard ethernet, the screen is cleared and nothing happens.

This behavior has been observed when logging in from a Debian Sarge machine. Logging in from a Debian Etch machine results in the successful display of the installer.

The slug fails to reboot with 2 drives connected

See MountDisksByLabel for a better method. The method below has no impact on the drive boot order.

If you connect a second drive after you have installed Debian, for example to store your data files, the order of the drives will be random after rebooting, i.e. the new drive could become /dev/sda with your root filesystem being /dev/sdb. If that happens the slug will fail to boot because it will be looking for its root filesystem on the wrong disk. To recover, boot with only the root drive connected and change your fstab to mount your root drive by UUID by following the procedure outlined below.
List the UUIDs of your drives with the tree (apt-get install tree) command
$ tree /dev/disk
/dev/disk
|-- by-id
|   |-- usb-[=ST340014=]_A_5000000000002886 -> ../../sda
|   |-- usb-[=ST340014=]_A_5000000000002886-part1 -> ../../sda1
|   |-- usb-[=ST340014=]_A_5000000000002886-part2 -> ../../sda2
|   `-- usb-[=ST340014=]_A_5000000000002886-part5 -> ../../sda5
|-- by-path
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sda
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sda1
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part2 -> ../../sda2
|   `-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part5 -> ../../sda5
`-- by-uuid
   `-- 424ba820-8e80-422e-aaeb-b343b4a462f1 -> ../../sda1
and then modify your fstab by replacing /dev/sda1 (your root partition) with the UUID, e.g.
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
UUID=424ba820-8e80-422e-aaeb-b343b4a462f1       /       ext3 defaults,errors=remount-ro 0       1
/dev/sda5       none            swap    sw              0       0
/dev/sda1       /media/usb0     auto    rw,user,noauto  0       0
/dev/sda5       /media/usb1     auto    rw,user,noauto  0       0
Then update the initramfs:
$ sudo update-initramfs -u
and flash the new initramfs
$ sudo flash-kernel

You may want to make a copy of your existing flash before this last step in case something goes wrong. To do that, use the following command:

$ cat /dev/mtdblock* > image

The slug gets stuck during boot

The default configuration will cause the slug to fail to boot if errors are encountered during filesystem check on reboot. This can be the cause of a slug which works fine over a few reboots but then one day hangs during boot with no response to ping or ssh. This problem is described in the README. The simple fix is to set "FSCKFIX=yes" in /etc/default/rcS. Do this on the first boot, or connect the slug drive to another computer to make the change.
The README also suggests changes which cause networking and SSH to start earlier in the init procedure, both of which can help to diagnose problems like this.

The slug hangs during reboot (stuck on orange LED, no HD activity.)

As per the nslu2-utils README.Debian, a solid orange status LED means that the system is in the process of loading the initramfs from flash. If the system doesn't come out of this state, then something has gone wrong during the initramfs load, and the root filesystem hasn't mounted.
This could be due to the slug waiting for a response on the console. On an existing system, the most likely cause of this is due to fsck having found a problem during filesystem check on reboot. As described in the README, the slug can be set to automatically fix any errors found by fsck. The symptoms are similar to the network problem described above, although the boot hangs early on and the main LED remains amber.
To fix this, edit /etc/default/rcS and set FSCKFIX=yes. If your slug is hanging, you can edit this file by mounting the disk on another computer and editing the file from there. Upon reboot the slug may take a long time as it performs a full fsck run, but the disk activity lights will show you that it hasn't hung. After the fsck the slug will finish booting.
Another cause of the initramfs not completing is because the root filesystem device wasn't found. If your system's root filesystem is on RAID or LVM, or you've just upgraded your system, your initramfs might not be quite right. Fiddling with the initramfs isn't particularly hard -- you can mount the system disk on another machine, and it's just a regular initramfs (cpio.gz) format -- but the slug is a bit different to a regular x86 machine, because it doesn't read the initramfs off disk. It reads it from flash. So to get your new and improved initramfs working, you need to write it to flash.
Since your initramfs is toast, you can't simply boot up and run flash-kernel. Instead, you need to either use upslug2 or the NSLU2 equivalent of a rescue disk to re-flash.
The upslug2 option
You need to make a new image containing the new initramfs to send to the device. Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader (thanks to Rod Whitby for pointing that out to me). The easiest way to create a new image is to use the slugimage utility (from the Debian package of the same name) to unpack an existing firmware image (such as the default di-nslu2.bin), replace the initramfs (and maybe the kernel if you're feeling eager), then repack the new image ready for loading into your upgrade-mode slug with upslug2. One point to note is that you need to pass slugimage the -L option (with the location of your APEX image, such as -L apex.bin) so that you don't get the dreaded "Ran out of flash space in <Kernel>" message.
The "rescue disk" option
In this case, you want to download the standard etch firmware from Martin Michlmayr's tarball install, write it to the slug with upslug2, then reboot and write the new initramfs (which you've presumably left on the system's hard drive after modifying it) using flash-kernel.
This may also be due to the RTC not being setup (described below) as Debian etch tries to access the hwclock during system startup (/etc/rcS.d/S11hwclock), which is called before the LED is switched to green.
Fstab Problems
In my case I had added a line to fstab for drive sdb1 on USB port 2. My boot disk is sda1. Symptoms were exactly as shown here, the drive was accessed a few times at slug power-on, but the Disk1 LED never lit up at all. Removed the new line from fstab and it booted up no problem after that.
Or maybe simply the drive is being checked
My NSLU2 didn't reboot correctly today. I spent a few hours trying to figure it out.

The NSLU2 was starting, I was getting Reader/Status LED solid orange and Network solid green. The drive was making some noise and I could see some led activity on it, until nothing after a few seconds.

I plugged the drive on my laptop and typed "tune2fs -l /dev/sdb1" to notice that the drive had reached the maximum mount count, and the drive was actually being checked.


The slug hangs during reboot (status and ethernet LED green)

If the activity light on the USB hard disk is flashing every few seconds, and the network is not yet up, this could be due to hwclock hanging. Sometimes the internal RTC on the slug does not work. In this case the hwclock init script hangs trying to read the RTC. To fix, remove and replace the battery to reset the RTC. As a temporary fix, can connect the disk to another computer and delete the hwclock script link from /etc/rcS.d.

Long Startup Time (hwclock)

An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with
$ sudo hwclock  --systohc
Make sure no ntp daemon is running (e.g.: chrony), else hwclock will give an error about /dev/rtc being busy.
If this doesn’t work you could try to change the NSLU2 battery.
note: Before flashing/installing Debian you might want to adjust the time using the original Linksys firmware that comes with the slug. I had a slug that took 40-60 minutes to boot. I pinpointed the issue to hwclock as I noticed when executing the command manually, once the slug was up, it timed out after about 40-60 minutes. I changed the battery as recommended above with no change to the boot behaviour. On the IRC channel I was recommended to re-flash the slug with the original Linksys firmware (I had to use the erase all utility as I got the "Error: fail to get samba information" error), set the time and install/flash debian again - and voilà the slug boots like a charm in less than 2 minutes. Thanks to rwhitby on the #debian-arm IRC Channel. - Cheers l00nix

Connecting Second NSLU2 to Network Hangs Existing NSLU2

Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hangs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk on the NSLU2s. From one of the emails in the thread:
"I fired up my protocol analyzer and monitored both boxes. It appears that the first Slug hangs as soon as the second Slug send an Apple Zone GetNetInfo request. After I disable AT on the Slug and reboot. Both boxes are running fine. I believe people have multiple slug working have the AppleTalk be disabled."

I just upgraded my nslu2 system using aptitude. The device boots fine, but my network device doesn't work!

At some point the onboard nic switched from eth0 to eth1. Turn off the slug. Take your usb disk out and mount it on another machine, edit /etc/network/interfaces. Duplicate your eth0 config to eth1. Unmount the disk. Plug it back into the slug. Power the slug on.

The installer can't get get release info from the Debian mirror. Otherwise the installer works fine.

If you're behind a NAT router, this can happen if the NSLU2 is set to use a static IP address. Choose "Start Shell" instead of "Start Menu" and run
dhclient eth0
to get a dynamic ip address from the router. You will need to go into the router's setup to see what ip address was assigned, as your ssh connection will be dropped. ssh to the newly assigned ip address and proceed with the install like before.

Beta 2 of the Debian installer for lenny fails to detect the disk drive ("No disk drive was detected")

In the debian-armel-5.0beta2, there is a bug with libparted. libparted1.7-udeb does not exist any more but needed by the debian installer. The solution is to go into a shell (by going back in the install menus) then do a ln -s /lib/libparted-1.8.so.9.0.0 /lib/libparted-1.7.so.1

and exit.

Here are the /var/log/syslog symptomatic of the problem:

Aug 15 10:35:20 kernel:  sda:
Aug 15 10:35:21 kernel:  sda1 sda2 sda3
Aug 15 10:35:21 kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Aug 15 10:35:58 main-menu[776]: (process:3191):
 parted_devices: error while loading shared libraries: libparted-1.7.so.1: cannot open shared object file: No such file or directory

Trying to add the parted module does not solve the problem since this is the 1.8 version that is installed:

Aug 15 10:36:45 anna[4210]: DEBUG: resolver (libgcc1): package doesn't exist (ignored)
Aug 15 10:36:45 anna[4210]: DEBUG: resolver (libparted1.7-udeb): package doesn't exist (ignored)
Aug 15 10:36:45 anna[4210]: DEBUG: retrieving lvm2-udeb 2.02.39-2
Aug 15 10:36:47 anna[4210]: DEBUG: retrieving md-modules-2.6.24-1-ixp4xx-di 1.15
Aug 15 10:36:48 anna[4210]: DEBUG: retrieving partman-lvm 61

News: this bug has been corrected a day after I detected it (Aug 15/2008). Well, see how I did the troubleshooting if this problem occurs again...

September 01, 2008, at 09:55 AM by Brytney --
Changed lines 1-291 from:

Troubleshooting Debian on the NSLU2


After flashing the installer, I cannot ssh or ping the NSLU2.

Quoting from Martin Michlmayr's installation instructions (with some additional formatting),
"Regardless of which image you intend to use, you should configure your network settings (IP address, DNS, hostname) using the web interface before flashing the debian-installer image in case you do not want to use DHCP. Debian's installer will use those settings to bring up the network.
"Please note that if you use a static IP configuration, you have to specify all information, including netmask, gateway and DNS. If you don't specify all information, debian-installer will not be able to bring up the network and there's currently no way to tell the user that an error has occurred. An incomplete network configuration has so far been the most common reasons for problems with these images, so please make sure you have filled in all values."
The 4.0rc2 installer will use DHCP if you leave default IP address (192.168.1.77). See this thread for more information.

Installation fails when the installer starts to format the new ext3 partition. What can I do?

This can happen at 33% for example and the SSH connection closes. The reason is probably that the format process runs out of memory.
Solution: Restart the installer by power cycling the NSLU2. Wait for the beeps, then ssh in as before. Follow the steps up to disk partitioning, and then use the partman manual partitioning mode to do the following:
  1. Delete all partitions the installer has created.
  2. Create a new primary swap partition that is at least 256MB.
  3. Create a new primary EXT3 partition, to be mounted on "/", and set it active.
  4. Write the new settings to the drive and installation should continue normally
Alternate solution: I had that problem with my 500 GB WD My Book. The format process ran out of memory because I wanted to format a 500 GB partition. When I created a smaller 40 GB partition as / mount point it worked well.
It has been reported that creating a swap partition a primary partition, SSH will fail during formatting every time, but if you make it a logical partition it works.
Another possibility: Create the partitions on another Linux machine using (c)fdisk and mk2fs.ext3 and then start the NSLU2 debian installer, choose manual partitioning and set the ext3 partition as root (/).

Loss of Network Connectivity

Jim Buzbee reported here
Case in point is that I had been successfully running my new Debian Slug for a couple of days, booting and rebooting a number of times. At some point, I noticed that I couldn't reach the slug on the network. I don't remember exactly what I had done last, but to bring it back, I just unplugged and re-plugged the power. As it booted back up, everything looked normal. The LEDs flashed, the disk clicked and all seemed right with the world. But when the boot finished, the NSLU2 was again nowhere to be found on my network.
Update: This occurs when apt attempts to install the "hotplug" package.
And the Fix:
The only way I could see what was happening was to add debug statements to the boot, building my own boot log. This was a tedious process of adding statements, unplugging the drive from my MacBook, plugging it back into my NSLU2, rebooting the NSLU2, putting the disk back on my MacBook, examining the logs, etc. What I finally found is that everything was normal except that the interfaces file, which tells the Debian boot which network interfaces to bring up, was missing the one line that told it to automatically configure the internal Ethernet device. Once I added this line, I rebooted and was back to normal.
From my experience, this was the file was missing an auto eth0 line.
In windows arp -a reported the NSLU2 IP Address with a MAC Address of 00-00-00-00-00-00 and that it was Invalid. I was unable to ping it, and therefore no SSH
If you know what you are doing, you only need to add auto eth0 to /etc/network/interfaces, using vi, nano, or what ever other text editor you are familiar with.
My Old/default Debian Etch RC1 /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 192.168.0.70
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
        dns-search example.org
Fixed /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
auto eth0
iface eth0 inet static
        address 192.168.0.70
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
        dns-search example.org
I also commented #allow-hotplug eth0 out upon suggestion in NSLU2-General IRC Channel.
After changing this, on reboot, I was able to ping during boot, ARP -a was reporting correctly, and when start up was complete - I had SSH. I have reported this on the debian-arm mailing list, as my config was like the top one from installation.
-I also lost network connection, and the above fix didn't solve it. By attaching the harddisk to a different computer I soon realized that the S40networking link was gone, god knows why. I recreated the link and got back the network connection.
cd /etc/rcS.d/ \\
ln -s ../init.d/networking S40networking \\
[[~Patrik Hermansson]]

After successfully logging in to the Etch RC2 installer, via SSH over the NSLU2's onboard ethernet, the screen is cleared and nothing happens.

This behavior has been observed when logging in from a Debian Sarge machine. Logging in from a Debian Etch machine results in the successful display of the installer.

The slug fails to reboot with 2 drives connected

See MountDisksByLabel for a better method. The method below has no impact on the drive boot order.

If you connect a second drive after you have installed Debian, for example to store your data files, the order of the drives will be random after rebooting, i.e. the new drive could become /dev/sda with your root filesystem being /dev/sdb. If that happens the slug will fail to boot because it will be looking for its root filesystem on the wrong disk. To recover, boot with only the root drive connected and change your fstab to mount your root drive by UUID by following the procedure outlined below.
List the UUIDs of your drives with the tree (apt-get install tree) command
$ tree /dev/disk
/dev/disk
|-- by-id
|   |-- usb-[=ST340014=]_A_5000000000002886 -> ../../sda
|   |-- usb-[=ST340014=]_A_5000000000002886-part1 -> ../../sda1
|   |-- usb-[=ST340014=]_A_5000000000002886-part2 -> ../../sda2
|   `-- usb-[=ST340014=]_A_5000000000002886-part5 -> ../../sda5
|-- by-path
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sda
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sda1
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part2 -> ../../sda2
|   `-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part5 -> ../../sda5
`-- by-uuid
   `-- 424ba820-8e80-422e-aaeb-b343b4a462f1 -> ../../sda1
and then modify your fstab by replacing /dev/sda1 (your root partition) with the UUID, e.g.
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
UUID=424ba820-8e80-422e-aaeb-b343b4a462f1       /       ext3 defaults,errors=remount-ro 0       1
/dev/sda5       none            swap    sw              0       0
/dev/sda1       /media/usb0     auto    rw,user,noauto  0       0
/dev/sda5       /media/usb1     auto    rw,user,noauto  0       0
Then update the initramfs:
$ sudo update-initramfs -u
and flash the new initramfs
$ sudo flash-kernel

You may want to make a copy of your existing flash before this last step in case something goes wrong. To do that, use the following command:

$ cat /dev/mtdblock* > image

The slug gets stuck during boot

The default configuration will cause the slug to fail to boot if errors are encountered during filesystem check on reboot. This can be the cause of a slug which works fine over a few reboots but then one day hangs during boot with no response to ping or ssh. This problem is described in the README. The simple fix is to set "FSCKFIX=yes" in /etc/default/rcS. Do this on the first boot, or connect the slug drive to another computer to make the change.
The README also suggests changes which cause networking and SSH to start earlier in the init procedure, both of which can help to diagnose problems like this.

The slug hangs during reboot (stuck on orange LED, no HD activity.)

As per the nslu2-utils README.Debian, a solid orange status LED means that the system is in the process of loading the initramfs from flash. If the system doesn't come out of this state, then something has gone wrong during the initramfs load, and the root filesystem hasn't mounted.
This could be due to the slug waiting for a response on the console. On an existing system, the most likely cause of this is due to fsck having found a problem during filesystem check on reboot. As described in the README, the slug can be set to automatically fix any errors found by fsck. The symptoms are similar to the network problem described above, although the boot hangs early on and the main LED remains amber.
To fix this, edit /etc/default/rcS and set FSCKFIX=yes. If your slug is hanging, you can edit this file by mounting the disk on another computer and editing the file from there. Upon reboot the slug may take a long time as it performs a full fsck run, but the disk activity lights will show you that it hasn't hung. After the fsck the slug will finish booting.
Another cause of the initramfs not completing is because the root filesystem device wasn't found. If your system's root filesystem is on RAID or LVM, or you've just upgraded your system, your initramfs might not be quite right. Fiddling with the initramfs isn't particularly hard -- you can mount the system disk on another machine, and it's just a regular initramfs (cpio.gz) format -- but the slug is a bit different to a regular x86 machine, because it doesn't read the initramfs off disk. It reads it from flash. So to get your new and improved initramfs working, you need to write it to flash.
Since your initramfs is toast, you can't simply boot up and run flash-kernel. Instead, you need to either use upslug2 or the NSLU2 equivalent of a rescue disk to re-flash.
The upslug2 option
You need to make a new image containing the new initramfs to send to the device. Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader (thanks to Rod Whitby for pointing that out to me). The easiest way to create a new image is to use the slugimage utility (from the Debian package of the same name) to unpack an existing firmware image (such as the default di-nslu2.bin), replace the initramfs (and maybe the kernel if you're feeling eager), then repack the new image ready for loading into your upgrade-mode slug with upslug2. One point to note is that you need to pass slugimage the -L option (with the location of your APEX image, such as -L apex.bin) so that you don't get the dreaded "Ran out of flash space in <Kernel>" message.
The "rescue disk" option
In this case, you want to download the standard etch firmware from Martin Michlmayr's tarball install, write it to the slug with upslug2, then reboot and write the new initramfs (which you've presumably left on the system's hard drive after modifying it) using flash-kernel.
This may also be due to the RTC not being setup (described below) as Debian etch tries to access the hwclock during system startup (/etc/rcS.d/S11hwclock), which is called before the LED is switched to green.
Fstab Problems
In my case I had added a line to fstab for drive sdb1 on USB port 2. My boot disk is sda1. Symptoms were exactly as shown here, the drive was accessed a few times at slug power-on, but the Disk1 LED never lit up at all. Removed the new line from fstab and it booted up no problem after that.
Or maybe simply the drive is being checked
My NSLU2 didn't reboot correctly today. I spent a few hours trying to figure it out.

The NSLU2 was starting, I was getting Reader/Status LED solid orange and Network solid green. The drive was making some noise and I could see some led activity on it, until nothing after a few seconds.

I plugged the drive on my laptop and typed "tune2fs -l /dev/sdb1" to notice that the drive had reached the maximum mount count, and the drive was actually being checked.


The slug hangs during reboot (status and ethernet LED green)

If the activity light on the USB hard disk is flashing every few seconds, and the network is not yet up, this could be due to hwclock hanging. Sometimes the internal RTC on the slug does not work. In this case the hwclock init script hangs trying to read the RTC. To fix, remove and replace the battery to reset the RTC. As a temporary fix, can connect the disk to another computer and delete the hwclock script link from /etc/rcS.d.

Long Startup Time (hwclock)

An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with
$ sudo hwclock  --systohc
Make sure no ntp daemon is running (e.g.: chrony), else hwclock will give an error about /dev/rtc being busy.
If this doesn’t work you could try to change the NSLU2 battery.
note: Before flashing/installing Debian you might want to adjust the time using the original Linksys firmware that comes with the slug. I had a slug that took 40-60 minutes to boot. I pinpointed the issue to hwclock as I noticed when executing the command manually, once the slug was up, it timed out after about 40-60 minutes. I changed the battery as recommended above with no change to the boot behaviour. On the IRC channel I was recommended to re-flash the slug with the original Linksys firmware (I had to use the erase all utility as I got the "Error: fail to get samba information" error), set the time and install/flash debian again - and voilà the slug boots like a charm in less than 2 minutes. Thanks to rwhitby on the #debian-arm IRC Channel. - Cheers l00nix

Connecting Second NSLU2 to Network Hangs Existing NSLU2

Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hangs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk on the NSLU2s. From one of the emails in the thread:
"I fired up my protocol analyzer and monitored both boxes. It appears that the first Slug hangs as soon as the second Slug send an Apple Zone GetNetInfo request. After I disable AT on the Slug and reboot. Both boxes are running fine. I believe people have multiple slug working have the AppleTalk be disabled."

I just upgraded my nslu2 system using aptitude. The device boots fine, but my network device doesn't work!

At some point the onboard nic switched from eth0 to eth1. Turn off the slug. Take your usb disk out and mount it on another machine, edit /etc/network/interfaces. Duplicate your eth0 config to eth1. Unmount the disk. Plug it back into the slug. Power the slug on.

The installer can't get get release info from the Debian mirror. Otherwise the installer works fine.

If you're behind a NAT router, this can happen if the NSLU2 is set to use a static IP address. Choose "Start Shell" instead of "Start Menu" and run
dhclient eth0
to get a dynamic ip address from the router. You will need to go into the router's setup to see what ip address was assigned, as your ssh connection will be dropped. ssh to the newly assigned ip address and proceed with the install like before.

Beta 2 of the Debian installer for lenny fails to detect the disk drive ("No disk drive was detected")

In the debian-armel-5.0beta2, there is a bug with libparted. libparted1.7-udeb does not exist any more but needed by the debian installer. The solution is to go into a shell (by going back in the install menus) then do a ln -s /lib/libparted-1.8.so.9.0.0 /lib/libparted-1.7.so.1

and exit.

Here are the /var/log/syslog symptomatic of the problem:

Aug 15 10:35:20 kernel:  sda:
Aug 15 10:35:21 kernel:  sda1 sda2 sda3
Aug 15 10:35:21 kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Aug 15 10:35:58 main-menu[776]: (process:3191):
 parted_devices: error while loading shared libraries: libparted-1.7.so.1: cannot open shared object file: No such file or directory

Trying to add the parted module does not solve the problem since this is the 1.8 version that is installed:

Aug 15 10:36:45 anna[4210]: DEBUG: resolver (libgcc1): package doesn't exist (ignored)
Aug 15 10:36:45 anna[4210]: DEBUG: resolver (libparted1.7-udeb): package doesn't exist (ignored)
Aug 15 10:36:45 anna[4210]: DEBUG: retrieving lvm2-udeb 2.02.39-2
Aug 15 10:36:47 anna[4210]: DEBUG: retrieving md-modules-2.6.24-1-ixp4xx-di 1.15
Aug 15 10:36:48 anna[4210]: DEBUG: retrieving partman-lvm 61

News: this bug has been corrected a day after I detected it (Aug 15/2008). Well, see how I did the troubleshooting if this problem occurs again...

to:

Really good site!

August 30, 2008, at 08:32 PM by Thierry MERLE -- debian-armel-5.0beta2 problem fixed
Changed line 282 from:
Trying to add the parted module does not solve the problem since this is the 1.8 version that is installed:
to:

Trying to add the parted module does not solve the problem since this is the 1.8 version that is installed:

Added line 290:

News: this bug has been corrected a day after I detected it (Aug 15/2008). Well, see how I did the troubleshooting if this problem occurs again...

August 15, 2008, at 11:07 AM by Thierry MERLE --
Changed line 283 from:

[@

to:
[@
August 15, 2008, at 11:07 AM by Thierry MERLE --
Changed lines 279-280 from:

Aug 15 10:35:58 main-menu[776]: (process:3191): parted_devices: error while loading shared libraries: libparted-1.7.so.1: cannot open shared object file: No such file or directory Trying to add the parted module does not solve the problem since this is the 1.8 version that is installed:

to:

Aug 15 10:35:58 main-menu[776]: (process:3191):

 parted_devices: error while loading shared libraries: libparted-1.7.so.1: cannot open shared object file: No such file or directory

@]

Trying to add the parted module does not solve the problem since this is the 1.8 version that is installed:

[@

August 15, 2008, at 11:04 AM by Thierry MERLE --
Added line 267:

August 15, 2008, at 11:03 AM by Thierry MERLE --
Changed line 269 from:

In the debian-armel-5.0beta2, there is a bug with libparted. libparted1.7-udeb does not exist any more but needed by the debian installer. The solution is to go into a shell (by going back in the install menus) then do a ln -s /lib/libparted-1.8.so.9.0.0 /lib/libparted-1.7.so.1

to:
In the debian-armel-5.0beta2, there is a bug with libparted. libparted1.7-udeb does not exist any more but needed by the debian installer. The solution is to go into a shell (by going back in the install menus) then do a ln -s /lib/libparted-1.8.so.9.0.0 /lib/libparted-1.7.so.1
Added line 271:
Added lines 273-274:
[@
Added lines 285-286:

@]

August 15, 2008, at 11:01 AM by Thierry MERLE -- Beta 2 of the Debian installer for lenny fails to detect the disk drive
Changed lines 265-281 from:
to get a dynamic ip address from the router. You will need to go into the router's setup to see what ip address was assigned, as your ssh connection will be dropped. ssh to the newly assigned ip address and proceed with the install like before.
to:
to get a dynamic ip address from the router. You will need to go into the router's setup to see what ip address was assigned, as your ssh connection will be dropped. ssh to the newly assigned ip address and proceed with the install like before.

Beta 2 of the Debian installer for lenny fails to detect the disk drive ("No disk drive was detected")

In the debian-armel-5.0beta2, there is a bug with libparted. libparted1.7-udeb does not exist any more but needed by the debian installer. The solution is to go into a shell (by going back in the install menus) then do a ln -s /lib/libparted-1.8.so.9.0.0 /lib/libparted-1.7.so.1 and exit. Here are the /var/log/syslog symptomatic of the problem: Aug 15 10:35:20 kernel: sda: Aug 15 10:35:21 kernel: sda1 sda2 sda3 Aug 15 10:35:21 kernel: sd 0:0:0:0: [sda] Attached SCSI disk Aug 15 10:35:58 main-menu[776]: (process:3191): parted_devices: error while loading shared libraries: libparted-1.7.so.1: cannot open shared object file: No such file or directory Trying to add the parted module does not solve the problem since this is the 1.8 version that is installed: Aug 15 10:36:45 anna[4210]: DEBUG: resolver (libgcc1): package doesn't exist (ignored) Aug 15 10:36:45 anna[4210]: DEBUG: resolver (libparted1.7-udeb): package doesn't exist (ignored) Aug 15 10:36:45 anna[4210]: DEBUG: retrieving lvm2-udeb 2.02.39-2 Aug 15 10:36:47 anna[4210]: DEBUG: retrieving md-modules-2.6.24-1-ixp4xx-di 1.15 Aug 15 10:36:48 anna[4210]: DEBUG: retrieving partman-lvm 61

August 07, 2008, at 02:52 AM by l00nix -- fixed link to FailSambaInformation wiki page
Changed lines 240-241 from:
note: Before flashing/installing Debian you might want to adjust the time using the original Linksys firmware that comes with the slug. I had a slug that took 40-60 minutes to boot. I pinpointed the issue to hwclock as I noticed when executing the command manually, once the slug was up, it timed out after about 40-60 minutes. I changed the battery as recommended above with no change to the boot behaviour. On the IRC channel I was recommended to re-flash the slug with the original Linksys firmware (I had to use the erase all utility as I got the "Error: fail to get samba information" error?), set the time and install/flash debian again - and voilà the slug boots like a charm in less than 2 minutes. Thanks to rwhitby on the #debian-arm IRC Channel. - Cheers l00nix
to:
note: Before flashing/installing Debian you might want to adjust the time using the original Linksys firmware that comes with the slug. I had a slug that took 40-60 minutes to boot. I pinpointed the issue to hwclock as I noticed when executing the command manually, once the slug was up, it timed out after about 40-60 minutes. I changed the battery as recommended above with no change to the boot behaviour. On the IRC channel I was recommended to re-flash the slug with the original Linksys firmware (I had to use the erase all utility as I got the "Error: fail to get samba information" error), set the time and install/flash debian again - and voilà the slug boots like a charm in less than 2 minutes. Thanks to rwhitby on the #debian-arm IRC Channel. - Cheers l00nix
August 07, 2008, at 02:49 AM by l00nix -- grammatical edits and added link to previous edit
Changed lines 240-241 from:
note: Before flashing debian you might want to adjust the time using the linksys firmware that comes with the slug. I had a slug that took 40-60 minutes to boot. I pin pointed the issue to hwclock as when I executed the command manually, once the slug was up, it timed out after about 40-60 minutes. I changed the battery as recommended above with no change. On the IRC channel it was recommended to me to re-flash the slug with the linksys firmware (had to use the erase all utility) set the time and install debian again - and voilà the slug boots like a charm in less than 2 minutes. Thanks to rwhitby on the #debian-arm IRC Channel. - Cheers l00nix
to:
note: Before flashing/installing Debian you might want to adjust the time using the original Linksys firmware that comes with the slug. I had a slug that took 40-60 minutes to boot. I pinpointed the issue to hwclock as I noticed when executing the command manually, once the slug was up, it timed out after about 40-60 minutes. I changed the battery as recommended above with no change to the boot behaviour. On the IRC channel I was recommended to re-flash the slug with the original Linksys firmware (I had to use the erase all utility as I got the "Error: fail to get samba information" error?), set the time and install/flash debian again - and voilà the slug boots like a charm in less than 2 minutes. Thanks to rwhitby on the #debian-arm IRC Channel. - Cheers l00nix
August 07, 2008, at 02:33 AM by l00nix -- another suggestion to fix to long boot issue
Added lines 240-241:
note: Before flashing debian you might want to adjust the time using the linksys firmware that comes with the slug. I had a slug that took 40-60 minutes to boot. I pin pointed the issue to hwclock as when I executed the command manually, once the slug was up, it timed out after about 40-60 minutes. I changed the battery as recommended above with no change. On the IRC channel it was recommended to me to re-flash the slug with the linksys firmware (had to use the erase all utility) set the time and install debian again - and voilà the slug boots like a charm in less than 2 minutes. Thanks to rwhitby on the #debian-arm IRC Channel. - Cheers l00nix
May 09, 2008, at 03:05 AM by Barry Schatz -- fixed my formatting
Changed lines 255-258 from:
If you're behind a NAT router, this can happen if the NSLU2 is set to use a static IP address. Choose "Start Shell" instead of "Start Menu" and run [@
to:
If you're behind a NAT router, this can happen if the NSLU2 is set to use a static IP address. Choose "Start Shell" instead of "Start Menu" and run
[@
Changed lines 261-263 from:

to get a dynamic ip address from the router. You will need to go into the router's setup to see what ip address was assigned, as your ssh connection will be dropped. ssh to the newly assigned ip address and proceed with the install like before.

to:
to get a dynamic ip address from the router. You will need to go into the router's setup to see what ip address was assigned, as your ssh connection will be dropped. ssh to the newly assigned ip address and proceed with the install like before.
May 09, 2008, at 02:50 AM by Barry Schatz -- Added if installer can\\
Added lines 251-258:

The installer can't get get release info from the Debian mirror. Otherwise the installer works fine.

If you're behind a NAT router, this can happen if the NSLU2 is set to use a static IP address. Choose "Start Shell" instead of "Start Menu" and run
dhclient eth0

to get a dynamic ip address from the router. You will need to go into the router's setup to see what ip address was assigned, as your ssh connection will be dropped. ssh to the newly assigned ip address and proceed with the install like before.

April 04, 2008, at 08:14 PM by kvaks -- adding how to save current flash image
Changed lines 174-175 from:

You may want to make a copy of your existing flash before this last step in case something goes wrong.

to:

You may want to make a copy of your existing flash before this last step in case something goes wrong. To do that, use the following command:

$ cat /dev/mtdblock* > image
Changed lines 238-239 from:
If this doesn’t work you could try to change the NSLU2 battery.
to:
If this doesn’t work you could try to change the NSLU2 battery.
March 28, 2008, at 01:02 PM by Tim -- Added a fix for network not working.
Added lines 243-247:

I just upgraded my nslu2 system using aptitude. The device boots fine, but my network device doesn't work!

At some point the onboard nic switched from eth0 to eth1. Turn off the slug. Take your usb disk out and mount it on another machine, edit /etc/network/interfaces. Duplicate your eth0 config to eth1. Unmount the disk. Plug it back into the slug. Power the slug on.
March 24, 2008, at 04:30 PM by Eric -- Increased min swap size to 256MB as per Martin Michlmayr\'s guide.
Changed line 20 from:
  1. Create a new primary swap partition that is at least 128MB.
to:
  1. Create a new primary swap partition that is at least 256MB.
March 04, 2008, at 04:30 PM by mverwijs --
Added line 234:
Make sure no ntp daemon is running (e.g.: chrony), else hwclock will give an error about /dev/rtc being busy.
February 27, 2008, at 06:08 PM by Del Merritt --
Added lines 30-31:
February 23, 2008, at 05:23 PM by sw -- nslu2 hanging at boot
Added lines 208-215:
Or maybe simply the drive is being checked
My NSLU2 didn't reboot correctly today. I spent a few hours trying to figure it out.

The NSLU2 was starting, I was getting Reader/Status LED solid orange and Network solid green. The drive was making some noise and I could see some led activity on it, until nothing after a few seconds.

I plugged the drive on my laptop and typed "tune2fs -l /dev/sdb1" to notice that the drive had reached the maximum mount count, and the drive was actually being checked.

February 09, 2008, at 02:45 PM by Reedy Boy -- ++
Changed lines 116-117 from:

See MountDisksByLabel for a better method

to:

See MountDisksByLabel for a better method. The method below has no impact on the drive boot order.

February 09, 2008, at 02:37 PM by Reedy Boy -- HowTo/MountDisksByLabel
Added lines 116-117:

See MountDisksByLabel for a better method

January 12, 2008, at 02:07 PM by kshaposhnikovgmailcom --
Changed lines 12-14 from:
The 4.0rc2 installer will use DHCP if you leave default IP address (192.168.1.77). See [[ http://groups.google.com/group/linux.debian.ports.arm/browse_thread/thread/461cd33ffc3adb84/cfcaaef7ba1e4386?lnk=gst&q=NSLU2#cfcaaef7ba1e4386
 | this thread ]] for more information.
to:
The 4.0rc2 installer will use DHCP if you leave default IP address (192.168.1.77). See this thread for more information.
January 12, 2008, at 02:04 PM by kshaposhnikovgmailcom -- Added note about DHCP and default IP address
Added lines 12-14:
The 4.0rc2 installer will use DHCP if you leave default IP address (192.168.1.77). See [[ http://groups.google.com/group/linux.debian.ports.arm/browse_thread/thread/461cd33ffc3adb84/cfcaaef7ba1e4386?lnk=gst&q=NSLU2#cfcaaef7ba1e4386
 | this thread ]] for more information.
January 04, 2008, at 02:44 PM by Patrik Hermansson --
Changed line 101 from:

[@

to:
[@
Changed line 103 from:

ln -s ../init.d/networking S40networking @@\\

to:

ln -s ../init.d/networking S40networking \\

January 04, 2008, at 02:44 PM by Patrik Hermansson --
Changed lines 100-101 from:
small I also lost network connection, and the above fix didn't solve it. By attaching the harddisk to a different computer I soon realized that the S40networking link was gone, god knows why. I recreated the link and got back the network connection.

@@

to:
-I also lost network connection, and the above fix didn't solve it. By attaching the harddisk to a different computer I soon realized that the S40networking link was gone, god knows why. I recreated the link and got back the network connection.

[@

Changed line 105 from:
to:

@]

January 04, 2008, at 02:42 PM by Patrik Hermansson --
Changed lines 101-102 from:

cd /etc/rcS.d/ ln -s ../init.d/networking S40networking \\

to:

@@ cd /etc/rcS.d/
ln -s ../init.d/networking S40networking @@\\

January 04, 2008, at 02:41 PM by Patrik Hermansson --
Changed line 100 from:
I also lost network connection, and the above fix didn't solve it. By attaching the harddisk to a different computer I soon realized that the S40networking link was gone, god knows why. I recreated the link and got back the network connection.
to:
small I also lost network connection, and the above fix didn't solve it. By attaching the harddisk to a different computer I soon realized that the S40networking link was gone, god knows why. I recreated the link and got back the network connection.
Changed line 102 from:

ln -s ../init.d/networking S40networking

to:

ln -s ../init.d/networking S40networking \\

January 04, 2008, at 02:39 PM by Patrik Hermansson --
Added lines 100-104:
I also lost network connection, and the above fix didn't solve it. By attaching the harddisk to a different computer I soon realized that the S40networking link was gone, god knows why. I recreated the link and got back the network connection.

cd /etc/rcS.d/ ln -s ../init.d/networking S40networking Patrik Hermansson

December 29, 2007, at 09:35 PM by Reedy Boy -- rem dupe
Changed lines 172-179 from:

I rebooted and now cannot contact the slug

This is probably due the network interface not being properly set up. It could also be due to the FSCK bug or the RTC not working (see below)
To fix the network configuration you will need to edit a file on your USB drive/stick. This will require you to either mount the root partition on another machine or install a serial port http://www.nslu2-linux.org/wiki/HowTo/AddASerialPort. The fix is to edit the '/etc/network/interfaces' file. Make sure to back up the file first.
The original file should look something like this.
to:

The slug hangs during reboot (stuck on orange LED, no HD activity.)

As per the nslu2-utils README.Debian, a solid orange status LED means that the system is in the process of loading the initramfs from flash. If the system doesn't come out of this state, then something has gone wrong during the initramfs load, and the root filesystem hasn't mounted.
This could be due to the slug waiting for a response on the console. On an existing system, the most likely cause of this is due to fsck having found a problem during filesystem check on reboot. As described in the README, the slug can be set to automatically fix any errors found by fsck. The symptoms are similar to the network problem described above, although the boot hangs early on and the main LED remains amber.
To fix this, edit /etc/default/rcS and set FSCKFIX=yes. If your slug is hanging, you can edit this file by mounting the disk on another computer and editing the file from there. Upon reboot the slug may take a long time as it performs a full fsck run, but the disk activity lights will show you that it hasn't hung. After the fsck the slug will finish booting.
Another cause of the initramfs not completing is because the root filesystem device wasn't found. If your system's root filesystem is on RAID or LVM, or you've just upgraded your system, your initramfs might not be quite right. Fiddling with the initramfs isn't particularly hard -- you can mount the system disk on another machine, and it's just a regular initramfs (cpio.gz) format -- but the slug is a bit different to a regular x86 machine, because it doesn't read the initramfs off disk. It reads it from flash. So to get your new and improved initramfs working, you need to write it to flash.
Since your initramfs is toast, you can't simply boot up and run flash-kernel. Instead, you need to either use upslug2 or the NSLU2 equivalent of a rescue disk to re-flash.
The upslug2 option
You need to make a new image containing the new initramfs to send to the device. Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader (thanks to Rod Whitby for pointing that out to me). The easiest way to create a new image is to use the slugimage utility (from the Debian package of the same name) to unpack an existing firmware image (such as the default di-nslu2.bin), replace the initramfs (and maybe the kernel if you're feeling eager), then repack the new image ready for loading into your upgrade-mode slug with upslug2. One point to note is that you need to pass slugimage the -L option (with the location of your APEX image, such as -L apex.bin) so that you don't get the dreaded "Ran out of flash space in <Kernel>" message.
The "rescue disk" option
In this case, you want to download the standard etch firmware from Martin Michlmayr's tarball install, write it to the slug with upslug2, then reboot and write the new initramfs (which you've presumably left on the system's hard drive after modifying it) using flash-kernel.
This may also be due to the RTC not being setup (described below) as Debian etch tries to access the hwclock during system startup (/etc/rcS.d/S11hwclock), which is called before the LED is switched to green.
Fstab Problems
In my case I had added a line to fstab for drive sdb1 on USB port 2. My boot disk is sda1. Symptoms were exactly as shown here, the drive was accessed a few times at slug power-on, but the Disk1 LED never lit up at all. Removed the new line from fstab and it booted up no problem after that.

The slug hangs during reboot (status and ethernet LED green)

If the activity light on the USB hard disk is flashing every few seconds, and the network is not yet up, this could be due to hwclock hanging. Sometimes the internal RTC on the slug does not work. In this case the hwclock init script hangs trying to read the RTC. To fix, remove and replace the battery to reset the RTC. As a temporary fix, can connect the disk to another computer and delete the hwclock script link from /etc/rcS.d.

Long Startup Time (hwclock)

An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with
Changed lines 210-227 from:
  1. This file describes the network interfaces available on your system
  2. and how to activate them. For more information, see interfaces(5).
  3. The loopback network interface

auto lo iface lo inet loopback

  1. The primary network interface

allow-hotplug eth0 iface eth0 inet static

        address 192.168.1.100
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.1.1
        dns-search example.org
to:

$ sudo hwclock --systohc

Changed lines 214-239 from:
Comment out the 'allow-hotplug eth0' and add 'auto eth0' on the line after it. The fixed /etc/network/interfaces file should now look like this
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
auto eth0
iface eth0 inet static
        address 192.168.0.70
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9K21nfs-common 
        dns-search example.org
to:
If this doesn’t work you could try to change the NSLU2 battery.
Deleted lines 216-260:

The slug hangs during reboot (stuck on orange LED, no HD activity.)

As per the nslu2-utils README.Debian, a solid orange status LED means that the system is in the process of loading the initramfs from flash. If the system doesn't come out of this state, then something has gone wrong during the initramfs load, and the root filesystem hasn't mounted.
This could be due to the slug waiting for a response on the console. On an existing system, the most likely cause of this is due to fsck having found a problem during filesystem check on reboot. As described in the README, the slug can be set to automatically fix any errors found by fsck. The symptoms are similar to the network problem described above, although the boot hangs early on and the main LED remains amber.
To fix this, edit /etc/default/rcS and set FSCKFIX=yes. If your slug is hanging, you can edit this file by mounting the disk on another computer and editing the file from there. Upon reboot the slug may take a long time as it performs a full fsck run, but the disk activity lights will show you that it hasn't hung. After the fsck the slug will finish booting.
Another cause of the initramfs not completing is because the root filesystem device wasn't found. If your system's root filesystem is on RAID or LVM, or you've just upgraded your system, your initramfs might not be quite right. Fiddling with the initramfs isn't particularly hard -- you can mount the system disk on another machine, and it's just a regular initramfs (cpio.gz) format -- but the slug is a bit different to a regular x86 machine, because it doesn't read the initramfs off disk. It reads it from flash. So to get your new and improved initramfs working, you need to write it to flash.
Since your initramfs is toast, you can't simply boot up and run flash-kernel. Instead, you need to either use upslug2 or the NSLU2 equivalent of a rescue disk to re-flash.
The upslug2 option
You need to make a new image containing the new initramfs to send to the device. Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader (thanks to Rod Whitby for pointing that out to me). The easiest way to create a new image is to use the slugimage utility (from the Debian package of the same name) to unpack an existing firmware image (such as the default di-nslu2.bin), replace the initramfs (and maybe the kernel if you're feeling eager), then repack the new image ready for loading into your upgrade-mode slug with upslug2. One point to note is that you need to pass slugimage the -L option (with the location of your APEX image, such as -L apex.bin) so that you don't get the dreaded "Ran out of flash space in <Kernel>" message.
The "rescue disk" option
In this case, you want to download the standard etch firmware from Martin Michlmayr's tarball install, write it to the slug with upslug2, then reboot and write the new initramfs (which you've presumably left on the system's hard drive after modifying it) using flash-kernel.
This may also be due to the RTC not being setup (described below) as Debian etch tries to access the hwclock during system startup (/etc/rcS.d/S11hwclock), which is called before the LED is switched to green.
Fstab Problems
In my case I had added a line to fstab for drive sdb1 on USB port 2. My boot disk is sda1. Symptoms were exactly as shown here, the drive was accessed a few times at slug power-on, but the Disk1 LED never lit up at all. Removed the new line from fstab and it booted up no problem after that.

The slug hangs during reboot (status and ethernet LED green)

If the activity light on the USB hard disk is flashing every few seconds, and the network is not yet up, this could be due to hwclock hanging. Sometimes the internal RTC on the slug does not work. In this case the hwclock init script hangs trying to read the RTC. To fix, remove and replace the battery to reset the RTC. As a temporary fix, can connect the disk to another computer and delete the hwclock script link from /etc/rcS.d.

Long Startup Time (hwclock)

An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with
$ sudo hwclock  --systohc
If this doesn’t work you could try to change the NSLU2 battery.

November 22, 2007, at 05:23 PM by Brian Dorling --
Changed lines 252-253 from:

Fstab Problems

to:
Fstab Problems
November 22, 2007, at 05:21 PM by Brian Dorling --
Deleted line 251:

November 22, 2007, at 05:21 PM by Brian Dorling --
Deleted lines 251-252:
In my case I had added a line to fstab for drive sdb1 on USB port 2. My boot disk is sda1. Symptoms were exactly as shown here, the drive was accessed a few times at slug power-on, but the Disk1 LED never lit up at all. Removed the new line from fstab and it booted up no problem after that.
Added lines 253-257:

Fstab Problems

In my case I had added a line to fstab for drive sdb1 on USB port 2. My boot disk is sda1. Symptoms were exactly as shown here, the drive was accessed a few times at slug power-on, but the Disk1 LED never lit up at all. Removed the new line from fstab and it booted up no problem after that.

November 22, 2007, at 05:19 PM by Brian Dorling -- Another reason for hang with no disk activity
Added lines 252-253:
In my case I had added a line to fstab for drive sdb1 on USB port 2. My boot disk is sda1. Symptoms were exactly as shown here, the drive was accessed a few times at slug power-on, but the Disk1 LED never lit up at all. Removed the new line from fstab and it booted up no problem after that.
August 19, 2007, at 09:54 PM by dumfrac --
Changed lines 242-243 from:
!!!!!The upslug2 option
to:
The upslug2 option
Changed lines 246-247 from:
!!!!!The "rescue disk" option
to:
The "rescue disk" option
Added line 261:
Added line 267:
August 19, 2007, at 09:53 PM by dumfrac --
Changed lines 242-243 from:
The upslug2 option
to:
!!!!!The upslug2 option
Changed lines 246-247 from:
The "rescue disk" option
to:
!!!!!The "rescue disk" option
Deleted line 249:
August 19, 2007, at 09:51 PM by dumfrac -- Fix formatting
Changed lines 29-30 from:

Loss of Network Connectivity

to:

Loss of Network Connectivity

Changed lines 106-107 from:

The slug fails to reboot with 2 drives connected

to:

The slug fails to reboot with 2 drives connected

Changed lines 165-166 from:

The slug gets stuck during boot

to:

The slug gets stuck during boot

Changed lines 259-260 from:

Long Startup Time (hwclock)

to:

Long Startup Time (hwclock)

Changed lines 270-271 from:

Connecting Second NSLU2 to Network Hangs Existing NSLU2

to:

Connecting Second NSLU2 to Network Hangs Existing NSLU2

August 19, 2007, at 09:49 PM by dumfrac -- Make item formatting consistent
Changed lines 30-46 from:

Jim Buzbee reported here

Case in point is that I had been successfully running my new Debian Slug for a couple of days, booting and rebooting a number of times. At some point, I noticed that I couldn't reach the slug on the network. I don't remember exactly what I had done last, but to bring it back, I just unplugged and re-plugged the power. As it booted back up, everything looked normal. The LEDs flashed, the disk clicked and all seemed right with the world. But when the boot finished, the NSLU2 was again nowhere to be found on my network.

Update: This occurs when apt attempts to install the "hotplug" package.

And the Fix:

The only way I could see what was happening was to add debug statements to the boot, building my own boot log. This was a tedious process of adding statements, unplugging the drive from my MacBook, plugging it back into my NSLU2, rebooting the NSLU2, putting the disk back on my MacBook, examining the logs, etc. What I finally found is that everything was normal except that the interfaces file, which tells the Debian boot which network interfaces to bring up, was missing the one line that told it to automatically configure the internal Ethernet device. Once I added this line, I rebooted and was back to normal.

From my experience, this was the file was missing an auto eth0 line.

In windows arp -a reported the NSLU2 IP Address with a MAC Address of 00-00-00-00-00-00 and that it was Invalid. I was unable to ping it, and therefore no SSH

If you know what you are doing, you only need to add auto eth0 to /etc/network/interfaces, using vi, nano, or what ever other text editor you are familiar with.

My Old/default Debian Etch RC1 /etc/network/interfaces

to:
Jim Buzbee reported here
Case in point is that I had been successfully running my new Debian Slug for a couple of days, booting and rebooting a number of times. At some point, I noticed that I couldn't reach the slug on the network. I don't remember exactly what I had done last, but to bring it back, I just unplugged and re-plugged the power. As it booted back up, everything looked normal. The LEDs flashed, the disk clicked and all seemed right with the world. But when the boot finished, the NSLU2 was again nowhere to be found on my network.
Update: This occurs when apt attempts to install the "hotplug" package.
And the Fix:
The only way I could see what was happening was to add debug statements to the boot, building my own boot log. This was a tedious process of adding statements, unplugging the drive from my MacBook, plugging it back into my NSLU2, rebooting the NSLU2, putting the disk back on my MacBook, examining the logs, etc. What I finally found is that everything was normal except that the interfaces file, which tells the Debian boot which network interfaces to bring up, was missing the one line that told it to automatically configure the internal Ethernet device. Once I added this line, I rebooted and was back to normal.
From my experience, this was the file was missing an auto eth0 line.
In windows arp -a reported the NSLU2 IP Address with a MAC Address of 00-00-00-00-00-00 and that it was Invalid. I was unable to ping it, and therefore no SSH
If you know what you are doing, you only need to add auto eth0 to /etc/network/interfaces, using vi, nano, or what ever other text editor you are familiar with.
My Old/default Debian Etch RC1 /etc/network/interfaces
Changed line 71 from:

Fixed /etc/network/interfaces

to:
Fixed /etc/network/interfaces
Changed lines 96-99 from:

I also commented #allow-hotplug eth0 out upon suggestion in NSLU2-General IRC Channel.

After changing this, on reboot, I was able to ping during boot, ARP -a was reporting correctly, and when start up was complete - I had SSH. I have reported this on the debian-arm mailing list, as my config was like the top one from installation.

to:
I also commented #allow-hotplug eth0 out upon suggestion in NSLU2-General IRC Channel.
After changing this, on reboot, I was able to ping during boot, ARP -a was reporting correctly, and when start up was complete - I had SSH. I have reported this on the debian-arm mailing list, as my config was like the top one from installation.
Changed lines 108-111 from:

If you connect a second drive after you have installed Debian, for example to store your data files, the order of the drives will be random after rebooting, i.e. the new drive could become /dev/sda with your root filesystem being /dev/sdb. If that happens the slug will fail to boot because it will be looking for its root filesystem on the wrong disk. To recover, boot with only the root drive connected and change your fstab to mount your root drive by UUID by following the procedure outlined below.

List the UUIDs of your drives with the tree (apt-get install tree) command

to:
If you connect a second drive after you have installed Debian, for example to store your data files, the order of the drives will be random after rebooting, i.e. the new drive could become /dev/sda with your root filesystem being /dev/sdb. If that happens the slug will fail to boot because it will be looking for its root filesystem on the wrong disk. To recover, boot with only the root drive connected and change your fstab to mount your root drive by UUID by following the procedure outlined below.
List the UUIDs of your drives with the tree (apt-get install tree) command
Changed lines 131-132 from:

and then modify your fstab by replacing /dev/sda1 (your root partition) with the UUID, e.g.

to:
and then modify your fstab by replacing /dev/sda1 (your root partition) with the UUID, e.g.
Changed lines 146-147 from:

Then update the initramfs:

to:
Then update the initramfs:
Changed lines 154-155 from:

and flash the new initramfs

to:
and flash the new initramfs
Changed lines 167-170 from:

The default configuration will cause the slug to fail to boot if errors are encountered during filesystem check on reboot. This can be the cause of a slug which works fine over a few reboots but then one day hangs during boot with no response to ping or ssh. This problem is described in the README. The simple fix is to set "FSCKFIX=yes" in /etc/default/rcS. Do this on the first boot, or connect the slug drive to another computer to make the change.

The README also suggests changes which cause networking and SSH to start earlier in the init procedure, both of which can help to diagnose problems like this.

to:
The default configuration will cause the slug to fail to boot if errors are encountered during filesystem check on reboot. This can be the cause of a slug which works fine over a few reboots but then one day hangs during boot with no response to ping or ssh. This problem is described in the README. The simple fix is to set "FSCKFIX=yes" in /etc/default/rcS. Do this on the first boot, or connect the slug drive to another computer to make the change.
The README also suggests changes which cause networking and SSH to start earlier in the init procedure, both of which can help to diagnose problems like this.
Changed lines 232-241 from:
As per the nslu2-utils README.Debian, a solid orange status LED means that the system is in the process of loading the initramfs from flash. If the system doesn't come out of this state, then something has gone wrong during the initramfs load, and the root filesystem hasn't mounted.
This could be due to the slug waiting for a response on the console. On an existing system, the most likely cause of this is due to fsck having found a problem during filesystem check on reboot. As described in the README, the slug can be set to automatically fix any errors found by fsck. The symptoms are similar to the network problem described above, although the boot hangs early on and the main LED remains amber.
To fix this, edit /etc/default/rcS and set FSCKFIX=yes. If your slug is hanging, you can edit this file by mounting the disk on another computer and editing the file from there. Upon reboot the slug may take a long time as it performs a full fsck run, but the disk activity lights will show you that it hasn't hung. After the fsck the slug will finish booting.
Another cause of the initramfs not completing is because the root filesystem device wasn't found. If your system's root filesystem is on RAID or LVM, or you've just upgraded your system, your initramfs might not be quite right. Fiddling with the initramfs isn't particularly hard -- you can mount the system disk on another machine, and it's just a regular initramfs (cpio.gz) format -- but the slug is a bit different to a regular x86 machine, because it doesn't read the initramfs off disk. It reads it from flash. So to get your new and improved initramfs working, you need to write it to flash.
Since your initramfs is toast, you can't simply boot up and run flash-kernel. Instead, you need to either use upslug2 or the NSLU2 equivalent of a rescue disk to re-flash.
to:
As per the nslu2-utils README.Debian, a solid orange status LED means that the system is in the process of loading the initramfs from flash. If the system doesn't come out of this state, then something has gone wrong during the initramfs load, and the root filesystem hasn't mounted.
This could be due to the slug waiting for a response on the console. On an existing system, the most likely cause of this is due to fsck having found a problem during filesystem check on reboot. As described in the README, the slug can be set to automatically fix any errors found by fsck. The symptoms are similar to the network problem described above, although the boot hangs early on and the main LED remains amber.
To fix this, edit /etc/default/rcS and set FSCKFIX=yes. If your slug is hanging, you can edit this file by mounting the disk on another computer and editing the file from there. Upon reboot the slug may take a long time as it performs a full fsck run, but the disk activity lights will show you that it hasn't hung. After the fsck the slug will finish booting.
Another cause of the initramfs not completing is because the root filesystem device wasn't found. If your system's root filesystem is on RAID or LVM, or you've just upgraded your system, your initramfs might not be quite right. Fiddling with the initramfs isn't particularly hard -- you can mount the system disk on another machine, and it's just a regular initramfs (cpio.gz) format -- but the slug is a bit different to a regular x86 machine, because it doesn't read the initramfs off disk. It reads it from flash. So to get your new and improved initramfs working, you need to write it to flash.
Since your initramfs is toast, you can't simply boot up and run flash-kernel. Instead, you need to either use upslug2 or the NSLU2 equivalent of a rescue disk to re-flash.
Changed lines 244-245 from:
You need to make a new image containing the new initramfs to send to the device. Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader (thanks to Rod Whitby for pointing that out to me). The easiest way to create a new image is to use the slugimage utility (from the Debian package of the same name) to unpack an existing firmware image (such as the default di-nslu2.bin), replace the initramfs (and maybe the kernel if you're feeling eager), then repack the new image ready for loading into your upgrade-mode slug with upslug2. One point to note is that you need to pass slugimage the -L option (with the location of your APEX image, such as -L apex.bin) so that you don't get the dreaded "Ran out of flash space in <Kernel>" message.
to:
You need to make a new image containing the new initramfs to send to the device. Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader (thanks to Rod Whitby for pointing that out to me). The easiest way to create a new image is to use the slugimage utility (from the Debian package of the same name) to unpack an existing firmware image (such as the default di-nslu2.bin), replace the initramfs (and maybe the kernel if you're feeling eager), then repack the new image ready for loading into your upgrade-mode slug with upslug2. One point to note is that you need to pass slugimage the -L option (with the location of your APEX image, such as -L apex.bin) so that you don't get the dreaded "Ran out of flash space in <Kernel>" message.
Changed lines 248-250 from:
In this case, you want to download the standard etch firmware from Martin Michlmayr's tarball install, write it to the slug with upslug2, then reboot and write the new initramfs (which you've presumably left on the system's hard drive after modifying it) using flash-kernel.
to:
In this case, you want to download the standard etch firmware from Martin Michlmayr's tarball install, write it to the slug with upslug2, then reboot and write the new initramfs (which you've presumably left on the system's hard drive after modifying it) using flash-kernel.
Changed line 261 from:

An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with

to:
An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with
Changed lines 267-268 from:

If this doesn’t work you could try to change the NSLU2 battery.

to:
If this doesn’t work you could try to change the NSLU2 battery.
Changed lines 272-274 from:

Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hangs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk on the NSLU2s. From one of the emails in the thread:

"I fired up my protocol analyzer and monitored both boxes. It appears that the first Slug hangs as soon as the second Slug send an Apple Zone GetNetInfo request. After I disable AT on the Slug and reboot. Both boxes are running fine. I believe people have multiple slug working have the AppleTalk be disabled."

to:
Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hangs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk on the NSLU2s. From one of the emails in the thread:
"I fired up my protocol analyzer and monitored both boxes. It appears that the first Slug hangs as soon as the second Slug send an Apple Zone GetNetInfo request. After I disable AT on the Slug and reboot. Both boxes are running fine. I believe people have multiple slug working have the AppleTalk be disabled."
August 19, 2007, at 09:47 PM by dumfrac -- Fix formatting
Changed lines 48-65 from:
 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo
 iface lo inet loopback

 # The primary network interface
 allow-hotplug eth0
 iface eth0 inet static
         address 192.168.0.70
         netmask 255.255.255.0
         network 192.168.0.0
         broadcast 192.168.0.255
         gateway 192.168.0.1
         # dns-* options are implemented by the resolvconf package, if installed
         dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
         dns-search example.org
to:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 192.168.0.70
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
        dns-search example.org
Changed lines 72-90 from:
 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo
 iface lo inet loopback

 # The primary network interface
 #allow-hotplug eth0
 auto eth0
 iface eth0 inet static
         address 192.168.0.70
         netmask 255.255.255.0
         network 192.168.0.0
         broadcast 192.168.0.255
         gateway 192.168.0.1
         # dns-* options are implemented by the resolvconf package, if installed
         dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
         dns-search example.org
to:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
auto eth0
iface eth0 inet static
        address 192.168.0.70
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
        dns-search example.org
Changed lines 112-125 from:
 $ tree /dev/disk
 /dev/disk
 |-- by-id
 |   |-- usb-ST340014_A_5000000000002886 -> ../../sda
 |   |-- usb-ST340014_A_5000000000002886-part1 -> ../../sda1
 |   |-- usb-ST340014_A_5000000000002886-part2 -> ../../sda2
 |   `-- usb-ST340014_A_5000000000002886-part5 -> ../../sda5
 |-- by-path
 |   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sda
 |   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sda1
 |   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part2 -> ../../sda2
 |   `-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part5 -> ../../sda5
 `-- by-uuid
    `-- 424ba820-8e80-422e-aaeb-b343b4a462f1 -> ../../sda1
to:
$ tree /dev/disk
/dev/disk
|-- by-id
|   |-- usb-[=ST340014=]_A_5000000000002886 -> ../../sda
|   |-- usb-[=ST340014=]_A_5000000000002886-part1 -> ../../sda1
|   |-- usb-[=ST340014=]_A_5000000000002886-part2 -> ../../sda2
|   `-- usb-[=ST340014=]_A_5000000000002886-part5 -> ../../sda5
|-- by-path
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sda
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sda1
|   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part2 -> ../../sda2
|   `-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part5 -> ../../sda5
`-- by-uuid
   `-- 424ba820-8e80-422e-aaeb-b343b4a462f1 -> ../../sda1
Changed lines 133-140 from:
 # /etc/fstab: static file system information.
 #
 # <file system> <mount point>   <type>  <options>       <dump>  <pass>
 proc            /proc           proc    defaults        0       0
 UUID=424ba820-8e80-422e-aaeb-b343b4a462f1       /       ext3 defaults,errors=remount-ro 0       1
 /dev/sda5       none            swap    sw              0       0
 /dev/sda1       /media/usb0     auto    rw,user,noauto  0       0
 /dev/sda5       /media/usb1     auto    rw,user,noauto  0       0
to:
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
UUID=424ba820-8e80-422e-aaeb-b343b4a462f1       /       ext3 defaults,errors=remount-ro 0       1
/dev/sda5       none            swap    sw              0       0
/dev/sda1       /media/usb0     auto    rw,user,noauto  0       0
/dev/sda5       /media/usb1     auto    rw,user,noauto  0       0
Changed lines 148-150 from:
 $ sudo update-initramfs -u
to:
$ sudo update-initramfs -u
Changed lines 156-158 from:
 $ sudo flash-kernel
to:
$ sudo flash-kernel
Changed lines 262-264 from:
 $ sudo hwclock  --systohc
to:
$ sudo hwclock  --systohc
August 19, 2007, at 09:32 PM by dumfrac -- Add items from the FAQ page
Added lines 4-28:

After flashing the installer, I cannot ssh or ping the NSLU2.

Quoting from Martin Michlmayr's installation instructions (with some additional formatting),
"Regardless of which image you intend to use, you should configure your network settings (IP address, DNS, hostname) using the web interface before flashing the debian-installer image in case you do not want to use DHCP. Debian's installer will use those settings to bring up the network.
"Please note that if you use a static IP configuration, you have to specify all information, including netmask, gateway and DNS. If you don't specify all information, debian-installer will not be able to bring up the network and there's currently no way to tell the user that an error has occurred. An incomplete network configuration has so far been the most common reasons for problems with these images, so please make sure you have filled in all values."

Installation fails when the installer starts to format the new ext3 partition. What can I do?

This can happen at 33% for example and the SSH connection closes. The reason is probably that the format process runs out of memory.
Solution: Restart the installer by power cycling the NSLU2. Wait for the beeps, then ssh in as before. Follow the steps up to disk partitioning, and then use the partman manual partitioning mode to do the following:
  1. Delete all partitions the installer has created.
  2. Create a new primary swap partition that is at least 128MB.
  3. Create a new primary EXT3 partition, to be mounted on "/", and set it active.
  4. Write the new settings to the drive and installation should continue normally
Alternate solution: I had that problem with my 500 GB WD My Book. The format process ran out of memory because I wanted to format a 500 GB partition. When I created a smaller 40 GB partition as / mount point it worked well.
It has been reported that creating a swap partition a primary partition, SSH will fail during formatting every time, but if you make it a logical partition it works.
Another possibility: Create the partitions on another Linux machine using (c)fdisk and mk2fs.ext3 and then start the NSLU2 debian installer, choose manual partitioning and set the ext3 partition as root (/).

Added lines 96-100:

After successfully logging in to the Etch RC2 installer, via SSH over the NSLU2's onboard ethernet, the screen is cleared and nothing happens.

This behavior has been observed when logging in from a Debian Sarge machine. Logging in from a Debian Etch machine results in the successful display of the installer.

Changed lines 159-161 from:

Long Startup Time (hwclock)

An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with

to:

I rebooted and now cannot contact the slug

This is probably due the network interface not being properly set up. It could also be due to the FSCK bug or the RTC not working (see below)
To fix the network configuration you will need to edit a file on your USB drive/stick. This will require you to either mount the root partition on another machine or install a serial port http://www.nslu2-linux.org/wiki/HowTo/AddASerialPort. The fix is to edit the '/etc/network/interfaces' file. Make sure to back up the file first.
The original file should look something like this.
Changed lines 168-187 from:
 $ sudo hwclock  --systohc
to:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 192.168.1.100
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.1.1
        dns-search example.org
Changed lines 189-190 from:

If this doesn’t work you could try to change the NSLU2 battery.

to:
Comment out the 'allow-hotplug eth0' and add 'auto eth0' on the line after it. The fixed /etc/network/interfaces file should now look like this
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
auto eth0
iface eth0 inet static
        address 192.168.0.70
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9K21nfs-common 
        dns-search example.org
Added lines 217-254:

The slug hangs during reboot (stuck on orange LED, no HD activity.)

As per the nslu2-utils README.Debian, a solid orange status LED means that the system is in the process of loading the initramfs from flash. If the system doesn't come out of this state, then something has gone wrong during the initramfs load, and the root filesystem hasn't mounted.
This could be due to the slug waiting for a response on the console. On an existing system, the most likely cause of this is due to fsck having found a problem during filesystem check on reboot. As described in the README, the slug can be set to automatically fix any errors found by fsck. The symptoms are similar to the network problem described above, although the boot hangs early on and the main LED remains amber.
To fix this, edit /etc/default/rcS and set FSCKFIX=yes. If your slug is hanging, you can edit this file by mounting the disk on another computer and editing the file from there. Upon reboot the slug may take a long time as it performs a full fsck run, but the disk activity lights will show you that it hasn't hung. After the fsck the slug will finish booting.
Another cause of the initramfs not completing is because the root filesystem device wasn't found. If your system's root filesystem is on RAID or LVM, or you've just upgraded your system, your initramfs might not be quite right. Fiddling with the initramfs isn't particularly hard -- you can mount the system disk on another machine, and it's just a regular initramfs (cpio.gz) format -- but the slug is a bit different to a regular x86 machine, because it doesn't read the initramfs off disk. It reads it from flash. So to get your new and improved initramfs working, you need to write it to flash.
Since your initramfs is toast, you can't simply boot up and run flash-kernel. Instead, you need to either use upslug2 or the NSLU2 equivalent of a rescue disk to re-flash.
The upslug2 option
You need to make a new image containing the new initramfs to send to the device. Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader (thanks to Rod Whitby for pointing that out to me). The easiest way to create a new image is to use the slugimage utility (from the Debian package of the same name) to unpack an existing firmware image (such as the default di-nslu2.bin), replace the initramfs (and maybe the kernel if you're feeling eager), then repack the new image ready for loading into your upgrade-mode slug with upslug2. One point to note is that you need to pass slugimage the -L option (with the location of your APEX image, such as -L apex.bin) so that you don't get the dreaded "Ran out of flash space in <Kernel>" message.
The "rescue disk" option
In this case, you want to download the standard etch firmware from Martin Michlmayr's tarball install, write it to the slug with upslug2, then reboot and write the new initramfs (which you've presumably left on the system's hard drive after modifying it) using flash-kernel.
This may also be due to the RTC not being setup (described below) as Debian etch tries to access the hwclock during system startup (/etc/rcS.d/S11hwclock), which is called before the LED is switched to green.

The slug hangs during reboot (status and ethernet LED green)

If the activity light on the USB hard disk is flashing every few seconds, and the network is not yet up, this could be due to hwclock hanging. Sometimes the internal RTC on the slug does not work. In this case the hwclock init script hangs trying to read the RTC. To fix, remove and replace the battery to reset the RTC. As a temporary fix, can connect the disk to another computer and delete the hwclock script link from /etc/rcS.d.

Long Startup Time (hwclock)

An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with

 $ sudo hwclock  --systohc

If this doesn’t work you could try to change the NSLU2 battery.


August 19, 2007, at 09:18 PM by dumfrac -- Add item seperators
Added line 3:

Added line 70:

Added line 121:

Added line 128:

Added line 137:

August 19, 2007, at 09:11 PM by dumfrac -- Fix spelling errors
Changed lines 18-19 from:

If you know what you are doing, you only need to add auto eth0 to /etc/network/interfaces, using vi, Nano, or what ever other text editor you are fimiliar with.

to:

If you know what you are doing, you only need to add auto eth0 to /etc/network/interfaces, using vi, nano, or what ever other text editor you are familiar with.

Changed lines 121-122 from:

The default configuration will cause the slug to fail to boot if errors are encountered during filesystem check on reboot. This can be the cause of a slug which works fine over a few reboots but then one day hangs during boot with no response to ping or ssh. This problem is described in the README. The simple fix is to set "FSCKFIX=yes" in /etc/default/rcS. Do this on thefirst boot, or connect the slug drive to another computer to make the change.

to:

The default configuration will cause the slug to fail to boot if errors are encountered during filesystem check on reboot. This can be the cause of a slug which works fine over a few reboots but then one day hangs during boot with no response to ping or ssh. This problem is described in the README. The simple fix is to set "FSCKFIX=yes" in /etc/default/rcS. Do this on the first boot, or connect the slug drive to another computer to make the change.

Changed lines 135-136 from:

Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hangs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk on the NSLU2s?. From one of the emails in the thread:

to:

Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hangs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk on the NSLU2s. From one of the emails in the thread:

August 19, 2007, at 09:07 PM by dumfrac -- Suppress some WikiLinks
Changed lines 125-126 from:

Long startup time hwclock

If you experience whey long start up time (20 min) this may be be a indication that the hwclock cant be set. Try to set the hwclock in your command promt with

to:

Long Startup Time (hwclock)

An excessively long start up time (20 min) may be an indication that the hwclock cant be set. Try to set the hwclock in your command prompt with

Changed lines 131-132 from:

If this doesn’t work you could try to change the Nslu Bios battery.

to:

If this doesn’t work you could try to change the NSLU2 battery.

Changed lines 135-137 from:

Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hanfs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk? on the NSLU2s?. From one of the emails in the thread:

"I fired up my protocol analyzer and monitored both boxes. It appears that the first Slug hangs as soon as the second Slug send an Apple Zone GetNetInfo? request. After I disable AT on the Slug and reboot. Both boxes are running fine. I believe people have multiple slug working have the AppleTalk? be disabled."

to:

Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hangs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk on the NSLU2s?. From one of the emails in the thread:

"I fired up my protocol analyzer and monitored both boxes. It appears that the first Slug hangs as soon as the second Slug send an Apple Zone GetNetInfo request. After I disable AT on the Slug and reboot. Both boxes are running fine. I believe people have multiple slug working have the AppleTalk be disabled."

August 19, 2007, at 09:03 PM by dumfrac -- Add tip about AppleTalk and Debian/NSLU2
Added lines 131-136:

Connecting Second NSLU2 to Network Hangs Existing NSLU2

Some people have reported that connecting a second NSLU2 to the same subnet as another NSLU2 hanfs the existing NSLU2. The solution, according to this thread, is to disable AppleTalk? on the NSLU2s?. From one of the emails in the thread:

"I fired up my protocol analyzer and monitored both boxes. It appears that the first Slug hangs as soon as the second Slug send an Apple Zone GetNetInfo? request. After I disable AT on the Slug and reboot. Both boxes are running fine. I believe people have multiple slug working have the AppleTalk? be disabled."

August 19, 2007, at 08:46 PM by dumfrac -- Create page, and copy information from the Debian/NSLU2 home page
Added lines 1-130:

Troubleshooting Debian on the NSLU2

Loss of Network Connectivity

Jim Buzbee reported here

Case in point is that I had been successfully running my new Debian Slug for a couple of days, booting and rebooting a number of times. At some point, I noticed that I couldn't reach the slug on the network. I don't remember exactly what I had done last, but to bring it back, I just unplugged and re-plugged the power. As it booted back up, everything looked normal. The LEDs flashed, the disk clicked and all seemed right with the world. But when the boot finished, the NSLU2 was again nowhere to be found on my network.

Update: This occurs when apt attempts to install the "hotplug" package.

And the Fix:

The only way I could see what was happening was to add debug statements to the boot, building my own boot log. This was a tedious process of adding statements, unplugging the drive from my MacBook, plugging it back into my NSLU2, rebooting the NSLU2, putting the disk back on my MacBook, examining the logs, etc. What I finally found is that everything was normal except that the interfaces file, which tells the Debian boot which network interfaces to bring up, was missing the one line that told it to automatically configure the internal Ethernet device. Once I added this line, I rebooted and was back to normal.

From my experience, this was the file was missing an auto eth0 line.

In windows arp -a reported the NSLU2 IP Address with a MAC Address of 00-00-00-00-00-00 and that it was Invalid. I was unable to ping it, and therefore no SSH

If you know what you are doing, you only need to add auto eth0 to /etc/network/interfaces, using vi, Nano, or what ever other text editor you are fimiliar with.

My Old/default Debian Etch RC1 /etc/network/interfaces

 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo
 iface lo inet loopback

 # The primary network interface
 allow-hotplug eth0
 iface eth0 inet static
         address 192.168.0.70
         netmask 255.255.255.0
         network 192.168.0.0
         broadcast 192.168.0.255
         gateway 192.168.0.1
         # dns-* options are implemented by the resolvconf package, if installed
         dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
         dns-search example.org

Fixed /etc/network/interfaces

 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo
 iface lo inet loopback

 # The primary network interface
 #allow-hotplug eth0
 auto eth0
 iface eth0 inet static
         address 192.168.0.70
         netmask 255.255.255.0
         network 192.168.0.0
         broadcast 192.168.0.255
         gateway 192.168.0.1
         # dns-* options are implemented by the resolvconf package, if installed
         dns-nameservers 212.159.13.49 212.159.13.50 212.159.6.9
         dns-search example.org

I also commented #allow-hotplug eth0 out upon suggestion in NSLU2-General IRC Channel.

After changing this, on reboot, I was able to ping during boot, ARP -a was reporting correctly, and when start up was complete - I had SSH. I have reported this on the debian-arm mailing list, as my config was like the top one from installation.

The slug fails to reboot with 2 drives connected

If you connect a second drive after you have installed Debian, for example to store your data files, the order of the drives will be random after rebooting, i.e. the new drive could become /dev/sda with your root filesystem being /dev/sdb. If that happens the slug will fail to boot because it will be looking for its root filesystem on the wrong disk. To recover, boot with only the root drive connected and change your fstab to mount your root drive by UUID by following the procedure outlined below.

List the UUIDs of your drives with the tree (apt-get install tree) command

 $ tree /dev/disk
 /dev/disk
 |-- by-id
 |   |-- usb-ST340014_A_5000000000002886 -> ../../sda
 |   |-- usb-ST340014_A_5000000000002886-part1 -> ../../sda1
 |   |-- usb-ST340014_A_5000000000002886-part2 -> ../../sda2
 |   `-- usb-ST340014_A_5000000000002886-part5 -> ../../sda5
 |-- by-path
 |   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sda
 |   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sda1
 |   |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part2 -> ../../sda2
 |   `-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part5 -> ../../sda5
 `-- by-uuid
    `-- 424ba820-8e80-422e-aaeb-b343b4a462f1 -> ../../sda1

and then modify your fstab by replacing /dev/sda1 (your root partition) with the UUID, e.g.

 # /etc/fstab: static file system information.
 #
 # <file system> <mount point>   <type>  <options>       <dump>  <pass>
 proc            /proc           proc    defaults        0       0
 UUID=424ba820-8e80-422e-aaeb-b343b4a462f1       /       ext3 defaults,errors=remount-ro 0       1
 /dev/sda5       none            swap    sw              0       0
 /dev/sda1       /media/usb0     auto    rw,user,noauto  0       0
 /dev/sda5       /media/usb1     auto    rw,user,noauto  0       0

Then update the initramfs:

 $ sudo update-initramfs -u

and flash the new initramfs

 $ sudo flash-kernel

You may want to make a copy of your existing flash before this last step in case something goes wrong.

The slug gets stuck during boot

The default configuration will cause the slug to fail to boot if errors are encountered during filesystem check on reboot. This can be the cause of a slug which works fine over a few reboots but then one day hangs during boot with no response to ping or ssh. This problem is described in the README. The simple fix is to set "FSCKFIX=yes" in /etc/default/rcS. Do this on thefirst boot, or connect the slug drive to another computer to make the change.

The README also suggests changes which cause networking and SSH to start earlier in the init procedure, both of which can help to diagnose problems like this.

Long startup time hwclock

If you experience whey long start up time (20 min) this may be be a indication that the hwclock cant be set. Try to set the hwclock in your command promt with

 $ sudo hwclock  --systohc

If this doesn’t work you could try to change the Nslu Bios battery.

Page last modified on January 18, 2014, at 10:59 PM