Thursday 18 August 2011

DSL to SliTaz

Having got my Omnibook firewall up and running rather sweetly it was time to return to my Omnibook NAS project...

Returning to my DSL install on another OB800, I fired up Samba for a few tests and discovered that the venerable code that is DSL has a 2GB file limit. Since I store a collection of Linux install DVD images this is rather a limitation. As DSL seems to have stalled I went looking for a successor and found one of its offspring, SliTaz.

I started up DSL and pulled down the SliTaz ISO file. With great presence of mind I had configured DSL with root and swap partitions the same size (at 512MB). This gave me somewhere to put SliTaz without blowing away DSL. I could thus shut down the swap partition, replacing it with a swapfile, and then mark it as Linux and format with ext2.

There is a manual install for SliTaz here. One problem...there is no lzma or xz for DSL so I can't unpack the root filesystem (which has a .gz extension but won't, of course, unpack with gzip). No matter, I ftp'ed the file to another machine, uncompressed the rootfs cpio archive and then pulled it back. Finally, I mount the DSL partition and add Slitaz to the Grub menu there since DSL installed Grub already.

Reboot...and Grub hangs trying to load the SliTaz kernel. Hmmmm. Grub 0.91 from DSL is rather ancient and does have a few known problems - maybe I need a newer one. The obvious thing to do is to boot SliTaz from floppies and then use the SliTaz version of Grub. Kernel loads fine from floppies and starts to boot and then panics.That might be a duff floppy image so try a new set but get the same results. Might be lack of RAM, try the low ram images but get the same results.

Ok, scratch SliTaz for this project. Pity.

Friday 12 August 2011

IPCop Tweaking

Doing a few throughput tests on IPCop on the OB800 I noticed it was working very hard. A bit of poking around revealed that tweaking could the hard drive settings made a lot of difference. Switching on 32-bit access and unmasking interrupts during operation improved network throughput and dropped CPU load at the same time. I guess logging onto CF was taking long enough to affect the network.

Anyway, the net result is to add the following to /etc/rc.d/rc.local

/sbin/hdparm -u1 -c1 /dev/hda

This also works for DSL, though the file to modify is /opt/bootlocal.sh