Since I’ve installed Gentoo, I haven’t had access to my other drives. One of them is an NTFS-formatted WD Raptor, and the other is a generic Seagate 300GB drive that contains my documents, pictures and Communist propaganda inside a TrueCrypt partition. Getting the Raptor to work was fairly simple (as far as Gentoo goes) – I added the entry to my /etc/fstab file and then manually mounted the partition:
/dev/sdb1 /mnt/raptor ntfs-3g noatime 0 0
The TrueCrypt drive proved to be more of an issue. After installing the software and attempting to mount the partition, I encountered an error:
device-mapper: reload ioctl failed: Invalid argument Command failed
A quick Bing and the Gentoo Wiki described this problem exactly, with the caveat that I had to recompile my kernel to add support for LRW and XTS support. Into the kernel configuration I went – the only difference I noticed is that LRW and XTS are considered “EXPERIMENTAL” but aren’t noted as such on the requirements page:
(This may come down to an x64 vs. x86 issue, but I haven’t run into any issues with these options enabled (yet!))
Of course, then came the make && make modules_install commands, which didn’t take too long to complete. The question then became, how do I install the new kernel? Looking in my /boot partition, I only had a few template files – and not the kernel itself or any grub settings. Essentially, /boot had nothing in it but the system still launches properly!
I then tried mounting /dev/sda1 manually, and the kernel and grub.conf showed up properly in the mountpoint. Something is obviously wrong with the way my system remounts /boot during the startup process, but at least now I’m able to install the new kernel. After copying /arch/x86_64/boot/bzImage to the newly available directory, I rebooted and the new kernel was picked up properly. TrueCrypt now lets me open, create and delete files from /media/truecrypt1, and automatically uses ntfs-3g support to accomplish this.
Overall, I’m pretty pleased at how easily I can recompile a kernel, and installation was seamless once I figured out that /boot wasn’t pointing to the right location. I expect I’ll try and manually remove the directory from /dev/sda3 and see if that makes a difference.
I’m surprised this is a kernel feature and not just an algorithm built into TrueCrypt