Hi,

I get the following error message when I try to mount 3TB large external USB hard drives with an AES encrypted NTFS partition with TrueCrypt on Odroid C1:

Error: Incomplete multi-sector transfer: magic: 0x454c4946 size: 4096 usa_ofs: 48 usa_count: 4 data: 8609 usn: 2: Input/output error
Record 1 has no FILE magic (0x44414142)
Failed to open inode $MFTMirr: Input/output error
Failed to load $MFTMirr: Input/output error
Failed to mount '/dev/loop0': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

chkdsk /f on Windows finds no errors and so repairs nothing.

The hard drives work on Windows, as well as Debian Wheezy (3.12.35+ # 730 PREEMPT Fri Dec 19 18:31:24 GMT 2014 armv6l - ntfs-3g 15/01/2012) on a RaspberryPi without problems/errors.
Error seems to occur only with hard drives with a sector size of 4KB and Odroid C1. Sector size of 512B is no problem.

The error occurs with the following variants/versions:

2 different WD Elements Desktop 3TB 4KB sector size USB 2.0; WD Elements Desktop 3TB 4KB sector size USB 3.0

Ubuntu 14.04.1 LTS 3.10.66-47 # 1 SMP PREEMPT Fri January 30 20:32:58 BRST 2015 armv7l armv7l armv7l GNU / Linux
Debian Wheezy 03/10/44 - g7302e7a # 1 SMP PREEMPT Sun January 11 08:35:07 CST 2015 armv7l GNU / Linux

ntfs-3g 2014.2.15
ntfs-3g 2013.1.13
ntfs-3g 2012.1.15

truecrypt 7.1a

Who can help or isolate the problem further?
I would be very grateful for any advice!
Thanks in advance for your help/effort/time.

Hi,


The magic header is wrong, and the usa_count should be 8 for a cluster size of 4096.

Was the file system formatted for 4K sectors ? Even when having formatted for 512 bytes, it is usable on computers which have a 512 byte emulation for 4K sectors. Please post the output of


Do not use an ntfs-3g earlier than 2013.1.13AR.2, a bug related to 4K sectors was fixed in that version (ntfs-3g 2013.1.13 is earlier than 2013.1.13AR.2). Please indicate which ntfs-3g version is behaving improperly (Ubuntu or Debian versions are probably unrelated to the issue).

If your drive is correctly accessed on Ubuntu or Debian, and not on Odroid with the same ntfs-3g version, the bug is probably not in ntfs-3g.

Regards

Jean-Pierre

Hi again,



Ok, so I wonder why it works on other systems.



puts out:


Today, i get Arch Linux (3.10.66-1-ARCH #1 SMP PREEMPT Wed Jan 28 18:12:35 MST 2015 armv7l GNU/Linux ntfs-3g 2014.2.15) to work on the Odroid-C1 for test purposes and I wonder, drives work without problems. So I think it's not a C1 problem.

Thank you for the quick response!

Regards

Hi,


What is the ntfs-3g version which went into this error ?

This is formatted for 4K sectors.

If you got the error with a recent ntfs-3g version, please post the contents of sectors 786432 and 786433 (and/or sectors 2 and 3, which should be the same) :

Please compress the output (required by this forum), and post as an attachment.

Regards

Jean-Pierre

Hi,


Like I wrote, the error occurs with the 3 versions I tried:
ntfs-3g 2014.2.15,
ntfs-3g 2013.1.13 and
ntfs-3g 2012.1.15.

The result of

is attached. (Sectors 2 and 3, are the same, like you wrote)

Many Thanks again.

Regards

Hi,

First, I have to correct my diagnosis on the error :

The magic value is correct, and the usa_count is actually a decremented count, with the value 4 meaning the error was detected at the end of the fourth 512-byte record (out of eight) in the second sector of the MFT. In the contents of the sectors you sent, there is no such error. To get the same error, I have inserted 8609 (0xa1 0x21) at the location which corresponds to 013776 (octal) in your sector dump.

The error occurs in a consistency check intended to make sure the sector was fully written and has been fully read, and the error message means that less than half the sector has been fed in. As the magic value and the usa_offs are correct, the correct sector is likely to have been read. In the error message the usn is 2, but in the sector dump it is 4, probably because you ran chkdsk in the meantime and it had to fix something in that record.

Note that the record 1 is the second record being read for mounting, the first one is record 0 which presumably was fully read with no error. This tends to discard the possibility of a buffer truncation in the device driver or in the decryption process.

I cannot explain further, more information may help :

- Does the error consistently happen at the same location ?
- If so, does it show the same data value (8609) or a slightly bigger one ?
- Was your sector dump made in the same conditions as the error ?

Regards

Jean-Pierre

Hi,



I'm not sure what you mean. Error appears always when I try to mount the external encrypted USB Drive with 4KB sector size on an Odroid-C1 with Ubuntu (14.04.1 LTS (GNU/Linux 3.10.67-55 armv7l)).



Indeed the data value and also the usn value are not always equal. Sorry that I haven't noticed earlier. I wrote a script which mount automatically 1000 times and therefore nine different errors appears randomly. Three of them with over 96% proportion.

42,9%:


30,1%:


23,2%:


<1%:


So the error message (in the second record) I posted at the beginning wasn't typical. Sorry again. (But error remains error)



Previously, I made the sector dump on the RaspberryPi, because it works only there. Errors appeared only on the Odroid-C1.
Today, I looked again (on Odroid-C1) and noticed that dump is still equal.

By the way - I'm now able to mount correctly on the Odroid-C1 because of a kernel-update (as a result on a inquiry in the Odroid forum). This allows truecrypt to use directly crypto ciphers which implemented in the kernel (I think it's closer to low-level programming and therefore in comparison very quick). Before, I had to set a switch in truecrypt not to used the missing kernel-ciphers. This is also possible on the RaspberryPi without errors (only slower).
Maybe this point is an another hint.

Nevertheless, I'm very thankful for your dedication.
From now it's not important for me to work further on the problem, because of what I pointed out above.
But I would love to continue to help to pinpoint the fault.

Regards

Hi,


I wanted to know if you always get the same error parameters. From your tests, I see the error may occur either in record 0 or record 1. When it occurs in record 0, the usn is always 19266 which is the value shown in your sector dump, but the data (which should be the same as the usn), show several unexpected values. So, most likely, bad buffer contents are fed into ntfs-3g.

Good news.

Most likely there is something wrong in your initial procedure. Is this procedure compatible with 4K encryption blocks ? You said you get no error with 512-byte sectors, and in your error samples, the first 512 bytes of a 4K block are correct.

Regards

Jean-Pierre