TrueCrypt 5.1 for the EeePC


George Foot <>


TrueCrypt is a portable volume encryption system, which encrypts volume (disk partition) data and embeds it either within other files, or on raw disk partitions.

I've built the latest version (5.1) for the EeePC's default Xandros OS, and compiled here some notes on how to do this yourself (if you want to).

On my own EeePC, I've encrypted the entire user partition, which seems to work really well - see below for more details.

Binary download

This is a dynamic executable, but it doesn't appear to depend upon anything that's not present on a stock EeePC. See below for instructions on compiling it yourself.

Compiling from source

It wasn't too hard to build TrueCrypt on the EeePC, so with a little self-confidence you should be able to build your own binary if you want to. I already had gcc and make ready to go. I had to install pkg-config from the Debian repositories, and libfuse-dev. I used the 5.1a TrueCrypt sources, with wxWidgets 2.8.7. Then I just followed the instructions for installing without GUI support, as I didn't want to install libgtk-dev.

I used a tarball of fuse at one point, but stopped doing that when I realised that the EeePC already has fuse libraries installed as standard. So don't do that - just get the dev package to go with the end-user package you've already got.

General command-line usage

The TrueCrypt documentation is a bit geared up to GUI use, but the command line is really easy to use. Running:


with no parameters will give you a full option list, if you need it, and:

truecrypt -h

will give more details and some examples.

Whole disk encryption with unionfs

Probably what you want to do is encrypt the user partition but not the system partition, as the system partition's contents are fixed and standard. This could give some speed advantages over whole disk encryption, as application files and shared libraries will tend to load from the unencrypted system partition anyway.

I'll try to get a vaguely automated installer together sometime, but in the meantime I've written some fairly detailed notes below, and include the following files for reference:

My broad approach to this was as follows:


I wanted to have the system prompt for a password on bootup, mounting the volume and continuing as normal after that.

Beyond that, it would be nice if the regular F9 menu options work roughly as they already do, so things like user partition disk scans are still possible.

Additional options would also be handy, e.g. remove encryption, change password, etc. I also wanted to allow a guest login, if you don't know the password, which would operate in the so-called "read only" mode, using a ramdisk as the user partition to allow system use without saving settings.

General process

Initially, I decided not to bother with adding further menu options to the boot menu, and also didn't bother with guest login. (I still haven't implemented these things.)

The truecrypt binary needs to be accessible at boot time, which means it should either be on the initrd, or on the system partition. Since we need to modify the system partition anyway, we might as well just put it in /sbin on there - then it will always be available at runtime too.

The truecrypt binary has various direct and indirect prerequisites, which you need to set up:

Shared libraries
It needs some shared libraries from /lib and /usr/lib, so I symlinked /lib and /usr from /mnt-system into the root of the ramdisk, which didn't have either directory before. It's basically free, and just means we can run arbitrary executables from the system partition.
/usr/bin/fusermount executable
This is a helper executable, part of the fuse system which allows userland apps like truecrypt to provide filesystem functionality to the kernel. I could have added /usr/bin to the path, as I'd already symlinked /usr, but instead I symlinked fusermount into /bin, which is already in the path.
/tmp directory
This didn't exist, so I created it.
Device nodes - /dev/fuse, /dev/loop0
TrueCrypt needs /dev/fuse for talking to fuse, and a loop device per encrypted filesystem you mount - we only need one at this stage.
fuse.ko kernel module
Needs to be loaded.
insmod /mnt-system/lib/modules/$VERSION/kernel/drivers/fs/fuse/fuse.ko

Hopefully I didn't forget anything there... it's hard to remember, as it took a few iterations to identify all these things.

I had planned to replace the Xandros scan and format scripts with new versions that use TrueCrypt. So far I didn't bother doing the scan script, but I used a new format script to set the volume up initially - this works well.

I can't see an easy way to get truecrypt to encrypt the data in-place, so you need to either start from scratch with a blank user partition, or restore a backup. Raw partition backups probably won't work so well here because the available space after encryption will probably be slightly less. Your best bet is probably to shrink the filesystem first, with resize2fs, then unshrink it after restoring it. The backup will still get truncated, but the missing data will be irrelevant.

Alternatively, use a tar backup - this is what I actually did. The main difficulty here is that the rescue console doesn't work very well - actually it works OK, but there are a lot of steps involved now to mount the user partition in a rescue console, so it's not as trivial as it once was.

So far I've avoided changing /boot/grub/menu.lst, but I'll come to that soon. I badly want a decent way to get a rescue console with all the truecrypt setup already done, even if the partition itself isn't mounted yet.


Whole disk encryption without unionfs

If you've removed unionfs, whole disk encryption is a bit harder. The initrd and basic bootloader files need to be stored unencrypted. You have two main options.

Two partitions

In the olden days, people used to keep a small boot partition at the start of their disk, containing the bootloader files - this was mounted over /boot after booting, and the root partition was the second one on the disk. This was mostly to keep the bootloader files near the start of the disk, as bootloaders and BIOSes used to suck quite a bit, but the same theory applies here. Having an unencrypted boot partition containing grub's files, including menu.lst and the initrd, should allow you to fully encrypt the actual root partition. Your initrd's init script needs to mount this using truecrypt, and switch_root to it; you can then mount the boot partition on /boot, if you like. In the end, it's very much like the unionfs setup, but without the union itself. The lack of easy access to maintenance tools might be an issue - any rescue console is going to be limited until you get the encrypted root partition mounted up, and that process becomes a lot harder now.

One unencrypted partition, and a big file containing the root filesystem

The other option that springs to mind is storing your root filesystem in a container file on the unencrypted filesystem. The theory is much the same, it's just a little more awkward to set up - except that it doesn't require any repartitioning. I don't know whether there are any speed differences between file containers and device volumes in TrueCrypt. I think this could just start to bring the frustrations of unionfs back to haunt you, without the union itslf.