New Debian on NSLU2 documentation available

I wrote several new guides about Debian on the Linksys NSLU2 this weekend. The new guides cover the following topics:

• Troubleshooting: common problems and their solutions
• Internals about the boot process of Debian on the NSLU2
• Modifying a NSLU2 firmware image
• Cloning a NSLU2
• Migration guide: how to move your Debian installation from your NSLU2 to a SheevaPlug.

You can find this documentation at my Debian on NSLU2 site.

Required installer modules installed automatically on NSLU2 now

One thing that's annoying about the Debian installer on the NSLU2, as Joey Hess pointed out a few months ago when he reinstalled his NSLU2, is that you have to manually select some installer modules. The reason for this is that the NSLU2 only has 32 MB of RAM and thus Debian installer runs in lowmem mode in which less functionality is enabled by default. As a result of this, you have to select partman-auto, partman-ext3 and usb-storage-modules from a list of additional installer modules to load so the installer will recognize your USB disk, offer guided partitioning and format the disk with ext3.

When Joey submitted his installation report, Frans Pop suggested that we could put a list of installer modules we want to have installed automatically in /var/cache/anna/include. I finally got around to playing around with this yesterday and while this specific solution won't work on lowmem systems we can use anna-install to automatically queue installer modules for installation. Since anna-install works, I put some functionality into the installer today to automatically load required installer modules on the Linksys NSLU2 and on Cobalt machines.

This change is good for users because they don't have to select some modules during the installation. I'm a little bit worried that existing users of the installer on the NSLU2 will be confused when they don't see the modules in the list anymore, but I'll update the documentation accordingly.

More robust oldsys-preseed uploaded

To follow-up on my recent posting about oldsys-preseed: I uploaded a new version of netcfg yesterday that can be told via preseeding not to use a gateway. I also uploaded a new version of oldsys-preseed that will properly handle static IP configs without a netmask or gateway. Additionally, oldsys-preseed will now use DHCP when the static IP config is incomplete (i.e. when either the IP address or DNS are missing). This makes oldsys-preseed much more robust and will hopefully get rid of many problems users ran into with etch.

Cannot connect to debian-installer via SSH: mystery solved?

I finally found the time today to dig into oldsys-preseed and what I found wasn't pleasant. In fact, I may have solved the mystery why some people trying to install Debian on their NSLU2 cannot connect to the installer via SSH.

oldsys-preseed is used on certain NAS devices to read the network configuration from the original firmware and these values are used to bring up SSH in debian-installer. If you used DHCP in the original firmware to obtain an IP address, debian-installer will do the same. If you have a static IP config, debian-installer will use it. In theory, it's all pretty simple, but users often run into troubles when a static IP config is used (as is the case on the NSLU2). While you only need an IP address, netmask and gateway to bring up SSH (and then you could configure the rest, such as DNS and hostname), debian-installer expects everything at the same time. I've seen many cases where users couldn't connect to the installer because they forgot to configure their DNS in the original firmware or some other values they didn't think were important.

Anyway, right now oldsys-preseed will use a static configuration if the firmware is configured this way even if it's clear that netcfg won't like this configuration because of missing values. The IP address and DNS are always required, but the netmask and gateway can be figured out automatically. I wanted to add a sanity check that would choose DHCP in case the IP address or DNS were not specified.

While working on this sanity check, I noticed two things: First, the "empty" value oldsys-preseed preseeds when there's no netmask or gateway is not accepted by netcfg and leads to an error message (which the user cannot see because SSH is not up yet). I'm pretty sure I tested this scenario when I wrote oldsys-preseed but it clearly doesn't work today and I don't see how it could ever have worked. This is pretty significant because having an empty gateway is a valid configuration (if hopefully not too common). Second, it seems that it's impossible to create a preseed file that tells netcfg that no gateway should be used. If you preseed an empty value, netcfg will simple use .1 as the gateway.

I've fixed the first problem and proposed a patch to put in a special case to allow preseeding of no gateway. The sanity check that chooses DHCP when the network configuration is incomplete is also there now.

New behaviour for oldsys-preseed regarding default settings

I've just changed the behaviour of oldsys-preseed in the case when a static IP address is set in the configuration of the device that is the default setting from the vendor. In the past, oldsys-preseed would try to be smart in this case and do DHCP in the assumption that the users never configured the static IP address themselves and might not want to have that setting. However, Mike (mwester) convinced me that doing DHCP when the configuration clearly says to use a static IP is a bad idea. Apparently quite a few users got confused by the old behaviour of oldsys-preseed. The new behaviour exists as of version 2.0 of oldsys-preseed which will be in rc1 of debian-installer for lenny. This change affects the Linksys NSLU2 and Thecus N2100.

NSLU2 Debian installer for lenny beta 2

The Debian installer team has published the second beta release of the installer for lenny (what will become Debian 5.0). I repacked the image for the Linksys NSLU2 with the proprietary IXP4xx microcode so Ethernet will work.

The installer is now available in two flavours for the ARM architecture: arm is the old ARM port whereas armel is the new ARM port using the EABI which offers better support for floating point and other features. Both the arm and armel architectures will be supported for lenny but the old arm port will be dropped after the release of lenny. At this point, I therefore recommend that people use armel for new installations.

The beta 2 installer image for NSLU2 can be found on slug-firmware.net.

The NSLU2 causing trouble recently...

We've had two serious bugs on the NSLU2 recently that both caused the system not too boot anymore. The first one was related to initramfs-tools. Kevin Price reported that after upgrading to initramfs-tools 0.92 the system would hang during boot waiting for the root filesystem. When I booted my NSLU2 and looked at the output, I noticed that no root device was set. When I mentioned this to maks, the maintainer of the initramfs-tools package, he immediately knew what was wrong and uploaded a fix. On the NSLU2, the boot loader doesn't pass a root device to the kernel so we set one in the initramfs itself. The code that loads this config variable is not used by many devices so nobody noticed that this got broken in 0.92 until the package moved to testing.

The second problem, reported on Saturday by Paul Collins and diagnosed today with some help from Kevin Price is also related to the strange way the NSLU2 boots. The NSLU2 has 6 MB available for the ramdisk but due to a bug in APEX (the second stage loader used on the NSLU2 by Debian) only 4 MB are actually used. When you write a ramdisk that is larger than 4 MB but smaller than 6 MB, flash-kernel will happily write the full image, but APEX will only tell the kernel about the first 4 MB. As it turns out, everything works fine on arm with 2.6.25, but on armel some additional SCSI modules are enabled that result in the ramdisk becoming too large. The short term solution is to disable these modules, but really APEX should finally be fixed (patches have been available for quite a while thanks to Gordon Farquharson). Fortunately 2.6.25 hasn't moved to testing yet and this problem only occurs on armel, so few people were impacted.

The nice thing about the NSLU2 is that you can write a new flash image via the network, so you can flash a good image in case your machine no longer boots. Nevertheless, we have to make sure such serious bugs don't occur in the future or that they are at least caught very early. Special thanks go to testers like Kevin Price.

Installer finally working again on Linksys NSLU2

The release release team of Debian released 4.0r2 today which fixes the bug that kept the installer from working on ARM based systems, such as the Linksys NSLU2. This means that installations are finally possible again. I've updated my installation instructions accordingly.

I've also updated the tar ball used for the manual installation to 4.0r2 but I doubt many people are interested in this method now that the installer is working again.

Tips on reducing memory and running Linux on a flash device

David Härdeman has contributed two really valuable guides to my Debian on NSLU2 site that will be of great interest to many NSLU2 users:

• The first guide is for people running Linux on a flash device, such as a USB flash stick. Since flash only supports a limited number of writes, it is important to reduce the wear and tear on the underlying flash device. David's guide gives some practical advice of how to achieve this.
• The second guide gives a few tips and tricks that can be used to reduce the amount of RAM a system uses. This is particularly interesting to NSLU2 users since 32 MB of RAM is not a lot.

These guides mention Debian but most of the advice applies to other NSLU2 firmware flavours and to Linux in general.

NSLU2 tar ball for Debian 4.0r1

I updated the tar ball for the manual Debian/NSLU2 installation to Debian 4.0r1 (including the new 2.6.18-5 kernel) today. The proprietary NPE microcode from Intel is now included in the tar ball since the code no longer has a click-through license.