firefly on DebianEtchLE/NSLU2

[mas]

Ok, I dared it. Following this excellent manual

http://www.cyrius.com/debian/nslu2/install.html

I managed to install Debian Etch (testing) in the little endian version on my NSLU. I will describe it here if other ppl intend to do it also.
There were no real glitches during the install, which went remarkably smooth thanks to the RC1 installer from

http://www.slug-firmware.net/d-dls.php

that does include some of the non-GPLed code for the eth0 interface of the NSLU.
The only things to note were that it took quite some time – a bit over 3h on a de-underclocked NSLU – where one couldnt walk away as it kept asking some questions from time to time. Also one must take the special installer noted above, as the generic debian installer wouldnt support the ethernet – quite essential.

After all was installed I first kicked out a lot of rubbish from the standard install, like a lot of appletalk deamons etc. I know why I generally am no debian fan, but there was no way I setup a gentoo on such a slow device and the debian had a nice installer. I used aptitude for this crap pruning, e.g.

aptitude purge netatalk

I basically took a “ps faux” and purged all daemons I didnt like, basically keeping samba and the system daemons alive. Needs also some patience as aptitude isnt fast on the NSLU but it works nicely, even in the grafical mode, albeit even slower then.

Then I went about to install the mt-daapd version provided in the repository. Thats a 0.2.4+r137 version, which did work after some editing of the config. Basic functions work, but the transcoding uses ffmpeg and is dead slow on the slug, causing rebuffering deathmatches where the big endian nightly package went smooth. As there would also be no updates on this for a while I decided to compile the latest nightly, which turned out to be quite a bit of a task as even after the install of the 0.2.4 version there were quite some packets missing. I put em together by trial and error trying to make the latest tarball and putting in all missing packets.

First I needed to aptitude install the newest g++/cpp and linux-headers-2.6.18-3-ixp4xx in order to get a ./configure to run without errors. Man, one would assume debian packages as standard a sane and complete compile environment, but apparently not so on the NSLU arm.

Then there turned out to be a lot of stuff to apt-install to get the nightly to compile. Hope I remember all:

avahi-daemon
avahi-dev
zeroconf
tagtool
flac
flac-dev
libavahi-client-dev
libavahi-compat-howl-dev
libflac-dev
libid3tag0-dev
libogg-dev
liboggflac-dev
libsqlite3-dev
libtagc0-dev
libvorbis-dev
howl-xml
curl

As I didnt move em in 1 by 1 but in chunks of 2-3 I cannot be sure all are needed but thats what I ended up installing (plus a lot of extra that these packages autoinstalled as dependencies) before the compiles went through.

I did then first manually compile (./configure && make install)

libvorbisidec-cvs-20050221
vorbis-tools-1.0 (with Rons tremor patch posted somewhere in this forum)

and then the mt-daapd-svn-1489.
I used basically ALL –enables that were present except:

-mem-debug
-ffmpeg (anyway too slow)
-gdbm (we use sqlite)
-howl (gives a compile error and aborts)
-mdns (we use avahi)

All compiled without errors then and it took about 1h to compile all this.

The good:
– The nightly works as it did on the big endian.
– Transcoding is faster now, though still not as fast as on the big endian packages (why?) it seems.

The bad:
– something is still strangely wrong on the transcoding. I had it transcode an ogg and it does it without giving an error. But the sound it plays back is noise! Not white noise but centered to one side of the spectrum as the roku analyzer shows. I assume something in the endian-ness is screwed up in the tremor patch colliding with the LE?
Will have a look later what that can be. Sigh, compiling that beast isnt really that easy. Still looking into it and hints welcome. Though all that doesnt involve transcoding works fine at least.

---

Something else I wanted to do

---

loopback encryption which now works thanks to Debian feed

What I did I was aptitude installing

loop-aes-modules-2.6.18-3-ixp4xx
loop-aes-utils

and then I made a keyfile to prevent using nasty long passwords (20 char passwords otherwise required – idiotic)

umask 077
head -c 2925 /dev/urandom | uuencode -m – | head -n 66 | tail -n 65 | gpg –symmetric -a >/etc/fskey.gpg

[Note the urandom, the random of the NSLU is too darn slow]
followed by

dd if=/dev/zero of=/path/to/container bs=1M count=sizeInMs
losetup -e AES128 -K /etc/fskey.gpg /dev/loop0 /path/to/container
mke2fs -m 0 /dev/loop0

Viola, now a small tweak in /etc/fstab

/path/to/container /mountpoint ext2 defaults,noauto,noatime,loop,encryption=AES128,gpgkey=/etc/fskey.gpg 0 0

and one can mount this encrypted volume like normal ones. Its slower than an unencrypted volume, but not as bad as one may assume. Seems to be around 1 MB/sec, which isnt too much slower than the 2-4 MB the slugs do without encryption. Definitly still quite ok. Works surprisingly well and using this debian LE version its easy to setup. With unslung there was no way in hell due to old kernel and lack of loopback tools.

[mas]

The bad:
– something is still strangely wrong on the transcoding. I had it transcode an ogg and it does it without giving an error. But the sound it plays back is noise! Not white noise but centered to one side of the spectrum as the roku analyzer shows. I assume something in the endian-ness is screwed up in the tremor patch colliding with the LE?
Will have a look later what that can be. Sigh, compiling that beast isnt really that easy. Still looking into it and hints welcome. Though all that doesnt involve transcoding works fine at least.

Solved that now. Ron! Your oggdec patch has a hardcoded byteswap in it so the patch will only work for big endian system. You even removed the –endian option from it! Grm. Nasty trap.

After I removed the byteswap code the thing works now fine also on LittleEndian Debian systems. Theres no upload or file attach function on this board so can only describe it: Apply the patch from Ron and then edit oggdec.c, search for byteswap (theres a comment) and remove all that belongs to it.

Performance of the NSLU is good enough to read an ogg from an AES loopbacked partition, transcode and stream it without rebuffering. Even a little bit of reserve left. i can browse and DL/UL small stuff via samba while doing it. Also ssh logins and some simple shell commands dont break the stream. A bigger compile job did cause rebuffering however. As does a “mv” of a tree into the cryptoloop. Not surprisingly hehe.

Measured netto speed over WLAN 802.11g was
ca. 2 MB/sec into an unencryted share
ca. 1.1 MB/sec into an encrypted share (AES128).

Not too bad I would say. At some point I gotta try if the NSLU manages to stream two .oggs with transcoding at the same time.

[rpedde]

@mas wrote:

Solved that now. Ron! Your oggdec patch has a hardcoded byteswap in it so the patch will only work for big endian system. You even removed the –endian option from it! Grm. Nasty trap.

Well, yeah! It’s an arm-specific package after all. 🙂 I did put a comment in there, though. It was really just a hack, it wasn’t every really meant to be part of unslung proper, just that other people were asking for it so I committed what I was using.

probably should put a endian-test in there.

Also, netatalk etc isn’t part of the base install — you must have picked something in the tasksel screen. If you are more of a gentoo person, you want to skip all that crap. You get a much more minimal installation that way. Tasksel is the suck.

— Ron

[mas]

Hehe yeah. I am a noob with debian.
I would always prefer gentoo on a fast laptop or desktop. Their emerge system is usually working better and more reliable than all packaging systems I know.
But it must be a fast machine – on a NSLU that would be hell painful slow even for a Stage 2 install. And crosscompiling is also sometimes tricky so debian it is here. Was already a weekend task for this debian. Gentoo on that slug would have been a 3 week task. Nah. No way.

[rpedde]

@mas wrote:

Was already a weekend task for this debian. Gentoo on that slug would have been a 3 week task. Nah. No way.

🙂

With an empty tasksel, it only takes around 45 minutes to install, iirc. Went much faster than I figured it would.

You are right though, it’s sucks as a compile machine. It’s the only linuxthreads machine I have though, so I end up using it to debug linuxthreads stuff. Man, does that suck.

– Ron

[Author]

Posts