Upgrading your Slug

By Silas Brown

If you installed Debian on an NSLU2 device ("Slug") following Kapil Hari Paranjape's instructions in LG #138, then you might now wish to upgrade from etch (old stable) to lenny (current stable). Debian itself contains instructions for doing this, which you can follow if you like (but see the note below about the locales package causing a crash). If you use the NSLU2's watchdog driver, then I recommend first booting without it, otherwise the general unresponsiveness caused by the upgrade can cause the watchdog to reboot when the system is unbootable, and you'll have to restore the filesystem from backup. However, following the standard Debian dist-upgrade will still leave you running lenny using the arm architecture. Debian's arm port is now considered deprecated, and in future releases will be replaced by the armel port, which has (among other things) significant speed improvements in floating-point emulation just by changing the handling of the ARM's registers, stack frames, etc.

If you want to move to armel at the same time as you're upgrading to lenny, this normally requires re-installing from scratch (since ArchTakeover is not implemented, yet.) However, there is also a way to do it incrementally. Martin Michlmayr has produced an unpacked version of the lenny armel install, which can be downloaded and untarred into a subdirectory of your etch system. Etch will not be able to chroot into this, but at least it lets you compare key configuration files and make needed changes from the comfort of a working system.

Moving Files and Setting up Configuration

The first thing you need to do is copy fstab from the old /etc to the new one; you'll also need resolv.conf, hostname, hosts, mailname, timezone, and adjtime. You might also like to copy apt/sources.list (change it to "lenny" or "stable", if it says "etch"), and the following files if you have customised them: inittab, inetd.conf, logrotate.conf. For the password files (i.e., passwd, shadow, group, and gshadow - you don't have to worry about any backup versions ending in -), it is best not to simply copy them from etch, because that can delete the new accounts that various lenny base packages use. Instead, you can use diff -u etc/passwd /etc/passwd | grep \+, pick out the real user accounts, and merge them in (and do the same with group, shadow, gshadow). To review all changes that the new distribution will make, do something like diff -ur /etc etc|less and read through it, looking for what you want to restore. (However, note that some packages won't be there yet; try searching the list for "Only in /etc" to see which new config files you might want to copy across in preparation for them.) Note that lenny uses rsyslog.conf instead of syslog.conf.

After you are happy with /etc, please remember to copy across the crontabs in /var/spool/cron. (I've lost count of the number of times I as a user have had to re-instate my crontab because some admin forgot to copy the crontabs during an upgrade). Also, take a list of the useful packages you've installed that you want to re-install on the new system. Finally, remove (rm -r) the following top-level directories from the new system (make sure you're in the new system, not in /!): media, home, root, tmp, lost+found, proc, mnt, sys, srv. Removing these means they will not overwrite the corresponding top-level directories from the old system during the next step.

The new system now needs to be copied onto the old one (with the old directories being kept as backups), and the NSLU2's firmware needs updating to the lenny version (also downloadable from the above-mentioned site) using upslug2 from a desktop, as documented. The directories are best copied over from another system: halt the NSLU2, mount its disk in another system, and do

cd /new-system
for D in * ; do
  mv /old-system/$D /old-system/$D.old && mv $D /old-system
done

substituting /new-system and /old-system appropriately. (This assumes you have room to keep the *.old top-level directories on the same partition; modify it, if not.)

Partitioning Complications

Because Martin Michlmayr's downloadable firmware image was (at the time of writing) generated from a system that assumes /dev/sda2 is the root device, you should make sure that your root filesystem is on the disk's second partition. If it is on the first, then you can move and/or shrink it slightly with gparted, create a small additional partition before it, and use fdisk to correct the order if necessary. (The fdisk commands you need are x, f, r, w, and q.) Then, put only that disk back into the NSLU2, and switch on. If all goes well, you should now boot into the new distribution. Then, you can start installing packages and re-compiling local programs, and do apt-get update, apt-get upgrade and apt-get dist-upgrade. You might still need to run dpkg-reconfigure tzdata, even though it should show your correct timezone as the default choice.

Of course, if you have 2 disks connected at boot time, then there's only a 50/50 chance it will choose the correct one to boot from. (If it doesn't, disconnect and reconnect the power and try again, or boot with only one disk connected.) If you have set up your /etc/fstab to boot from UUIDs, then this will take effect when you install your own kernel (which should happen automatically as you upgrade the lenny packages). You can get a partition's UUID using dumpe2fs /dev/sda2 | grep UUID, and use UUID=(this number) in place of /dev/sda2 or whatever in fstab, as long as it's not a swap partition. One trick for getting swap to work is to ensure that it is on a partition number that is valid on only one disk, and then list all the disks having swap partitions with this number. The correct disk will be used, and the others will cause harmless errors during boot.

You may experience further complications on account of the differences between ext2 and ext3 filesystems: In Debian Etch, if you wanted to reduce the wear on a flash disk, you could tell /etc/fstab to mount the partition as ext2, even though the installer formatted it as ext3. Mounting as ext2 simply leaves out writing the ext3 crash-recovery journal. Apparently, however, the newer kernel in lenny cannot really mount an ext3 partition as ext2 (it tells you it's doing so, but it doesn't, see Ubuntu bug 251999), and moreover, if your fstab says it's ext2, the update-initramfs utility's omitting the ext3 module from the kernel will result in an unbootable system when you try to upgrade to lenny's latest kernel (but you can still boot Martin's kernel, which expects ext3). Conversely, if your filesystem really is ext2, you won't be able to boot Martin's kernel. Therefore, you have to:

• Make sure the filesystem is ext3 before booting Martin's kernel
• Make sure the filesystem is ext2 before booting your own kernel, if you have ext2 in your /etc/fstab

To convert an ext3 partition back to ext2, connect the disk to a separate computer and, if for example the partition is sdb2 on that computer, make sure it is unmounted and do

e2fsck -fy /dev/sdb2
tune2fs -O ^has_journal /dev/sdb2
e2fsck -fy /dev/sdb2

and to convert it back to ext3,

tune2fs -O has_journal /dev/sdb2

Martin has filed Debian bug #519800 to suggest that initramfs support both versions of extfs no matter what fstab says, which should mean (when fixed) you don't have to run tune2fs just to get a bootable system. You might still want to do it anyway to work around the other bug (kernel updating the journal even when ext2 is requested).

Locales Package

When doing an apt-get upgrade or dist-upgrade, make sure the locales package is not installed, or at least that you are not generating any locales with it. That package's new version requires too much RAM to generate the locales; the 32MB NSLU2 cannot cope, and may crash. If you need any locales other than C and POSIX, then you can get them from another Linux system by copying the appropriate subdirectories of /usr/lib/locale (and possibly /usr/share/i18n if you want locale -m to work, too).

Sound

If you have fitted a "3D Sound" USB dongle, you might find that, in the new distribution, the audio becomes choppy and/or echoey. This seems to be on account of an inappropriate default choice of algorithms in the ALSA system, and it can be fixed by creating an /etc/asound.conf with the following contents:

pcm.converter {
  type plug
  slave {
    pcm "hw:0,0"
    rate 48000
    channels 2
    format S16_LE
  }
}
pcm.!default converter

Note that this configuration deliberately bypasses the mixer, so only one sound can play at once. Mixing sounds in real time on an embedded system like this is likely to be more trouble than it's worth.

Unfortunately, it no longer seems possible to drive the soundcard itself at lower sample rates and channels, which is a pity because having to up-convert any lower-samplerate audio (such as the mono 22.05kHz audio generated by eSpeak) not only wastes bandwidth on the USB bus but also seems to slightly reduce the sound quality, but the difference is not immense.

If you are playing MP3s, then you also have the option of getting madplay (rather than the ALSA system) to do the resampling, and this could theoretically be better because madplay is aware of the original MP3 stream, but I for one can't hear the difference.

madplay file.mp3  -A -9  -R 48000 -S  -o wav:-|aplay -q -D hw:0,0

On lenny (unlike on etch), recording works, too, and it can be done with arecord -D hw:0,0 -f S16_LE -r 24000 test.wav, but the quality is not likely to be good. (Mine had a whine in the background.)

Everything Finished

If you have done this, then you should, with luck, have an NSLU2 running lenny on the armel architecture, which has significantly faster floating-point emulation (although it's not as fast as a real floating-point processor), and perhaps more important has better long-term support. (You won't be stuck when arm is dropped in the release after lenny.)

The *.old top-level directories created above can be removed when you are sure you no longer need to retrieve anything from them, or you can rename them to "old/bin", "old/usr", etc., and have a chroot environment in old/. (The new kernel can run an old system in chroot, but not vice-versa.)

Talkback: Discuss this article with The Answer Gang

---

Silas Brown is a legally blind computer scientist based in Cambridge UK. He has been using heavily-customised versions of Debian Linux since 1999.