This post is the happy conclusion of one heck of a weekend. I worked extremely hard all weekend trying dozens of options for buildig a media box. With no exceptions, they sucked. GeexBox was terrible. Mythbuntu was okay but MythTV was terrible. Piren sucked.
Ultimately though – I decided to try XBMC – it was awesome, but the live version was a bit limited.

So I installed it inside Ubuntu Jaunty. It is gorgeous, and I even have my WIImote working as a mouse to control it.

So here is the setup and the steps involved:
I built it out of the old parts of my computer from before it’s last upgrade, it’s an AMD Sempron single core machine with 2Gb of RAM and a 300gb hard-drive, about 200Gb filled with video files.
The name of this new box: andysandimas.
All I added to it was a WIFI card and an NVidia video card (for TV-out support).
I used my LCD secondary monitor from my main desktop to do the initial setups with however – since it is just not fun to do real work on a TV-screen.

So I started by just installing plain old Ubuntu from the Jaunty live CD – then I installed the wiimote software as per this document, and XBMC as per this one.
All pretty straight forward. I did however uninstall NetworkManager and install WICD instead because having to type my password to unlock the keystore to connect to my WPA network everytime I booted was just… not on for this case.
Then I wrote two little scripts in my home directory. The first is to get the wiimote running at bootup, it just requires a quick press on the scan button (note for those having trouble like I did: the new wiimotes don’t go discoverable by pressing 1 and 2 but instead has a little red button next to the battery-casing to enable USB).
Here is the content of wiimote.sh

#!/bin/bash
wminput -d -r -w -c ir_ptr 00:1F:C5:7B:81:D8 &

This tells the wiimote input system to run as a daemon, reconnect if it loses signal, and wait indefinitely for a connection – nice for having it there all the time. Though I do need to rescan from the wiimote after reboots.
The second script is for starting XBMC, this is my launchxbmc.sh script:
#!/bin/bash
export XBMC_HOME=/usr/share/xbmc
xbmc -fs


Both scripts are set up to be run from startup applications. I also enabled the ssh server so I can get in remotely to do tweaks.
One seriously annoying thing I encountered with this now near perfect setup is Ubuntu’s notifications for updates: which would pop up when it found them – then de-fullscreen XBMC – despite me trying to watch a movie.
So I set that to autodownload them, and only check every two weeks.

Basically there is still a full ubuntu desktop running behind XBMC – easy to reach by just exiting the application, and this means adding things like xmame later to really expand the box’s usefullness is remarkably easy.

Johan Hartzenberg put in a request to add ZFS-FUSE support in Kongoni. This is a rather complex topic so I felt I should write a post to clarify the status on this request and the degree to which it can be done.
I won’t bother with an explanation of what ZFS is, if you don’t know – chances are you are not the right target audience for this post anyway. Just file it under “AJ was geeking out again”

Now the first catch is this: ZFS is under SUN’s CDDL license, the same license used for OpenOffice.org. This license is FSF approved (so in adding it we don’t risk breaking our FSF compliance rules) but it is not unfortunately compatible with the GPL. This means that at this stage there is no reasonable expectation that we’ll see ZFS support in the kernel. The only Linux support for it currently available is as a fuse plugin.

This plugin is a direct port of the ZFS driver as used in OpenSolaris and the current version is compatible up to the latest ZFS in OS10 so it’s all good in that regard. However that means one small catch: there is no feasible way to put the root filesystem on a fuse-filesystem unless you use a (very clever) initrd which would probably need to be custom-built for the specific setup.
So the short answer: for the foreseeable future, you will not be able to use a ZFS root filesystem. You may be able to put almost all your system on a zpool however – but this may well require some clever post-install hacking on your part. If you really want to you could even clone your normal root into a zpool, have a bootscript mount it and chroot – so you only use the non-ZFS root for getting the ZFS root accessed.
This is completely doable but will require a bit of hand-hacking, the closest I will come to trying to support it is to post a howto if somebody writes it.

So what support do we have ? Well for starters we now have a port for zfs-fuse in the ports tree. This can be installed quite easily. The only real catch is this: it has a daemon and like all daemons in slackware likes, execution at boot-time is controlled by the executable bit, and this is unset by default. So if you want to make zfs available at boottime, you need to: chmod +x /etc/rc.d/rc.zfs-fuse

Currently it’s just about the last thing on the bootlist that will get started, edit /etc/rc.d/rc.M if you want to move it earlier (but make sure it’s after rc.fuse itself).

So that means you can manually add it to kongoni and at least create and access zpools. What about support in live ? Well I would like to add support for zfs into Nietzsce, gparted has the ability to work with it (apparently) so you should be able to create zpools during the installation phase.
The next phase gets tricker, zfs does not use the same kind of mounting that other filesystems use – instead the mountpoints are set up right inside the filesystem itself. More-over, during the installation your mountpoint needs to be under /newroot – if you wish to install to it, but it cannot be there post-install – it has to move one level up.

I don’t have a feasable way to deal with this yet – so my feeling is that adding it to the live-cd at all is a bad move. I will experiment with it a bit and I may change my mind about this, especially if the ZFS experts are willing to put in some effort to help me work out the quirks so the installer can correctly mount them – install – and then move them, or whatever methodology works) – but from my point of view, having the port is a great thing, trying to add support to set up zpools during install – especially since we cannot use it for / is just not currently doable.
I will happily accept a patch to the installer code to make it work, but I don’t feel up to doing it myself.

If anybody does feel like giving it a shot, e-mail me and I’ll send you the instructions for working on the installer and testing your code and once it works, send me the patch you created – I’ll include it if I can.