[dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name
flyingstar16 at gmail.com
Wed Sep 11 17:02:08 CEST 2013
On Wed, Sep 11, 2013 at 3:10 PM, .. ink .. <mhogomchungu at gmail.com> wrote:
> >I don't think that's the problem: I can open the volume when I'm logged
> in (as a matter of fact, it's open right now) so cryptsetup >it's working;
> it's the boot script (cryptdisks_start) that's failing.. Can zulucrypt
> modify that?
> No,it can not,zuluCrypt is a desktop GUI application not designed to be
> used from root account or as part of boot up process.
> You have a truecrypt volume and you want a convenient way to unlock it.
> You dont seem to have the necessary systemd support to do that and you
> seem uncomfortable to roll your own solution and hence i suggest zuluCrypt
> as an alternative convenient solution.I think it is a better alternative
> since with a GUI application,you will get to unlock the volume when you
> need access to it and then lock it when done with it.
> with systemd,it will get unlocked at boot time each and everytime even
> when you have no need to access the encrypted volume and unlocking later on
> will involve going to root terminal,something that may not always be
> convenient.This assumes you are on a desktop system,not a headless server.
> Choosing btw rolling your own solution and updating systemd components to
> gain support,i think rolling your solution will be a better alternative.
I think I did not explain my problem well: I have the necessity of
unlocking the volume at boot time, because I require constat access to some
data that are now stored on the truecrypt volume.
This makes inefficient - at least for me - unlocking the volume after
booting the system. The cryptsetup command line allows me to unlock it and,
if for some reasons it fails, I can always use truecrypt command line (they
have a tar.gz with the CLI) which can be scripted.
I'd like to use the system-provided tools, though, and at the moment the
cryptdisks_start action that is triggered at boot time (along with
/etc/crypttab) is the most efficient way to do it. What I'm trying to
understand is what is triggering the "bad variable name" error, because it
can't be systemd (it's not installed), so I believe it can only be
sysvinit; my current workaround is failing, for some reason, that's what
makes me unhappy with rolling my own solution.
My concerns with switching to zulucrypt are mostly two, at the moment: (1)
since it appears to me as a GUI interface for cryptsetup, it doesn't seem
to fit my current need and (2) even if it can help me (by, for example,
providing a CLI which I can trigger from rc.local or some other script at
logon), it has no permissions to mount a device in /media/ (because, as you
said, it does not require administrative privileges), nor can 'mount -o
bind' the folders I'm mounting in my home.
If there's anything I missed, or a way to do what I'm trying to do using
zulucrypt, I'm open to any suggestions, and I'll be willing to try them. My
goal is to reach what I had when my Windows disk was unencrypted.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt