Bugzilla Bug 197839

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
2.
3.

Actual Results:  
 *
 * ERROR: app-crypt/truecrypt-4.3a failed.
 * Call stack:
 *               ebuild.sh, line 1711:  Called dyn_preinst
 *               ebuild.sh, 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.

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.

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.

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:
http://alon.barlev.googlepages.com/utilities

These utilities helps me to maintain this configuration.

(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.

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.

OK.
Thanks, this I can understand... :)
Sorry.
I was not aware that preinst is used.
Rechecked, tests of this version do not relay on kernel modules.
Removed the preinst step.

(In reply to comment #6)
> Removed the preinst step.

Thanks! ;)