[dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[Claudio Moretti]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

Hello everyone,

I have recently (aka today) encrypted my Windows system partition with
Truecrypt.
My system is booting fine (both Windows and Debian sid), but I have the
necessity of mounting the Windows partition when booting Debian (all my
files are there).

I found out that with a simple entry in /etc/crypttab this should be easily
done, but when I tried it, I got the following error:

[....] Starting crypto disk.../usr/sbin/cryptdisks_start: 1: export:
> CRYPTTAB_OPTION_tcrypt-system: bad variable name
>

I thought it was a bad-something happening with the Debian version of
cryptsetup (2:1.6.1-1), so I downloaded and compiled the 1.7.0-git version
and tried to use it. The same error occurs

root@Chuck:/home/claudio# /usr/sbin/cryptdisks_start truecrypt
> [....] Starting crypto disk.../usr/sbin/cryptdisks_start: 1: export:
> CRYPTTAB_OPTION_tcrypt-system: bad variable name
>

in an online version of the crypttab manpage[1] I can see the tcrypt and
tcrypt-system options, and how to use them; in my manpage (cryptsetup
2:1.6.1-1 2013-06-28 CRYPTTAB(5) ) there is no such thing.

I know that this is not the 1.7.0-git manpage, but (AFAIK) the tcrypt and
tcrypt-system options should be there and, nevertheless, 1.7.0-git does not
work.

I don't know how to solve this. I can't reboot rigth now, so I don't know
if the "workaround" I'm trying ('cat passwordfile | /usr/sbin/cryptsetup
--tcrypt-system tcryptOpen /dev/sda1 truecrypt' and 'mount -a' in
/etc/rc.local) works, but I'd prefer to use the 'built-in' function.

Any suggestions?

Thanks,

Claudio

[1] http://www.freedesktop.org/software/systemd/man/crypttab.html

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

Re: [dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

> in an online version of the crypttab manpage[1] I can see the tcrypt and
> tcrypt-system options, and how to use them; in my manpage (cryptsetup
> 2:1.6.1-1 2013-06-28 CRYPTTAB(5) ) there is no such thing.
>
> I know that this is not the 1.7.0-git manpage, but (AFAIK) the tcrypt and
> tcrypt-system options should be there and, nevertheless, 1.7.0-git does not
> work.
>
> I don't know how to solve this. I can't reboot rigth now, so I don't know
> if the "workaround" I'm trying ('cat passwordfile | /usr/sbin/cryptsetup
> --tcrypt-system tcryptOpen /dev/sda1 truecrypt' and 'mount -a' in
> /etc/rc.local) works, but I'd prefer to use the 'built-in' function.
>
> Any suggestions?
>
> Thanks,
>
> Claudio
>
> [1] http://www.freedesktop.org/software/systemd/man/crypttab.html
>
>
> tcrypt options to "/etc/crypttab" were added a few months ago to support
systemd somewhere.

Probably the crypttab errors you are getting are due to the support not
being there in debian yet.

Will appreciate if you could do me a favor,i have a project at[1] .It does
support opening truecrypt system volume but i have not tested the
functionality because i have no system volume to test.

If it works,you could use the project to open your truecrypt system and
other encrypted volumes you may have the project support.

[1] http://code.google.com/p/zulucrypt/

[-- Attachment #2: Type: text/html, Size: 2015 bytes --]

Re: [dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[Claudio Moretti]

[-- Attachment #1: Type: text/plain, Size: 3398 bytes --]

Thanks everyone for the answers!

On Wed, Sep 11, 2013 at 2:16 AM, .. ink .. <mhogomchungu@gmail.com> wrote:

>
> tcrypt options to "/etc/crypttab" were added a few months ago to support
> systemd somewhere.
>
> Probably the crypttab errors you are getting are due to the support not
> being there in debian yet.
>
> Will appreciate if you could do me a favor,i have a project at[1] .It does
> support opening truecrypt system volume but i have not tested the
> functionality because i have no system volume to test.
>
> If it works,you could use the project to open your truecrypt system and
> other encrypted volumes you may have the project support.
>
> [1] http://code.google.com/p/zulucrypt/
>
>
 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?



On Wed, Sep 11, 2013 at 2:42 AM, Arno Wagner <arno@wagner.name> wrote:

> I suspect the problem is that sid uses systemd-44 while freedesktop has
> version 206 as newest (44 being "stable" and "206" development?),
> and the man-page for crypttab likely references the development
> version. As that was made, cryptsetup could not yet (I think)
> handle tcrypt volumes.
>
>
I suspected that as well (after googling a lot) but I'm not sure: I don't
have systemd, at least not the whole package.. I only have a library but,
as you suggested, is the "44" and not the "204".. I tried installing that,
but nothing changed...

claudio@Chuck:~$ dpkg -l|grep systemd
> ii  libsystemd-login0:amd64
> 204-2+b1                           amd64        systemd login utility
> library
> claudio@Chuck:~$ apt-cache policy libsystemd-login0
> libsystemd-login0:
>   Installed: 204-2+b1
>   Candidate: 44-12+b1
>   Version table:
>  *** 204-2+b1 0
>         600 http://ftp.debian.org/debian/ experimental/main amd64 Packages
>         100 /var/lib/dpkg/status
>      44-12+b1 0
>        1001 http://ftp.debian.org/debian/ sid/main amd64 Packages
>
>


> Your workaround looks good to me. You could also make a proper
> boot script, with the dependency-headers, it is not that hard.
>

I should have thought about that...


On Wed, Sep 11, 2013 at 8:05 AM, Milan Broz <gmazyland@gmail.com> wrote:

> No, the cryptsetup binary version is fine. If you have system disk
> encryption,
> you need 1.6.2 with fixes but otherwise the support is in 1.6.1 already.
>
> What is missing is Debian init scripts/systemd/cryptsetup scripts  support
> for new crypttab keyword.
>
> Parsing of crypttab is not part of upstream cryptsetup so this report
> should
> go into Debian bugzilla.
>
> But if you are able to use systemd 206 as service manager, it should work
> by default...
>

Should I install systemd, then? AFAIK[1] there are some problems with
systemd running at boot time (replacing sysvinit); I'm not sure it'll work
without it and I'm kind of afraid I'm going to blow everything up..
Also, if it's not systemd, who is controlling it? initramfs?

BTW, the workaround is not working: for some reason, this happens :/

root@Chuck:/home/claudio# cat /etc/tcrypt.key | cryptsetup tcryptOpen
> --tcrypt-system /dev/sda truecrypt
> Cannot use device /dev/sda which is in use (already mapped or mounted).
>

Thanks,

Claudio

[1] https://wiki.debian.org/systemd#Known_Issues_and_Workarounds

[-- Attachment #2: Type: text/html, Size: 5622 bytes --]

Re: [dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[Claudio Moretti]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Wed, Sep 11, 2013 at 2:33 PM, Claudio Moretti <flyingstar16@gmail.com>wrote:

> BTW, the workaround is not working: for some reason, this happens :/
>
> root@Chuck:/home/claudio# cat /etc/tcrypt.key | cryptsetup tcryptOpen
>> --tcrypt-system /dev/sda truecrypt
>> Cannot use device /dev/sda which is in use (already mapped or mounted).
>>
>
>
I managed to open the device by calling directly the compiled binary in the
folder where I compiled it. And that's really odd. It doesn't work the
other way...

Claudio

[-- Attachment #2: Type: text/html, Size: 1211 bytes --]

Re: [dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 4976 bytes --]

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



On Wed, Sep 11, 2013 at 8:33 AM, Claudio Moretti <flyingstar16@gmail.com>wrote:

> Thanks everyone for the answers!
>
> On Wed, Sep 11, 2013 at 2:16 AM, .. ink .. <mhogomchungu@gmail.com> wrote:
>
>>
>> tcrypt options to "/etc/crypttab" were added a few months ago to support
>> systemd somewhere.
>>
>> Probably the crypttab errors you are getting are due to the support not
>> being there in debian yet.
>>
>> Will appreciate if you could do me a favor,i have a project at[1] .It
>> does support opening truecrypt system volume but i have not tested the
>> functionality because i have no system volume to test.
>>
>> If it works,you could use the project to open your truecrypt system and
>> other encrypted volumes you may have the project support.
>>
>> [1] http://code.google.com/p/zulucrypt/
>>
>>
>  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?
>
>
>
> On Wed, Sep 11, 2013 at 2:42 AM, Arno Wagner <arno@wagner.name> wrote:
>
>> I suspect the problem is that sid uses systemd-44 while freedesktop has
>> version 206 as newest (44 being "stable" and "206" development?),
>> and the man-page for crypttab likely references the development
>> version. As that was made, cryptsetup could not yet (I think)
>> handle tcrypt volumes.
>>
>>
> I suspected that as well (after googling a lot) but I'm not sure: I don't
> have systemd, at least not the whole package.. I only have a library but,
> as you suggested, is the "44" and not the "204".. I tried installing that,
> but nothing changed...
>
> claudio@Chuck:~$ dpkg -l|grep systemd
>> ii  libsystemd-login0:amd64
>> 204-2+b1                           amd64        systemd login utility
>> library
>> claudio@Chuck:~$ apt-cache policy libsystemd-login0
>> libsystemd-login0:
>>   Installed: 204-2+b1
>>   Candidate: 44-12+b1
>>   Version table:
>>  *** 204-2+b1 0
>>         600 http://ftp.debian.org/debian/ experimental/main amd64
>> Packages
>>         100 /var/lib/dpkg/status
>>      44-12+b1 0
>>        1001 http://ftp.debian.org/debian/ sid/main amd64 Packages
>>
>>
>
>
>> Your workaround looks good to me. You could also make a proper
>> boot script, with the dependency-headers, it is not that hard.
>>
>
> I should have thought about that...
>
>
> On Wed, Sep 11, 2013 at 8:05 AM, Milan Broz <gmazyland@gmail.com> wrote:
>
>> No, the cryptsetup binary version is fine. If you have system disk
>> encryption,
>> you need 1.6.2 with fixes but otherwise the support is in 1.6.1 already.
>>
>> What is missing is Debian init scripts/systemd/cryptsetup scripts  support
>> for new crypttab keyword.
>>
>> Parsing of crypttab is not part of upstream cryptsetup so this report
>> should
>> go into Debian bugzilla.
>>
>> But if you are able to use systemd 206 as service manager, it should work
>> by default...
>>
>
> Should I install systemd, then? AFAIK[1] there are some problems with
> systemd running at boot time (replacing sysvinit); I'm not sure it'll work
> without it and I'm kind of afraid I'm going to blow everything up..
> Also, if it's not systemd, who is controlling it? initramfs?
>
> BTW, the workaround is not working: for some reason, this happens :/
>
> root@Chuck:/home/claudio# cat /etc/tcrypt.key | cryptsetup tcryptOpen
>> --tcrypt-system /dev/sda truecrypt
>> Cannot use device /dev/sda which is in use (already mapped or mounted).
>>
>
> Thanks,
>
> Claudio
>
> [1] https://wiki.debian.org/systemd#Known_Issues_and_Workarounds
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
>

[-- Attachment #2: Type: text/html, Size: 7868 bytes --]

Re: [dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[Claudio Moretti]

[-- Attachment #1: Type: text/plain, Size: 2996 bytes --]

On Wed, Sep 11, 2013 at 3:10 PM, .. ink .. <mhogomchungu@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.

Thanks,

Claudio

[-- Attachment #2: Type: text/html, Size: 3624 bytes --]

Re: [dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]

On Wed, Sep 11, 2013 at 11:02 AM, Claudio Moretti <flyingstar16@gmail.com>wrote:

> On Wed, Sep 11, 2013 at 3:10 PM, .. ink .. <mhogomchungu@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.
>>
>>
> 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.
>
>
zulucrypt has a GUI component and a CLI component.The CLI component is an
suid programs and thats how it work from normal user accounts without
necessitating the user elevating its permissions since it can do that by
itself.It mounts unlocked volumes in "/run/media/private/$USER"

zuluMount will also allow you to unlock and mount the volume at
"/run/media/private/$USER" but it has an option to also create a "public
mirror" of the private mount point at "/run/media/public".Useful for multi
user access to the volume.

like others have said,if you want to go with system tools,you will have to
file a bug report with debian to ask them to add truecrypt
support."/etc/crypttab" is not part of cryptsetup project and hence its
abilities and deficiencies are outside the scope of this project.

zulucrypt is also not part of cryptsetup project.Hope nobody minded i
mentioned it

your own solution should work if you use at leave version 1.6.2 of
cryptsetup.the tricky part will be how to tear down everything when you are
powering down.

[-- Attachment #2: Type: text/html, Size: 4069 bytes --]

Re: [dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[Arno Wagner]

On Wed, Sep 11, 2013 at 02:00:45AM +0200, Claudio Moretti wrote:
> Hello everyone,
> 
> I have recently (aka today) encrypted my Windows system partition with
> Truecrypt.
> My system is booting fine (both Windows and Debian sid), but I have the
> necessity of mounting the Windows partition when booting Debian (all my
> files are there).
> 
> I found out that with a simple entry in /etc/crypttab this should be easily
> done, but when I tried it, I got the following error:
> 
> [....] Starting crypto disk.../usr/sbin/cryptdisks_start: 1: export:
> > CRYPTTAB_OPTION_tcrypt-system: bad variable name
> >
> 
> I thought it was a bad-something happening with the Debian version of
> cryptsetup (2:1.6.1-1), so I downloaded and compiled the 1.7.0-git version
> and tried to use it. The same error occurs
> 
> root@Chuck:/home/claudio# /usr/sbin/cryptdisks_start truecrypt
> > [....] Starting crypto disk.../usr/sbin/cryptdisks_start: 1: export:
> > CRYPTTAB_OPTION_tcrypt-system: bad variable name
> >
> 
> in an online version of the crypttab manpage[1] I can see the tcrypt and
> tcrypt-system options, and how to use them; in my manpage (cryptsetup
> 2:1.6.1-1 2013-06-28 CRYPTTAB(5) ) there is no such thing.
> 
> I know that this is not the 1.7.0-git manpage, but (AFAIK) the tcrypt and
> tcrypt-system options should be there and, nevertheless, 1.7.0-git does not
> work.

I suspect the problem is that sid uses systemd-44 while freedesktop has
version 206 as newest (44 being "stable" and "206" development?),
and the man-page for crypttab likely references the development
version. As that was made, cryptsetup could not yet (I think) 
handle tcrypt volumes.
 
> I don't know how to solve this. I can't reboot rigth now, so I don't know
> if the "workaround" I'm trying ('cat passwordfile | /usr/sbin/cryptsetup
> --tcrypt-system tcryptOpen /dev/sda1 truecrypt' and 'mount -a' in
> /etc/rc.local) works, but I'd prefer to use the 'built-in' function.

For 'built-in' I suspect you would need to get Debian to update
systemd. As it is a critical part of the system, there may be issues
preventing that at this time.
 
> Any suggestions?

Your workaround looks good to me. You could also make a proper
boot script, with the dependency-headers, it is not that hard.

Arno


> 
> Thanks,
> 
> Claudio
> 
> [1] http://www.freedesktop.org/software/systemd/man/crypttab.html

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Truecrypt and cryptdisks_start: failing with CRYPTTAB_OPTION_tcrypt-system: bad variable name

[Milan Broz]

On 11.9.2013 2:00, Claudio Moretti wrote:
> Hello everyone,
>
> I have recently (aka today) encrypted my Windows system partition
> with Truecrypt. My system is booting fine (both Windows and Debian
> sid), but I have the necessity of mounting the Windows partition when
> booting Debian (all my files are there).
>
> I found out that with a simple entry in /etc/crypttab this should be
> easily done, but when I tried it, I got the following error:
>
> [....] Starting crypto disk.../usr/sbin/cryptdisks_start: 1: export:
> CRYPTTAB_OPTION_tcrypt-system: bad variable name
>
>
> I thought it was a bad-something happening with the Debian version of
> cryptsetup (2:1.6.1-1), so I downloaded and compiled the 1.7.0-git
> version and tried to use it. The same error occurs

No, the cryptsetup binary version is fine. If you have system disk encryption,
you need 1.6.2 with fixes but otherwise the support is in 1.6.1 already.

What is missing is Debian init scripts/systemd/cryptsetup scripts  support
for new crypttab keyword.

Parsing of crypttab is not part of upstream cryptsetup so this report should
go into Debian bugzilla.

But if you are able to use systemd 206 as service manager, it should work
by default...

Milan