Bugzilla Bug 168691

If a truecrypt drive is mounted... / cannot be remounted as read only (similar
to dm-crypt).. This yields improper halt..

Reproducible: Always

Steps to Reproduce:
1. Mount a file with truecrypt
2. Shutdown

Actual Results:  
Bad shutdown

Expected Results:  
God shutdown

truecrypt -d

Created an attachment (id=111526) [edit]
A patch that fixes the problem in most cases

This fixes the problem if there are no nested mounts (and who would make them?)

this is not how we want to do things anymore

truecrypt should implement at least a stop addon which we would call via
`stop_addon truecrypt`

see the dm-crypt addons as an example

Created an attachment (id=111575) [edit]
Patch for halt.sh

A better patch for halt.sh

Created an attachment (id=111576) [edit]
A patch for the ebuild

Make the ebuild install the addon

Created an attachment (id=111577) [edit]
The stop part og the addon

Make truecrypt "dismount" its mappings

SpanKY: I don't understand exactly what you wish us to do here... It seems not
wise to patch the halt script...
Maybe it should dynamically find the addons?

the addons belong with the respective ebuilds ... so you need to
review/approve/merge the proposed addon here before we update baselayout

yes, it should prob be a bit more dynamic in baselayout, but we'll worry about
that later ... 1.12.x will include an explicit call to stop_addon

Created an attachment (id=111713) [edit]
truecrypt-stop.sh

OK, added to portage, truecrypt-4.2a-r3.
With minor modifications...

(In reply to comment #7)
> yes, it should prob be a bit more dynamic in baselayout, but we'll worry about
> that later ... 1.12.x will include an explicit call to stop_addon

I'm hopeful that we can have them as init scripts with baselayout-2. I'm not
saying that's a design goal, but in theory it should be possible for everything
including udev/devfs to be an init script.

basesystem: Can you please add your side?

Added to our svn repo.

uberlord: When can I close this one?

base-system: please decide when we can close this issue.

The addon script (or truecrypt) is buggy. When no truecrypt volumes are
mounted, halt.sh shows the failed umounting of the non-existing truecrypt
volumes like this in red [!!].

Obviously it is no error when no truecrypt volumes are mounted.

Please suggest how to solve this...
As the only bug may be:
/usr/bin/truecrypt -d
And by your report this returns none zero if no mount is available...

Is there any other command that can return if any is mounted? So we may execute
the above only if something is mounted?

one can do
truecrypt -l 2>&1 | grep -q  "No volumes mapped" || truecrypt -d

though it will not display any errormessages from truecrypt -1 but that is prob
ok

I think it would make more sense to see if truecrypt gives different error
codes depending on whether there are real errors or just no volumes to unmount.
And only pass the real errors to halt.sh

Jakob:
Can you please try:
truecrypt -l 2>&1 && truecrypt -d

Opps...

Jakob:
Can you please try:
truecrypt -l > /dev/null 2>&1 && truecrypt -d

(In reply to comment #19)
> Opps...
> 
> Jakob:
> Can you please try:
> truecrypt -l > /dev/null 2>&1 && truecrypt -d
> 

As you can se from the following, the one with grep that I proposed, works, The
one you proposed does not

geneshaft jakobt # truecrypt volume.tc /mnt/stuff/
geneshaft jakobt # truecrypt -l 2>&1 | grep -q  "No volumes mapped" ||
truecrypt -d; echo $?
0
geneshaft jakobt # truecrypt -l 2>&1 | grep -q  "No volumes mapped" ||
truecrypt -d; echo $?
0
geneshaft jakobt # truecrypt volume.tc /mnt/stuff/
geneshaft jakobt # truecrypt -l > /dev/null 2>&1 && truecrypt -d; echo $?
0
geneshaft jakobt # truecrypt -l > /dev/null 2>&1 && truecrypt -d; echo $?
1

One could also do
! truecrypt -l > /dev/null 2>&1  || truecrypt -d; echo $?

But that would indicate that all went well also if some error occured in
"truecrypt -l"

OK.
Added the last.
Thanks.

Please re-emerge the package.

I am also closing this as it seems baselayout now activate this one... :)