Matthew Johnson: Passwordless Encrypted Root in Debian
If, like me, you wanted both an encrypted root filesystem and
some form of bootsplash you may have discovered that this is tricky.
You need to enter the decryption passphrase on the terminal which
means exiting the bootsplash.
I decided it must be possible to use a USB token with the key on it
rather than a passphrase to decrypt the drive and while this
seems supported upstream, it is not supported out of the box on Debian.
This is a short howto explaining my solution.
Pre-requisites
You will need a USB hard disk and a computer using Debian with an
encrypted root filesystem. I am assuming that you are using a stock
kernel with an initramfs image and have a luks encrypted LVM containing
the root filesystem. You will have to change some of the details below
to match your specific system.
In the examples below
/dev/hda5
is the encrypted partition
and
/dev/sda2
is the partition on the USB disk holding the key.
Setting up the key
First we need to generate a random key and put it on the disk. To save
having to mount things in the initramfs, I chose to use a partition at
the end of the USB flash disk. This means repartitioning and reformatting
your USB disk. I recommend allocating the last cylinder in fdisk to
primary partition 2.
Once you have the second, small partition (you are only going to use
1k, so as small a partition as possible) you can put a key on it.
This is as simple as
dd if=/dev/urandom of=/dev/sda2
bs=1M
.
Adding the key to the luks partition
Next, you need to add your new key as able to decrypt the partition.
Luks allows several keys to be able to unlock the partition. The real
key is decrypted under each of the user keys or passphrases and stored
in a key slot' in the partition. To add your key type:
touch /tmp/keyfile chmod 600 /tmp/keyfile dd if=/dev/sda2 bs=1k count=1 of=/tmp/keyfile cryptsetup luksAddKey /dev/hda5 /tmp/keyfile wipe /tmp/keyfileNote the careful handling of the temporary key file (luksKeyAdd won't read from stdin, whereas luksOpen will), I recommend storing it on a ramdisk and you should certainly use wipe rather than rm if you don't. Once you have added your USB key you could remove the passphrase from the key list with luksDelKey, but if for any reason you lose the USB hdd you will be unable to decrypt the partition; I recommend leaving both keys available. Booting automatically In order to boot using the USB key we need to provide a couple of helper scripts in order for the initramfs to work. We also need to set some parameters on the kernel command line. In Debian these scripts can be added to the initramfs by putting them in /etc/initramfs-tools/. The first script is a helper script used when building the initramfs. This writes a second script into the initramfs itself which takes the partition as a parameter and prints the key on stdout. This should be written to /etc/initramfs-tools/hooks/cryptkey (executable) and contain:
#!/bin/sh -- PREREQ="" prereqs() echo "$PREREQ" case $1 in prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions cat > $ DESTDIR /bin/loadkeyThe second script runs immediately before the cryptsetup script in the initramfs and ensures that the USB disk is available. This will cause the boot sequence to block until the USB disk is inserted and the device nodes created by udev. It can be provided directly in /etc/initramfs-tools/scripts/local-top/00ensureusb (executable) and should contain:
#!/bin/sh --
PREREQ=""
prereqs()
echo "$PREREQ"
case $1 in
prereqs)
prereqs
exit 0
;;
esac
if ! grep cryptopts /proc/cmdline >/dev/null; then return; fi
. /scripts/functions
log_begin_msg "Waiting for USB to become available..."
modprobe usbcore
modprobe uhci_hcd
modprobe ehci_hcd
modprobe usb_storage
while [ ! -b /dev/sda2 ]; do
sleep 1
done
log_end_msg
exit 0
The cryptsetup script itself reads configuration from the kernel command
line. Here you can give it a script which will read the key and the
source for the key to read. Edit your grub or lilo config and append
the following to the kernel command line:
cryptopts=keyscript=/bin/loadkey,key=/dev/sda2,source=/dev/hda5,target=hda5_crypt,lvm=hecate-root
You will obviously have to change the name of your lvm root partition
(volumegroup-logicalvolume). I recommend having two entries in the
boot menu, one with the cryptopts and one without to allow easy
decryption using the passphrase instead.
Conclusion
That should be everything. Boot your computer and inset the usb hdd.
When the boot process passes decryption you can remove it again. You
may have to replug it if you boot with it inserted to start with.
rebuildd-job stats says that 20 % of the archive is now built in less than 24h, seems fast, cool.
Bad point is that I'm building and trashing logs into /dev/null because I've no QA idea to implement right now.
Atheros has released a 
This week I ought to have posted about how Gunnar and I met 
A few days ago I installed the 
A curiously interesting thread has sprung up on the Xorg mailing list recently regarding the lack of bandwidth the developers might have for accepting patches. Bernardo Innocenti, who hacks on OLPC stuff amongst other things, wants to get some patches reviewed for acceptance, but there aren't enough people around with the time and inclination to review and accept his work.
He did a quick and dirty analysis of Xorg LoC vs Linux LoC, to give a "X codebase is roughly 1/2 Linux codebase" (which surprised me, actually, I'd always thought it was larger) and then a similarly rough analysis that suggests that Xorg has roughly 1/20th of the developer base.
To some extent Bernardo's metrics are arguable, but the basic facts are that Linux gets the lions share of the developers. Is this what we should expect? Is this a healthy way for the free and open source software community to support the development of what I personally would like to see as the future desktop base?
Linux does a fantastic job as an OS, right now. It's been doing it for years, really, but we still need to get behind some of the differential further up the stack. And all credit to those stalwarts of X development who are shouldering more than their fair share of the burden.
So if you were looking for an open source software project where you can be appreciated, don't overlook X.
These are all just 'first-builds' so problems could well lie ahead but I have now built a set of cross built packages for Emdebian (ARM) that edos-debcheck says is installable for a basic GPE installation. Only one package remains as a problem - gpe-filemanager builds fine but the current dependencies of libgnomevfs mean that gconf is required which doesn't give an option to disable ldap which is something I would rather do without. Certainly, existing GPE installations do without ldap but that could just be because these tend to use older versions of the particular libraries.
Information is currently not completely tripled checked but I would
advice all readers of this blog entry to think twice before upgrading
their Etch-based samba file servers to 3.0.24-etch6 (and maybe also 3.0.24-etch7). Same for 3.0.14a-sarge8 (and -sarge9).
According to 
Of all of the 
Dear vim-ers, yes I know my git.vim ftplugin was kind of a dirty hack, and that it didn't worked that well.
Since a few days, 
