>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.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.
On Wed, Sep 11, 2013 at 8:33 AM, Claudio Moretti <flyingstar16@xxxxxxxxx> wrote:
Thanks everyone for the answers!
On Wed, Sep 11, 2013 at 2:16 AM, .. ink .. <mhogomchungu@xxxxxxxxx> 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.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@xxxxxxxxxxx> 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 PackagesYour 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...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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
