Need clarification on IFW and Truecrypt
Re: Need clarification on IFW and Truecrypt
Well you already have KB 462, but it might be helpful to have something more specifically related to using IFL from outside Windows, without all the PhyLock stuff. Anyway, I'll give the new version a try on my machine today and see how it works. Thanks very much for getting this to work. I think it's a major improvement for TC users. Hope I wasn't too obnoxious in pressing the issue.
Re: Need clarification on IFW and Truecrypt
I just wanted to report that I did a test with IFL 2.77 and backed up and restored the C partition, and then the D partition, in both cases doing used-sectors-only images of the Truecrypt-mounted versions of these partitions. And it all worked perfectly using essentially the default settings. So thanks very much for this fix. It's going to greatly simplify my life.
But my computer uses whole drive encryption, so I'm not able to test the case where the partitions are encrypted individually/separately. I assume in that case the C partition would still image and restore correctly via 2.77, but I wonder whether the D partition would work. My memory of the KB article is that a separately-mounted non-system partition won't image properly because the TC-mounted version of such a partition, with it's assigned drive letter, doesn't look like a proper physical drive. Is that still the case using the IFL 2.77 boot media?
And then the same question arises with respect to a 2nd physical non-system hard drive.
But my computer uses whole drive encryption, so I'm not able to test the case where the partitions are encrypted individually/separately. I assume in that case the C partition would still image and restore correctly via 2.77, but I wonder whether the D partition would work. My memory of the KB article is that a separately-mounted non-system partition won't image properly because the TC-mounted version of such a partition, with it's assigned drive letter, doesn't look like a proper physical drive. Is that still the case using the IFL 2.77 boot media?
And then the same question arises with respect to a 2nd physical non-system hard drive.
-
TeraByte Support(TP)
- Posts: 305
- Joined: Wed Aug 31, 2011 4:22 pm
Re: Need clarification on IFW and Truecrypt
Peabody wrote:
> I just wanted to report that I did a test with IFL 2.77 and backed up and
> restored the C partition, and then the D partition, in both cases doing
> used-sectors-only images of the Truecrypt-mounted versions of these
> partitions. And it all worked perfectly using essentially the default
> settings. So thanks very much for this fix. It's going to greatly
> simplify my life.
>
> But my computer uses whole drive encryption, so I'm not able to test the
> case where the partitions are encrypted individually/separately. I assume
> in that case the C partition would still image and restore correctly via
> 2.77, but I wonder whether the D partition would work. My memory of the KB
> article is that a separately-mounted non-system partition won't image
> properly because the TC-mounted version of such a partition, with it's
> assigned drive letter, doesn't look like a proper physical drive. Is that
> still the case using the IFL 2.77 boot media?
> And then the same question arises with respect to a 2nd physical non-system
> hard drive.
In all tests tried so far, the Linux version of TC is able to mount non-system partitions (such as an individually-encrypted D partition on HD0), and drives, so that IFL can access them as /dev/mapper drives, the same as it does for system partitions and drives. And image/restore operations have worked on those with all default options. If you have an entire, non-system drive encrypted, then it shows up in Linux as a drive with no partitions, because the entire drive is encrypted, including the 1st sector where the partition table is located. But if you select that drive in TC (such as /dev/sdb), then you will be able to mount it in the same way as other volumes, and then image/restore it like the others. The issue in Windows with IFW (as the KB article points out) is just that IFW is not able to access the mounted TC volumes themselves, just the raw, encrypted partition. So you can image them, but only in encrypted form.
One thing I would suggest when working with TC volumes in Linux is to NOT mount the file system when imaging/restoring them. In TC, you would do that by selecting "Do not mount" in the Filesystem section of the mount dialog box. What that does is make the TC volume available as a device mapper drive (e.g. /dev/mapper/truecrypt1), but doesn't mount the filesystem. That's all that is needed to image/restore the volume. Not mounting the filesystem on a TC volume is the equivalent of an unmounted partition, which is the way IFL is intended to be used. That will prevent anything other than IFL from writing to the volume during imaging/restoring. In the case of the IFL boot disk, nothing is likely to be written anyway, but it's good practice in general.
> I just wanted to report that I did a test with IFL 2.77 and backed up and
> restored the C partition, and then the D partition, in both cases doing
> used-sectors-only images of the Truecrypt-mounted versions of these
> partitions. And it all worked perfectly using essentially the default
> settings. So thanks very much for this fix. It's going to greatly
> simplify my life.
>
> But my computer uses whole drive encryption, so I'm not able to test the
> case where the partitions are encrypted individually/separately. I assume
> in that case the C partition would still image and restore correctly via
> 2.77, but I wonder whether the D partition would work. My memory of the KB
> article is that a separately-mounted non-system partition won't image
> properly because the TC-mounted version of such a partition, with it's
> assigned drive letter, doesn't look like a proper physical drive. Is that
> still the case using the IFL 2.77 boot media?
> And then the same question arises with respect to a 2nd physical non-system
> hard drive.
In all tests tried so far, the Linux version of TC is able to mount non-system partitions (such as an individually-encrypted D partition on HD0), and drives, so that IFL can access them as /dev/mapper drives, the same as it does for system partitions and drives. And image/restore operations have worked on those with all default options. If you have an entire, non-system drive encrypted, then it shows up in Linux as a drive with no partitions, because the entire drive is encrypted, including the 1st sector where the partition table is located. But if you select that drive in TC (such as /dev/sdb), then you will be able to mount it in the same way as other volumes, and then image/restore it like the others. The issue in Windows with IFW (as the KB article points out) is just that IFW is not able to access the mounted TC volumes themselves, just the raw, encrypted partition. So you can image them, but only in encrypted form.
One thing I would suggest when working with TC volumes in Linux is to NOT mount the file system when imaging/restoring them. In TC, you would do that by selecting "Do not mount" in the Filesystem section of the mount dialog box. What that does is make the TC volume available as a device mapper drive (e.g. /dev/mapper/truecrypt1), but doesn't mount the filesystem. That's all that is needed to image/restore the volume. Not mounting the filesystem on a TC volume is the equivalent of an unmounted partition, which is the way IFL is intended to be used. That will prevent anything other than IFL from writing to the volume during imaging/restoring. In the case of the IFL boot disk, nothing is likely to be written anyway, but it's good practice in general.