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 attachment 111526 [details, diff] 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 attachment 111575 [details, diff] Patch for halt.sh A better patch for halt.sh
Created attachment 111576 [details, diff] A patch for the ebuild Make the ebuild install the addon
Created attachment 111577 [details] 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 attachment 111713 [details] 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... :)
