Peabody wrote:
> Well, it may be a Samsung issue more than an IFL issue, but the drive on
> USB3 just doesn't appear anywhere in IFL, either as a potential source or
> potential destination. But if I move it to a USB2 port, it shows up just
> fine. So for whatever reason, IFL isn't working with the USB3 ports.
>
> I should add that this is a third generation processor - Ivy Bridge - and I
> believe the USB3 ports are built into the chipset. So perhaps they use
> newer drivers than the distro has. But I'm just guessing.
It should be loaded automatically, but one thing you could try is to manually load the USB3 driver, and see if that causes the USB3 drive to show up. To do that, just open a terminal window and run this command: modprobe xhci_hcd
Then exit from the IFL program and start it again (or just go back to the main menu screen and start again) to see if the USB3 drive is now detected.
Need clarification on IFW and Truecrypt
-
TeraByte Support(TP)
- Posts: 305
- Joined: Wed Aug 31, 2011 4:22 pm
Re: Need clarification on IFW and Truecrypt
The USB3 stlll doesn't work. But more important -
The image/restore doesn't work.
Working only from the IFL CD, I first did a full drive backup, multifile, with no encryption.
Then I installed Truecrypt and did a whole drive encryption. Then I booted the IFL CD, mounted the D partition in Truecrypt, opened IFL, and did a normal image and restore of that partition. And that worked fine. I rebooted into Windows, and the D partition was there with all the files, and they opened ok.
So then I tried the real test - image and restore of the C partition. I mounted it in Truecrypt, went into IFL, did the image, and did the restore.
And when I rebooted, I entered the TC password, and it said Booting..., but then immediately said "A read error has occurred. Press Ctl-Atl=Del to reboot" But of course that didn't work.
I booted the TC rescue disk, and restored the TC boot loader, and the keys, but still get the read error.
Well of course there's no read error from the drive. It's just that either the image or the restore is messing with something it shouldn't. The settings and options are pretty obscure, and maybe the defaults need to be changed. The only thing I changed was turning off logging.
As a reminder, I had already removed the 100mb partition per your KB article, so that's not the problem.
So at this point I'm trying to restore the original unecrypted images.
Any suggestions would be appreciated.
The image/restore doesn't work.
Working only from the IFL CD, I first did a full drive backup, multifile, with no encryption.
Then I installed Truecrypt and did a whole drive encryption. Then I booted the IFL CD, mounted the D partition in Truecrypt, opened IFL, and did a normal image and restore of that partition. And that worked fine. I rebooted into Windows, and the D partition was there with all the files, and they opened ok.
So then I tried the real test - image and restore of the C partition. I mounted it in Truecrypt, went into IFL, did the image, and did the restore.
And when I rebooted, I entered the TC password, and it said Booting..., but then immediately said "A read error has occurred. Press Ctl-Atl=Del to reboot" But of course that didn't work.
I booted the TC rescue disk, and restored the TC boot loader, and the keys, but still get the read error.
Well of course there's no read error from the drive. It's just that either the image or the restore is messing with something it shouldn't. The settings and options are pretty obscure, and maybe the defaults need to be changed. The only thing I changed was turning off logging.
As a reminder, I had already removed the 100mb partition per your KB article, so that's not the problem.
So at this point I'm trying to restore the original unecrypted images.
Any suggestions would be appreciated.
Re: Need clarification on IFW and Truecrypt
See previous message.
I successfully restored the drive from the original unencrypted images, and it boots fine. No read errors. I'll do the encryption again overnight (10 hours), and maybe try something tomorrow if anyone has suggestions.
What strikes me is that this is so close to being the Holy Grail for Truecrypt users - being able to do normal used-sector-only images and restorations of individual partitions of an encrypted drive. It clearly works for me for the D partition, and I've TBIViewed the contents of the C image, and all the files are there. So the basic process does work.
But something is being corrupted in the C process. IFL is probably updating something it thinks needs to be updated, and that's messing things up. All it needs to do is copy the used sectors during the imaging, beginning at at LBA 2048, or whatever, and write them back exactly as copied, and not change anything.
Well, hopefully I just have a setting wrong. But if not, it seems it would be worth it from a business viewpoint to get this to work. So far as I know, nobody else has. You could even have "Truecrypt Mode" option in the settings that would set everything the right way.
I successfully restored the drive from the original unencrypted images, and it boots fine. No read errors. I'll do the encryption again overnight (10 hours), and maybe try something tomorrow if anyone has suggestions.
What strikes me is that this is so close to being the Holy Grail for Truecrypt users - being able to do normal used-sector-only images and restorations of individual partitions of an encrypted drive. It clearly works for me for the D partition, and I've TBIViewed the contents of the C image, and all the files are there. So the basic process does work.
But something is being corrupted in the C process. IFL is probably updating something it thinks needs to be updated, and that's messing things up. All it needs to do is copy the used sectors during the imaging, beginning at at LBA 2048, or whatever, and write them back exactly as copied, and not change anything.
Well, hopefully I just have a setting wrong. But if not, it seems it would be worth it from a business viewpoint to get this to work. So far as I know, nobody else has. You could even have "Truecrypt Mode" option in the settings that would set everything the right way.
-
TeraByte Support(PP)
- Posts: 1694
- Joined: Fri Aug 12, 2011 12:51 am
Re: Need clarification on IFW and Truecrypt
What options did you use when you encrypted the drive? My tests were with no HPA encryption and a single OS.
Also, when you restored the enrypted partition, did you check the "Disk" box or just the partition box? I would try with just the partition selected, if you didn't.
Also, when you restored the enrypted partition, did you check the "Disk" box or just the partition box? I would try with just the partition selected, if you didn't.
Re: Need clarification on IFW and Truecrypt
TeraByte Support(PP) wrote:
> What options did you use when you encrypted the drive? My tests were with
> no HPA encryption and a single OS.
>
> Also, when you restored the enrypted partition, did you check the
> "Disk" box or just the partition box? I would try with just the
> partition selected, if you didn't.
I did it exactly the same way - no HPA, single OS, partition only.
> What options did you use when you encrypted the drive? My tests were with
> no HPA encryption and a single OS.
>
> Also, when you restored the enrypted partition, did you check the
> "Disk" box or just the partition box? I would try with just the
> partition selected, if you didn't.
I did it exactly the same way - no HPA, single OS, partition only.
-
TeraByte Support
- Posts: 3760
- Joined: Thu May 05, 2011 10:37 pm
Re: Need clarification on IFW and Truecrypt
If you backup unencrypted, your restore should choose to write a standard
mbr since the restored data isn't encrypted. If you back up the data
encrypted, it's restored encrypted.
"Peabody" wrote in message news:3488@public.image...
TeraByte Support(PP) wrote:
> What options did you use when you encrypted the drive? My tests were with
> no HPA encryption and a single OS.
>
> Also, when you restored the enrypted partition, did you check the
> "Disk" box or just the partition box? I would try with just the
> partition selected, if you didn't.
I did it exactly the same way - no HPA, single OS, partition only.
mbr since the restored data isn't encrypted. If you back up the data
encrypted, it's restored encrypted.
"Peabody" wrote in message news:3488@public.image...
TeraByte Support(PP) wrote:
> What options did you use when you encrypted the drive? My tests were with
> no HPA encryption and a single OS.
>
> Also, when you restored the enrypted partition, did you check the
> "Disk" box or just the partition box? I would try with just the
> partition selected, if you didn't.
I did it exactly the same way - no HPA, single OS, partition only.
Re: Need clarification on IFW and Truecrypt
TeraByte Support wrote:
> If you backup unencrypted, your restore should choose to write a standard
> mbr since the restored data isn't encrypted. If you back up the data
> encrypted, it's restored encrypted.
Well, let me again describe what I'm trying to do, as suggested by Paul. First, I've done Truecrypt whole drive encryption.
I boot the IFL CD, run Truecrypt, mount the C partition (partition only) there, and make a normal IFL image of the Truecrypt-mounted C partition, which image of course contains unencrypted data, used sectors only.
But then to restore that image, I again boot the IFL CD, mount the C partition in Truecrypt, and restore the image to the mounted partition. Truecrypt re-encrypts the data before writing it to the drive.
This process does work on the D partition, but it doesn't work on the C partition using the same settings and options - the computer won't boot. I don't know why. Restoring the Truecypt MBR and Boot Loader didn't help, so I suspect the problem is not in the first track, but somewhere in the restored C partition, but of course don't know that for sure.
If I had a Linux CD that included Truecrypt and a hex/disk editor that would let me copy the first few megabytes of the drive contents to a file on an external hard drive, I could make those files before and after the image/restore, and see exactly what has changed. In theory, nothing should have changed if the computer hasn't been booted into Windows in between. Or, you know, a Terabyte guy could do that, and figure out a way to make this work, and acquire a whole new market for IFW/IFL.
> If you backup unencrypted, your restore should choose to write a standard
> mbr since the restored data isn't encrypted. If you back up the data
> encrypted, it's restored encrypted.
Well, let me again describe what I'm trying to do, as suggested by Paul. First, I've done Truecrypt whole drive encryption.
I boot the IFL CD, run Truecrypt, mount the C partition (partition only) there, and make a normal IFL image of the Truecrypt-mounted C partition, which image of course contains unencrypted data, used sectors only.
But then to restore that image, I again boot the IFL CD, mount the C partition in Truecrypt, and restore the image to the mounted partition. Truecrypt re-encrypts the data before writing it to the drive.
This process does work on the D partition, but it doesn't work on the C partition using the same settings and options - the computer won't boot. I don't know why. Restoring the Truecypt MBR and Boot Loader didn't help, so I suspect the problem is not in the first track, but somewhere in the restored C partition, but of course don't know that for sure.
If I had a Linux CD that included Truecrypt and a hex/disk editor that would let me copy the first few megabytes of the drive contents to a file on an external hard drive, I could make those files before and after the image/restore, and see exactly what has changed. In theory, nothing should have changed if the computer hasn't been booted into Windows in between. Or, you know, a Terabyte guy could do that, and figure out a way to make this work, and acquire a whole new market for IFW/IFL.
Re: Need clarification on IFW and Truecrypt
See the previous post for info on what I'm trying to do.
I've confirmed that the image/restore process of the C partition results in changing the 16 bytes at locations 0x10 through 0x1F of sector 2048, which on my drive is the first sector of the C partition. This is in the middle of the Bios Parameter Block of the C partition, located right after the "NTFS" string. So as I suspected, the problem did not occur in the MBR or even the full first track of the drive, all of which was unchanged. I tested the first 8MB of the drive, and these 16 bytes were the only ones changed.
Because Truecrypt encrypts data 16 bytes at a time, all we know at this point is that at least one byte within the changed block was changed. I'll see if I can get more information on whether the change occurs during the imaging or during the restore. Since both the imaging and restore are not to the partition itself, but to the Truecrypt-mounted version of that partition, it may be that a mounted TC partition has its own BPB which it sends to IFL. Or it could be something IFL is changing. And of course it could be due to a setting I've chosen. In any case, I changed those 16 bytes back to their original values, and Windows boots just fine.
In the Global settings in IFL, I had checked the lines:
Align MBR for Bios Auto
Assume same target system
Use new MBR
Auto scaling limits
All the others were unchecked.
Then under Backup I unchecked Logging, but left the others at defaults
And under Restore, all were unchecked.
I have to believe there is a way to make this reliable. In my experience the changed BPB does not occur in the D partition, or it may be that the new values just happen to be the same as the old ones, so it isn't noticed.
I'll post again when I know more.
I've confirmed that the image/restore process of the C partition results in changing the 16 bytes at locations 0x10 through 0x1F of sector 2048, which on my drive is the first sector of the C partition. This is in the middle of the Bios Parameter Block of the C partition, located right after the "NTFS" string. So as I suspected, the problem did not occur in the MBR or even the full first track of the drive, all of which was unchanged. I tested the first 8MB of the drive, and these 16 bytes were the only ones changed.
Because Truecrypt encrypts data 16 bytes at a time, all we know at this point is that at least one byte within the changed block was changed. I'll see if I can get more information on whether the change occurs during the imaging or during the restore. Since both the imaging and restore are not to the partition itself, but to the Truecrypt-mounted version of that partition, it may be that a mounted TC partition has its own BPB which it sends to IFL. Or it could be something IFL is changing. And of course it could be due to a setting I've chosen. In any case, I changed those 16 bytes back to their original values, and Windows boots just fine.
In the Global settings in IFL, I had checked the lines:
Align MBR for Bios Auto
Assume same target system
Use new MBR
Auto scaling limits
All the others were unchecked.
Then under Backup I unchecked Logging, but left the others at defaults
And under Restore, all were unchecked.
I have to believe there is a way to make this reliable. In my experience the changed BPB does not occur in the D partition, or it may be that the new values just happen to be the same as the old ones, so it isn't noticed.
I'll post again when I know more.
-
TeraByte Support
- Posts: 3760
- Joined: Thu May 05, 2011 10:37 pm
Re: Need clarification on IFW and Truecrypt
If you restored a single partition outside of encryption (and write standard
mbr) it would work, but inside it's saying it's unpartitioned, and so it's
adjusted as such (but it's really not). We'll have to add a some special
processing for restoring to those truecrypt volumes since they mount per
partition instead of mounting one unencrypted physical drive.
"Peabody" wrote in message news:3534@public.image...
See the previous post for info on what I'm trying to do.
I've confirmed that the image/restore process of the C partition results in
changing the 16 bytes at locations 0x10 through 0x1F of sector 2048, which
on my drive is the first sector of the C partition. This is in the middle
of the Bios Parameter Block of the C partition, located right after the
"NTFS" string. So as I suspected, the problem did not occur in the MBR or
even the full first track of the drive, all of which was unchanged. I
tested the first 8MB of the drive, and these 16 bytes were the only ones
changed.
Because Truecrypt encrypts data 16 bytes at a time, all we know at this
point is that at least one byte within the changed block was changed. I'll
see if I can get more information on whether the change occurs during the
imaging or during the restore. Since both the imaging and restore are not
to the partition itself, but to the Truecrypt-mounted version of that
partition, it may be that a mounted TC partition has its own BPB which it
sends to IFL. Or it could be something IFL is changing. And of course it
could be due to a setting I've chosen. In any case, I changed those 16
bytes back to their original values, and Windows boots just fine.
In the Global settings in IFL, I had checked the lines:
Align MBR for Bios Auto
Assume same target system
Use new MBR
Auto scaling limits
All the others were unchecked.
Then under Backup I unchecked Logging, but left the others at defaults
And under Restore, all were unchecked.
I have to believe there is a way to make this reliable. In my experience
the changed BPB does not occur in the D partition, or it may be that the new
values just happen to be the same as the old ones, so it isn't noticed.
I'll post again when I know more.
mbr) it would work, but inside it's saying it's unpartitioned, and so it's
adjusted as such (but it's really not). We'll have to add a some special
processing for restoring to those truecrypt volumes since they mount per
partition instead of mounting one unencrypted physical drive.
"Peabody" wrote in message news:3534@public.image...
See the previous post for info on what I'm trying to do.
I've confirmed that the image/restore process of the C partition results in
changing the 16 bytes at locations 0x10 through 0x1F of sector 2048, which
on my drive is the first sector of the C partition. This is in the middle
of the Bios Parameter Block of the C partition, located right after the
"NTFS" string. So as I suspected, the problem did not occur in the MBR or
even the full first track of the drive, all of which was unchanged. I
tested the first 8MB of the drive, and these 16 bytes were the only ones
changed.
Because Truecrypt encrypts data 16 bytes at a time, all we know at this
point is that at least one byte within the changed block was changed. I'll
see if I can get more information on whether the change occurs during the
imaging or during the restore. Since both the imaging and restore are not
to the partition itself, but to the Truecrypt-mounted version of that
partition, it may be that a mounted TC partition has its own BPB which it
sends to IFL. Or it could be something IFL is changing. And of course it
could be due to a setting I've chosen. In any case, I changed those 16
bytes back to their original values, and Windows boots just fine.
In the Global settings in IFL, I had checked the lines:
Align MBR for Bios Auto
Assume same target system
Use new MBR
Auto scaling limits
All the others were unchecked.
Then under Backup I unchecked Logging, but left the others at defaults
And under Restore, all were unchecked.
I have to believe there is a way to make this reliable. In my experience
the changed BPB does not occur in the D partition, or it may be that the new
values just happen to be the same as the old ones, so it isn't noticed.
I'll post again when I know more.
-
TeraByte Support(TP)
- Posts: 305
- Joined: Wed Aug 31, 2011 4:22 pm
Re: Need clarification on IFW and Truecrypt
Peabody wrote:
> See the previous post for info on what I'm trying to do.
>
> I've confirmed that the image/restore process of the C partition results in
> changing the 16 bytes at locations 0x10 through 0x1F of sector 2048, which
> on my drive is the first sector of the C partition. This is in the middle
> of the Bios Parameter Block of the C partition, located right after the
> "NTFS" string. So as I suspected, the problem did not occur in
> the MBR or even the full first track of the drive, all of which was
> unchanged. I tested the first 8MB of the drive, and these 16 bytes were
> the only ones changed.
>
> Because Truecrypt encrypts data 16 bytes at a time, all we know at this
> point is that at least one byte within the changed block was changed. I'll
> see if I can get more information on whether the change occurs during the
> imaging or during the restore. Since both the imaging and restore are not
> to the partition itself, but to the Truecrypt-mounted version of that
> partition, it may be that a mounted TC partition has its own BPB which it
> sends to IFL. Or it could be something IFL is changing. And of course it
> could be due to a setting I've chosen. In any case, I changed those 16
> bytes back to their original values, and Windows boots just fine.
>
> In the Global settings in IFL, I had checked the lines:
>
> Align MBR for Bios Auto
> Assume same target system
>
> Use new MBR
> Auto scaling limits
>
> All the others were unchecked.
>
> Then under Backup I unchecked Logging, but left the others at defaults
>
> And under Restore, all were unchecked.
>
> I have to believe there is a way to make this reliable. In my experience
> the changed BPB does not occur in the D partition, or it may be that the
> new values just happen to be the same as the old ones, so it isn't noticed.
>
> I'll post again when I know more.
Yes, testing here shows basically the same thing as you are seeing. The bytes that can get changed are at locations 0x18 through 0x1f in the first sector of the C drive (boot sector). Those locations hold the sectors per track, # of heads, and hidden sectors values. It could be as few as 3 of those 8 bytes getting changed, but could be more. These bytes get changed when restoring the image.
To work around this for now, you can back up the first sector the the drive to a file using the 'dd' command, and then restore it from that file using 'dd' after restoring. When you mount a volume with TC in IFL, a corresponding device file will be created in the /dev/mapper directory. The first TC volume mounted will be /dev/mapper/truecrypt1 (aka /dev/dm-0). You can verify that these device files exist with the commands 'ls -l /dev/mapper' and 'ls -l /dev/dm-*'.
Once mounted by TC, you could then backup the first sector with this command:
dd if=/dev/dm-0 of=bootsect.bin bs=512 count=1 (bootsect.bin is the arbitrary filename for the backup)
Then, to later restore the sector from this file:
dd if=bootsect.bin of=/dev/dm-0 bs=512 count=1
That's the simplest form of those commands, but of course since that file will be lost once you reboot from IFL, you will want to save it to a drive/partition. To do that, mount a drive/partition that you want to save it to, and then include the mount point in the 'dd' command. For example, if the drive/partition is mounted at /tbu/mnt1, the 'dd' commands would look like this:
dd if=/dev/dm-0 of=/tbu/mnt1/bootsect.bin bs=512 count=1
dd if=/tbu/mnt1/bootsect.bin of=/dev/dm-0 bs=512 count=1
Also note that there is a hex editor included on the IFL boot disk. For example, to look at the mounted TC volume at /dev/dm-0, open a terminal window and run this command: hexedit -s /dev/dm-0 (the -s tells it to display the file sector by sector)
> See the previous post for info on what I'm trying to do.
>
> I've confirmed that the image/restore process of the C partition results in
> changing the 16 bytes at locations 0x10 through 0x1F of sector 2048, which
> on my drive is the first sector of the C partition. This is in the middle
> of the Bios Parameter Block of the C partition, located right after the
> "NTFS" string. So as I suspected, the problem did not occur in
> the MBR or even the full first track of the drive, all of which was
> unchanged. I tested the first 8MB of the drive, and these 16 bytes were
> the only ones changed.
>
> Because Truecrypt encrypts data 16 bytes at a time, all we know at this
> point is that at least one byte within the changed block was changed. I'll
> see if I can get more information on whether the change occurs during the
> imaging or during the restore. Since both the imaging and restore are not
> to the partition itself, but to the Truecrypt-mounted version of that
> partition, it may be that a mounted TC partition has its own BPB which it
> sends to IFL. Or it could be something IFL is changing. And of course it
> could be due to a setting I've chosen. In any case, I changed those 16
> bytes back to their original values, and Windows boots just fine.
>
> In the Global settings in IFL, I had checked the lines:
>
> Align MBR for Bios Auto
> Assume same target system
>
> Use new MBR
> Auto scaling limits
>
> All the others were unchecked.
>
> Then under Backup I unchecked Logging, but left the others at defaults
>
> And under Restore, all were unchecked.
>
> I have to believe there is a way to make this reliable. In my experience
> the changed BPB does not occur in the D partition, or it may be that the
> new values just happen to be the same as the old ones, so it isn't noticed.
>
> I'll post again when I know more.
Yes, testing here shows basically the same thing as you are seeing. The bytes that can get changed are at locations 0x18 through 0x1f in the first sector of the C drive (boot sector). Those locations hold the sectors per track, # of heads, and hidden sectors values. It could be as few as 3 of those 8 bytes getting changed, but could be more. These bytes get changed when restoring the image.
To work around this for now, you can back up the first sector the the drive to a file using the 'dd' command, and then restore it from that file using 'dd' after restoring. When you mount a volume with TC in IFL, a corresponding device file will be created in the /dev/mapper directory. The first TC volume mounted will be /dev/mapper/truecrypt1 (aka /dev/dm-0). You can verify that these device files exist with the commands 'ls -l /dev/mapper' and 'ls -l /dev/dm-*'.
Once mounted by TC, you could then backup the first sector with this command:
dd if=/dev/dm-0 of=bootsect.bin bs=512 count=1 (bootsect.bin is the arbitrary filename for the backup)
Then, to later restore the sector from this file:
dd if=bootsect.bin of=/dev/dm-0 bs=512 count=1
That's the simplest form of those commands, but of course since that file will be lost once you reboot from IFL, you will want to save it to a drive/partition. To do that, mount a drive/partition that you want to save it to, and then include the mount point in the 'dd' command. For example, if the drive/partition is mounted at /tbu/mnt1, the 'dd' commands would look like this:
dd if=/dev/dm-0 of=/tbu/mnt1/bootsect.bin bs=512 count=1
dd if=/tbu/mnt1/bootsect.bin of=/dev/dm-0 bs=512 count=1
Also note that there is a hex editor included on the IFL boot disk. For example, to look at the mounted TC volume at /dev/dm-0, open a terminal window and run this command: hexedit -s /dev/dm-0 (the -s tells it to display the file sector by sector)