Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 197839 - app-crypt/truecrypt cannot be built/upgraded while TrueCrypt-encrypted volumes are in use
Summary: app-crypt/truecrypt cannot be built/upgraded while TrueCrypt-encrypted volume...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Crypto team [DISABLED]
Depends on:
Reported: 2007-11-02 00:40 UTC by Guenther Brunthaler
Modified: 2007-11-02 06:52 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Guenther Brunthaler 2007-11-02 00:40:28 UTC
When trying to emerge a new version of the TrueCrypt ebuild on a Gentoo installation living on an TrueCrypt-encrypted hard disk, the build process fails.

Reproducible: Always

Steps to Reproduce:
1.emerge truecrypt

Actual Results:  
 * ERROR: app-crypt/truecrypt-4.3a failed.
 * Call stack:
 *     , line 1711:  Called dyn_preinst
 *     , line 1150:  Called pkg_preinst
 *   truecrypt-4.3a.ebuild, line   65:  Called die
 * The specific snippet of code:
 *      grep -q "^truecrypt" /proc/modules && die "Please dismount all mounted TrueCrypt volumes"
 *  The die message:
 *   Please dismount all mounted TrueCrypt volumes
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/log/ebuilds/app-crypt:truecrypt-4.3a:20071101-233247.log'.

Expected Results:  
No errors.

The problem is that the ebuild requires all TrueCrypt volumes to be unmounted before it allows itself to succeed.

However, on a fully TrueCrypt encrypted Gentoo installation, it is not possible to dismount all TrueCrypt volumes, because the volumes are in use by the Gentoo installation itself.

The only clean solution to avoid such chicken-egg-problems is to convert TrueCrypt into a slotted ebuild.

More precisely, the truecrypt cli utility should be qualified with the name of the kernel it has been built for, e. g /usr/bin/truecrypt-2.6.22-gentoo-r9. Of course, a symlink /usr/bin/truecrypt to the most current version might also be added for convenience.

This will allow to re-emerge TrueCrypt for a new kernel in /usr/src/linux, installing a new kernel module and a matching cli utility without overwriting the versions currently in use.

After the ebuild finishes, the user can than copy the new kernel and the new TrueCrypt cli utility to the new initrd for the next reboot, while the current TrueCrypt kernel module and the current cli utility still exist and can be used for properly shutting down the system.

Besides making the ebuild slotted and changing the name of the cli utility, the ebuild must be modified to skip any regression tests which require unloading the currently loaded TrueCrypt kernel module (which would require unmounting all TrueCrypt volumes and is thus impossible on a fully encrypted system).

However, a warning should be displayed to the user, informing him that regression tests could not be run, and that he has to unmount all TrueCrypt volumes and re-emerge if he wishes to have the regression tests actually being run.
Comment 1 Guenther Brunthaler 2007-11-02 01:11:21 UTC
In order to better illustrate the failure scenario, here's how my Gentoo installation has been set up:

* I have a harddisk with only 2 Partitions on it: A small 8 MB LILO /boot partition, containing the kernel and an initrd.

* The rest of the harddisk is a single TrueCrypt-encrypted partition.

* The TrueCrypt partition, when mounted with TrueCrypt, exposes an LVM2 physical volume.

* All other partitions, including /, /tmp and the swap partition, reside in LVM2 logical volumes within that LVM2 physical volume.

This allows me to resize any partition, including the / partition, using LVM2, any time I need it.

It also encrypts all of my hard disk, including any temporary files or the swap disk, so no personal or confidental data will be revealed even if my box is stolen by a burgler, the RIAA or whoever. ;-)

The initrd contains the LVM2 and TrueCrypt cli utilities, prompts for the password and then mounts the TrueCrypt volume.

Then it initializes the LMV2 volumes and mounts the new LVM2 root volume as the new root device.

Finally it cleans up the initrd and executes /sbin/init on the new root device.

It works pretty well so far.
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2007-11-02 05:50:11 UTC
This issue has nothing to do with slotting. *If* unmounting all volumes is required for running tests, then the check should be done in src_test() only, otherwise users shouldn't be bothered at all. 

Frankly said, the check doesn't make any sense whatsoever to me.
Comment 3 Alon Bar-Lev (RETIRED) gentoo-dev 2007-11-02 06:10:43 UTC
Jacub is right.
If you use the test feature you must load the new modules.
Loading the new modules forces you to unload the old ones.

There is nothing relevant in a test that only test userspace.

In order to test I use two sets of kernels, one stable and one none-stable.
This way I can test my configuration before committing it.

You can see genkernel-utils at:

These utilities helps me to maintain this configuration.
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2007-11-02 06:14:55 UTC
(In reply to comment #3)
> Jacub is right.
> If you use the test feature you must load the new modules.
> Loading the new modules forces you to unload the old ones.
> There is nothing relevant in a test that only test userspace.

Alon, I guess you missed the point here? You are trying to rmmod truecrypt in pkg_preinst(), which causes the ebuild to fail whether the user has FEATURES=test enabled or not. This should be moved to src_test() to make upgrading possible. 

In no way is this related to genkernel/initrd maintenance.
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2007-11-02 06:41:45 UTC
Plus, thinking about this, there's no way to actually run the tests in a reasonable/useful way in the ebuild if you need the new modules for that. 

- in src_test() they are not installed yet (unless you are re-emerging the ebuild, and then it's pointless to try to rmmod that first)
- in pkg_postinst() it's too late because you have the (potentially broken) package already installed.

Then again, I didn't check how the tests actually work, they might not need the kernel modules at all, in which case the rmmod hacks should be just dropped altogether.
Comment 6 Alon Bar-Lev (RETIRED) gentoo-dev 2007-11-02 06:50:53 UTC
Thanks, this I can understand... :)
I was not aware that preinst is used.
Rechecked, tests of this version do not relay on kernel modules.
Removed the preinst step.
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2007-11-02 06:52:56 UTC
(In reply to comment #6)
> Removed the preinst step.

Thanks! ;)