view · edit · print · history

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 ( See this thread for more information.
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 to the DHCP server while the NSLU2 was running (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. 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 (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).

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. Or possibly after removing the default dhcp3-client and switching over to a static inet config.
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
        # dns-* options are implemented by the resolvconf package, if installed
        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
        # dns-* options are implemented by the resolvconf package, if installed
        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
|-- 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 (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.

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...

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(approve sites) 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(approve sites) 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
Page last modified on January 18, 2014, at 02:59 PM