I have an Truecrypt encrypted USB thumb drive that works fine under Windows. I have successfully accessed files that were encrypted on other USB drives that were in standard FAT format.

The problem is that the encrypted drive is not seen by Linux (tried this on Ubuntu 8.10 and a Fedora 10 systems). The device /dev/sdb1 is mounted when I plug in a FAT formatted USB drive, but even that is not there when I plug in the encrypted USB drive.

Without a drive name to enter into the Truecrypt user interface, I can't decrypt and access the drive.

The question boils down to: How to access a non-FAT formatted USB device on Linux?

Thanks, Ira

Good question; I'm only guessing that the automounting under Ubuntu and Fedora assumes a FAT system; hence when you plug in a FAT system it's is mounted as /dev/sdb1.

These links might help:

http://www.howtoforge.com/truecrypt_data_encryption
http://www.movingtofreedom.org/2007/...ora-gnu-linux/

It looks like you have to look in /dev/mapper for the virtual volume; I haven't gotten around to using TrueCrypt under linux yet, so I can't help you further, but I suspect the command "truecrypt" has mount options..

TrueCrypt has the ability to create a virtual filesystem that is simply a large file on any regular drive. I use this between linux and windows and it had worked very well for me.

- Jim

I "gave up" and went on a Windows system and reformatted my 8 GB Corsair USB drive and then created a 4 GB encrypted file on that drive.

Plugging this into my Ubuntu laptop I noticed that Linux didn't recognize the USB drive at all, even though it was a well formatted Windows drive.

I then remembered that I unsuccessfully tried to create a bootable Linux on this USB drive before and was unable to boot from on on a couple of desktop machines.

The problem appears to be a problem with the USB drive and non-Windows XP systems. Is the fact that it is > 4 GB the cause of the problem? Why can Windows see the drive but Linux (and some desktop Bios') can't?

Odd.

I will try the encrypted USB drive on another thumb drive and see what Linux does with that.

So, the problem is either with the Corsair drive, or because it is an 8GB drive. It is the only USB drive that I have at the moment that is bigger than 1GB. So I can't tell the cause yet.

Has anyone else had problems with 8GB (or beyond) drives and Linux? Or with Corsair drives and Linux?

What filesystem did you use? NTFS or FAT?

- Jim

But, the format shouldn't make a difference as the drive itself wasn't even recognized as something plugged into the USB port.

XP doesn't seem to give me the option of NTFS formatting on the USB drive.

I have used an 8GB memory stick on Linux before without any issues, although it wasn't a Corsair.

Have you checked that the Corsair drive is compatible with Linux?

The fix was to add:

echo 30 > /sys/module/scsi_mod/parameters/inq_timeout

in an rc startup script. (I placed mine in /etc/rc2.d/S99usb_inq_timeout.

Now the Corsair USB device can be seen by Linux and I can mount it or use Truecrypt to create/access a fully encrypted USB drive.

Some suggestions on the web included:

or in /etc/modprobe.conf

options usb_storage delay_use=20

That didn't work for me. (I didn't try 30, though.) Others also stated that the /etc/modprobe.conf fix didn't work for them either.

Ira

From the website: http://www.asktheramguy.com/v3/showthread.php?t=73036

See bugzilla #11640

Whenever you create multiple partitions or a non fat(32) file system in a partition on the stick the inquiry of the stick timeouts. The default linux timeout is set for 5 secs, and the stick takes 14.5 seconds. So if you set the timeout to 15 seconds or more, and reinsert the stick, the stick should be mountable and readable. Just remember to add this to your boot scripts, or repeat it every time you reboot the kernel.

The inquiry timeout can be set to 15 sec with the following command line:
Code:

echo 15 >/sys/module/scsi_mod/parameters/inq_timeout

Or if you prefer the grub command line is :
Code:

scsi_mod.inq_timeout=15

I hope this longer timeout will someday be standard for the kernel. Or maybe part of an exception list when a prolific 2528 stick is detected.

Probably due to the inq_timeout, but I don't know how to tell the BIOS to wait longer. That's OK, I will use other USB drives for my portable OS instantiations.