Nagilum’s Cookie Jar

Hmm, on a second try the compilation worked without a hitch – strange.
Anyway there were still some minor things to smooth out. For one the NVidia driver would not compile, thankfully that problem was already solved here. In addition the VMWare Workstation modules failed to compile which can be solved following the instructions from here. The Highpoint driver compiled without a hitch *yay*.

While compiling 2.6.33 on Debian Etch I stumbled over this error:
The UTS Release version in include/linux/version.h
“”
does not match current version:
“2.6.33″
Please correct this.

and so we shall!
We edit include/linux/version.h and add this:
#define UTS_RELEASE “2.6.33″
Replace “2.6.33″ with whatever is given as current version.
That’s it. make-kpkg should now run through.

After upgrading to FreeBSD 8 and doing a “portupgrade -fa” until it bailed out I removed all the old files & libraries (cd /usr/src && make delete-old) and then started hunting down broken ports. For that purpose I wrote a small Perl script (see http://www.nagilum.net/checkports/index.html) but there was one error I could not get around even after rebuilding all dependencies (I used “make all-depends-list|xargs -n1 -J % make -C % describe|cut -d\| -f1|xargs” to get the list):

cc -o x264 x264.o matroska.o muxers.o libx264.a -L/usr/local/lib -L/usr/local/lib -lm -pthread -lgpac -s -fprofile-generate
/usr/lib/libgcov.a(_gcov.o)(.text+0x1175): In function `gcov_exit':
: undefined reference to `__stack_chk_fail_local'
gmake[1]: *** [x264] Error 1
gmake[1]: Leaving directory `/var/tmp/export/ports/multimedia/x264/work/x264-snapshot-20081218-2245'
gmake: *** [fprofiled] Error 2
*** Error code 1
Stop in /export/ports/multimedia/x264.
*** Error code 1

Turns out that this is part of the stack protector and to link this properly you have to link with “-fstack-protector”. So to fix the multimedia/x264 port run “make extract” and edit “work/x264-snapshot-20081218-2245/Makefile” and look for:

x264$(EXE): $(OBJCLI) libx264.a
$(CC) -o $@ $+ $(LDFLAGS)

and change it to:

x264$(EXE): $(OBJCLI) libx264.a
$(CC) -o $@ $+ $(LDFLAGS) -fstack-protector

After that the port should compile and install as usual.
To build ffmpeg with x264 I did “LDFLAGS=-fstack-protector make“.

I just noticed that Highpoint has put out a new release of their driver that not only fixes the compilation errors on 2.6.30/31 but also adds support for 48-bit address for ide passthrough.
So my patch is now basically obsolete.

I just completed the upgrade from FreeBSD 7 to 8 on this cakebox.
The most noteable changes for me were (quoting from UPDATING):

The sio(4) driver has been removed from the i386 and amd64 kernel configuration files. This means uart(4) is now the default serial port driver on those platforms as well.
When using the serial port as a boot console, be sure to update /boot/device.hints and /etc/ttys before booting the new kernel. If you forget to do so, you can still manually specify the hints at the loader prompt:

set hint.uart.0.at=”isa”
set hint.uart.0.port=”0×3F8″
set hint.uart.0.flags=”0×10″
set hint.uart.0.irq=”4″
boot -s

So basically replace sio by uart in your kernel config and do a “mergemaster -Ui” before rebooting.
I also needed “COMPAT_FREEBSD7″ or my kernel wouldn’t even compile and I removed “ADAPTIVE_GIANT” which is gone in 8. Likewise “ugen” is also no longer needed in 8.
Another change affects ppp, the “ppp” driver is now called “sppp”. I also looked for the kernel SLIP driver but couldn’t find it anymore so “sl” had to go too.
That are all the changes I had to do in order to get my cakebox compile and run again on FreeBSD 8. I think I’ll probably do a little bit more tweaking (like adding “P1003_1B_SEMAPHORES”) when I find a reason to do so.

I just upgraded my Debian5 workstation to 2.6.31. While doing so I stumbled over this:

cc -m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE lguest.c -o lguest
lguest.c:21:25: error: sys/eventfd.h: No such file or directory
lguest.c: In function ‘create_thread’:
lguest.c:1021: warning: implicit declaration of function ‘eventfd’
make: *** [lguest] Error 1

This is apparenty due to the old libc-dev package that Lenny comes with. Since libc isn’t exactly a good candidate for a selective upgrade I helped myself with simply editing Documentation/lguest/Makefile and changing:

all: lguest

to

all:

So lguest wont be build anymore. After that make-kpkg binary-arch worked as usual.
I’m also happy to report that my rr232x-linux patch still works on 2.6.31.

Just as 2.6.31 was released I found some time to update the current highpoint driver (rr232x-linux-src-v1.9-090407-1135.tar.gz) to compile on 2.6.30.
So here is the patch. I don’t expect any problems as the changes were minor.
Update: I just tested the patch with 2.6.30.6 and 2.6.31 with my RocketRaid 2320 and both work fine for me.

After playing around a bit with FreeBSD and geom_uzip on the small laptop I found it somewhat dissatisfiyng because every other time the Laptop would fail during boot when accessing the uzip mountpoint with the process being stuck in state ‘UFS’. After seing Xubuntu 9.04 being released and hearing about the minimum requirements in FLOSS Weekly I decided to give it a try. I had an older version installed on my AMD K6 about two years ago but it took ages to boot so I wasn’t too happy with it. Anyway I decided the new version might be worth a try and downloaded the ISO. Booting took a while but considering it booted from CD it wasn’t so bad. So I made a backup of the installed FreeBSD and installed it.
Xubuntu from harddisk was really nice, the XFCE4 desktop feels pretty much like Gnome with only a fraction of the memory footprint. So I decided to make a similar to the uzip FreeBSD setup using Xubuntu.
After installing enough software to fill up the 5GB disk I made a small script to create a squashfs:

mksquashfs /bin /lib /sbin /opt /usr /selinux /srv \
/cakebox/obxe3.sqfs -read-queue 16 -write-queue 32 -noappend -check_data -nolzma \
 -e /lib/init/rw/* -e /lib/modules/*/volatile/* -e /lib/modules/*/volatile/.mounted

“/cakebox” is a NFS mountpoint with enough space. After the image is created I boot from the install CD, mount the harddisk and the NFS share and remove the files from the harddisk and copy the image from the NFS share to the harddisk.
To have this image mounted from the initrd I found that putting the following script into /etc/initramfs-tools/scripts/local-bottom does the trick (I called it “unionfs_root”, remember to do a chmod +x on it!):

#!/bin/sh

PREREQS=""

prereqs() { echo "$PREREQS"; }

case "$1" in
   prereqs)
   prereqs
   exit 0
   ;;
esac

printf "Mounting SquashFS."
mount -o remount,rw,noatime ${rootmnt}
printf "."
mount -t squashfs -o loop,ro ${rootmnt}/obxe3.sqfs ${rootmnt}/.sqfs
printf "."
mount -t unionfs -o dirs=${rootmnt}=rw:${rootmnt}/.sqfs=ro,delete=whiteout unionfs ${rootmnt}
#touch ${rootmnt}/fastboot
printf "done\n"

To make this work you also need to have the unionfs and squashfs modules in the initrd. This can be accomplished by adding:

squashfs
unionfs

to /etc/initramfs-tools/modules and after update-initramfs -u the new initrd will mount the previously created squashfs.
So what does it look like now? See this:

$ df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             4.4G  3.0G  1.2G  73% /

and:

$ du -sxh /
8.4G      /

Nice!

This is just a small follow-up on the last post. I did some more testing with different filesystem options.
I used the following script:


#!/usr/local/bin/bash
set -ex
idprio 10 -$$

SIZE=7G
IMAGE=/export/test
SOURCE=/uzip
MNT=/mnt
# we need to set the fragment size because UFS1 will switch to space opt. otherwise
COMMON_OPTS="-b 65536 -n -o time"
UZIP=/export/test.uzip
LOG=bench.txt

function mk_image ( ) {
rm -f $IMAGE
truncate -s $SIZE $IMAGE && \
export MDDEV="/dev/"$(mdconfig -a -t vnode -f $IMAGE)
}

function uzip_image ( ) {
mount $MDDEV $MNT
ssync -v 3 -f $SOURCE -t $MNT -F
# tar -C $SOURCE -cf - .|buffer -S 1M -m 10M|tar -C $MNT -xf - && \
sync
df -k $MNT |tee -a $LOG
umount $MNT || umount -f $MNT
mdconfig -d -u $(basename $MDDEV)
mkuzip -o $UZIP -s 65536 $IMAGE
ls -la $UZIP|tee -a $LOG
rm $UZIP
}

echo "UFS1" |tee -a $LOG
mk_image
newfs -O 1 $COMMON_OPTS $MDDEV
uzip_image

echo "UFS1+softupdates" |tee -a $LOG
mk_image
newfs -O 1 -U $COMMON_OPTS $MDDEV
uzip_image

echo "UFS2" |tee -a $LOG
mk_image
newfs -O 2 $COMMON_OPTS $MDDEV
uzip_image

echo "UFS2+softupdates" |tee -a $LOG
mk_image
newfs -O 2 -U $COMMON_OPTS $MDDEV
uzip_image

So here the result, filesizes depending on the used filesystem:

What I found interesting:

• When creating a filesystem with less than 8% reserved space, the optimization will invariantly switch to space. So I removed the “-m 0″ option.
• The created filesystems have a different amounts of available space depending on the UFS type. 7055MB for UFS1 and 6943MB for UFS2. As can be seen from the results above this has no negative impact for the final image size for UFS2

The used space on the filesystem after copying the testset is virtually identical (1024-blocks/Used/Avail):

Some time ago I inherited an old Laptop, an OmniBook XE3GC. I had installed FreeBSD on it quite some time ago and tried connecting using different means. First I tried a USB2USB cable. This somewhat worked but unfortunately it was too unreliable. After some time the connection would drop and I could not re-establish the connection without rebooting both ends. Next I tried a parallel port laplink cable. Unfortunately the parallel port on the laptop is not interrupt driven making this non-functional. So I reverted to the last resort: SLIP while this worked ok when connecting to my K6 gateway it wouldn’t work so well with the new Soekris 5501 that replaced the K6 recently. The problem here was that the connection would only work on the baudrate set in the console although conlock was not enabled.
Since I recently moved all my stuff to the living room I had a spare WLAN stick and right away stuck that one in the laptops USB port. Although the laptop only has USB1.1 it would still be much better than SLIP’s 12kb/s max. Now I could do some real work and install all the good stuff. Unfortunately I hit another wall soon. The laptop only has a 5GB harddisk so was soon running out of space. So I started with the usualy space saving measures. I had already NFS mounted my gateway for /usr/src and /usr/ports. So cleaned up the ports builddirectory and deleted /usr/obj. Then I reverted to make all portbuild happen on the NFS share. Nonetheless it became clear that in order to be able to actually do anything with the machine after install one would need some space to work with. So I looked at compression options. The first thing I tried was a fusefs-gunzip but that didn’t work so I searched some more and found geom_uzip. This is somewhat similar to squashfs but works a little different. Instead of providing a complete filesystem it takes a filesystem image and compresses it block by block. The blocksize can be specified, default is 16k I chose 64k for better compression ratio. Here is the script I use for setting up the empty image:

#!/bin/sh
# create empty diskimage and mount it
SIZE=7G
FILE=/home/usr_local
rm $FILE && \
truncate -s $SIZE $FILE && \
MDDEV=$(mdconfig -a -t vnode -f $FILE)
if [ "$MDDEV" ]
then newfs -b 65536 -m 0 -n -U -o time /dev/$MDDEV
mount /dev/$MDDEV /mnt
fi

The truncate command creates a sparse file. This is much faster than doing a “dd if=/dev/zero of=/home/usr_local” as the 7GB of zeroes aren’t actually written. (that way you can also create multi petabyte volumes requiring only small amounts of diskspace and impress your friends with it) Then I turn the file into a blockdevice (similar to losetup under Linux) and create a filesystem on it. I chose the same blocksize as I will use later on for uzip, select no reserved space as the volume will be readonly anyways, for the same reason I also forego snapshots (-n) and I set the optimization to time. This will cause the filesystem not to use “tails”, that is if a datablock doesn’t fill the 64k completely use the remaining space for other files (by default 2k chunks are used). The idea is that the zeroes will be compressed “away” anyways so I rather have the speed advantage (and zeroes decompress really really fast). I used the default UFS2 because I don’t know any better and I enabled softupdates (-U) because write performance sucked without it. Maybe I’ll do some comparison later on to find out the optimal combination of UFS1/2 with or without softupdates. I could imagine that softupdates writes some kind of journal data that impacts compression ratio and UFS2 adds some additional structures to increase failure resilience.
Then I replicate the content of /usr/local from the laptop into /mnt. After that I run:

#!/bin/sh
# umount imagefile and create uzip file
FILE=/home/usr_local
UZIP=/export/usr_local.uzip
MDDEV=$(mdconfig -l -v|grep $FILE|awk '{print $1}')
MNT=$(mount|grep $MDDEV|awk '{print $3}')
umount $MNT &&\
mdconfig -d -u $MDDEV
mkuzip -v -o $UZIP -s 65536 $FILE


After that I can delete /usr/local on the laptop and put the following in /etc/rc.conf:

mdconfig_md0="-t vnode -f /usr_local.uzip"

and this in /etc/fstab:

/dev/md0.uzip /uzip ufs ro,noauto 0 0

This causes rc to automatically activate /dev/md0, load geom_uzip and that automatically creates /dev/md0.uzip which is then in turn mounted. It took me a while to figure out that FreeBSD will invariantly attempt a “mount /dev/md0.uzip” after creating it and that I just have to put in the above fstab entry to make it work.
After that the only remaining piece was to unionfs mount /uzip under the existing, writeable /usr/local. But that again was a single line in the fstab:

/uzip /usr/local unionfs rw,noatime,below,copymode=transparent 0 0

Since this is a laptop and I don’t want each access to a file cause a write so I also added the noatime option to this and the “/” filesystem.
And as a last comment I thought on how to replicate /usr/local as quick a possible and this what I came up with:

tar -C /usr/local -cf - .|buffer -S 1M -m 5M|lzop|buffer|nc gateway 1234

and on the gateway:

nc -l 1234|buffer -m 5M|lzop -d|tar -C /mnt -xvf -

The buffer commands are there to balance out speed variances caused by different filesizes. Many small files will cause tar to slow down compared to large files when looking at the bytes per second throughput. This applies to both ends. An additional buffer after lzop compression to ensure saturation of the the link even when we encounter lots of well compressable data.