When I want to make a check, I get this:

it's because there is no fsck.vfat on /sbin (same here) but this helps (as root):



I tried it and it works:

sudo fsck.vfat /dev/loop0
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/dev/loop0: 0 files, 1/1218484 clusters

my output.

Maybe you should add this in the doinst.
It works.

Done! Package updated!

Good.

By the way, I think you should add the zenwalk version and the build number in the name of the package. You may take a look at x11-driver-nvidia's. It would be something like this: truecrypt-6.2-i686-2.6.29.2_62.1.txz.

And as you can use it in CLI, i486 would be wise, but I personally don't care.

Done! Recompiled package for i486 and used suggested naming convention

Why should a truecrypt package create that symlink!? The only place where such a symlink should be created is the package where the symlinked binary comes from unless it's truecrypt specific but I don't think so. The relevant package is dosfstools.

Why are there that many files in the src directory? Where is `build-<pkgname>.sh'. Seventh rule on this page: http://wiki.zenwalk.org/index.php?title ... kage_Rules
Just rename your .ZenBuild script.

I have a suggestion, how to make kernel crypto services available. It's possible to build a single kernel module without rebuilding the whole kernel. So you could do exactly that and provide the modules with your package.
The command to do this is:

This will build the xts.ko module in crypto/. Just copy it over to: /lib/modules/$(uname -r)/kernel/crypto/

Well, I did manage to create the xts and gf128mul modules (they need each other), copy them from /lib/modules/linux-2.6.29.2/kernel/crypto and added them on rc.modules for extra measure. Sadly, it doesn't work...

I'm thinking of creating a tc script that will call truecrypt -m=nokernelcrypto, and use that on CLI.

I think ZW's kernel needs to be shipped with kernel crypto services support enabled...

Package is updated. truecrypt.ZenBuild is renamed to build-truecrypt.sh and other minor revisions. I tried the XTS kernel module approach by Shador, but it didn't help You still need to disable kernel crypto service support on GUI mode and have 'm=nokernelcrypto' on CLI mode. To lessen the burden on CLI mode, you can make a bash alias for 'truecrypt -m=nokernelcrypto' on your .bashrc like this:



There will be a performance degrade when you disable kernel crypto service support, but hey, it's better than nothing (except dm-crypt with luks of course ).

BTW the links in your first post are wrong.

LOL! your right! thanks for remaining me it's fixed.

As truecrypt only works if started as root, you should modify the desktop file (/usr/share/applications/truecrypt.desktop) with a simple sed, so that trucrypt is startet with gksu.

I checked the modules thing. The problem is that the dm-crypt module would have to be recompiled. But this feature is compiled into the kernel on ZW. So I tried what would happen if I compile and insert it. Nothing, the module wasn't inserted and insmod exited with an error.
So dm-crypt as a module would be another alternative.

I think I know the real culprit for the read ioctl errors: lack of some ciphers on ZW!

Yes, having XTS and GF128MUL kernel modules created and loaded removed the need for disabling kernel crypto services on truecrypt. The added menace is that the lack of twofish, serpent, rmd160 (ripemd160), wp512 (whirlpool) support! I created tc container with the default cipher and hash settings and tried to mount it with kernel crypto support, it worked! When I tried my previously-created container (AES-Serpent-Twofish cipher with sha512 hash), mounting with kernel crypto failed! When I mounted without kernel crypto, mounting works! It seems I needed the serpent, twofish and rmd160 modules to get it mounted.

Seems like repack time for me...

OK! Newest rebuild is up! It seems TrueCrypt is now 100% functional! All the needed kernel modules to make TrueCrypt work perfectly are included in the package I also included the gksu call suggested by Shador on the .desktop file (I won't use it, I use a sudo nopasswd rule for truecrypt ).

I don't think the "gksu" thing is really wise, as the volume you create doesn't necesserly have to be owned by root.
You better should find a solution that would let a normal user mount a volume. Normally, when you type the root password after clicking the "mount" button, there should'nt be the error message I mentionned in my first post. That would be better to find a way to permit that.

Maybe you should make doinst.sh create a truecrypt group and add "%truecrypt ALL = (ALL) NOPASSWD:/usr/bin/truecrypt" in /etc/sudoers. Like for VirtualBox, the users allowed to mount volumes just have to be added in the truecrypt group.