Windows – NTFS partition broke: Won’t mount in Linux & Windows won’t boot

A friend dropped her Acer Aspire One KAV10 on the ground while it was still powered on and it restarted with "No boot device found" "PXE-M0F" etc. Your problem seems similar but your solution wasn't really that intuitive so I'd like to elaborate on what I did to fix it.

I burnt a copy of UBCD511, booted into Parted Magic (using defaults), opened xterm and used TestDisk to:

1. Restore the NTFS boot sector
2. Recover the ACER partition table

Recovering an NTFS Boot Sector from an NTFS Partition using its backup

From TestDisk:

• [No log]
• Select disk
• [Intel]
• [Advanced]
• If "Sectors are not identical." appears then:
• [BackupBS]

[q] to return to the previous menu

Recovering the ACER partition table

From TestDisk:

• [No log]
• Select disk
• [Intel]
• [Analyse]
• [Quick Search]
• [Y] for Vista (just default it to Y)

It should have something like:

* HPFS - NTFS [PQSERVICE]

P HPFS - NTFS

• Use [up]/[down] arrows to select the non-PQSERVICE partition
• [p] to list the files
• If the list of files looks complete messed up then go back to the list of partitions by pressing [q]
• [Enter]
• [Deep search]
• After about 1,000 cylinders have been searched you should have about 3-4 partitions listed. If so, press [Stop]
• Use the [up]/[down] arrows to select the PQSERVICE partition
• Use the [left]/[right] arrows to change the type from * (boot) to P (primary)
• Use the [up]/[down] arrows to select the ACER partition
• [p] to list the files
• If the files don't look ok then go back with [q] and look at another partition
• If the files look ok then [C] copy the files to an external hard drive if you want to
• Use the [left]/[right] arrows to change it from D (deleted) to * (boot)
• [Enter]
• Confirm and reboot

Windows XP should now load.

I'm posting this for the benefit of others if they find themselves in a similar situation, and as a reminder if I've to do this again.

Tim.

If it is the USB drive, and it is size-related, then the USB drive is failing to correctly process a sector write (and probably read, too) request. The file size does not matter. The cause is that the larger file has "pieces" falling beyond the addressable boundary.

Due to disk fragmentation, it is difficult to confirm or deny this hypothesis, but you can try with any tool which displays the disk fragmentation map. This should display a large disk with the beginning which is filling up, and nothing past a certain point. Not at the end, especially.

On a FAT32 disk you could try and fill the disk with small files, each 8Kb in size, until the "reachable" area was filled up and the disk became unwriteable. But the disk is NTFS and however the method isn't really very precise, or certain.

If at all possible, I would mount the disk on a Linux live distribution. At that point you could try and read the disk one sector at a time:

fdisk -l

will tell you how many 512-byte blocks are there in the external disk. Then

dd bs=512 if=/dev/sdc of=test skip=NNNNN count=1

will request a read of sector NNNNN (one-based :-) ).

If it is a matter of a limit to NNNNN, you will observe that:

N=1         it works
N=MAX_NUM   it fails
N=MAX_NUM/2 it fails

...

so you can start with a classic bisection algorithm and determine where the critical sector "C" lies (any sector before C is readable, any after is not). If such a sector exists, you've got either an incredibly weird hardware damage, or the proof you were looking for of the enclosure's guilt.

Update - finding the boundary by bisecting: an example

So let's say the disk is 4TB, so 8,000,000,000 sectors. We know that sector 1 is readable and sector 8-billion isn't. Let READABLE be 1, let UNREADABLE be 8. Then the algorithm is:

 let TESTING be (READABLE + UNREADABLE)/2
 if sector TESTING is readable then READABLE becomes equal to TESTING
 else, UNREADABLE becomes equal to TESTING.
 Lather, rinse, repeat with the new values of (UN)READABLE.
 When two consecutive values of TESTING are obtained, that's your boundary.

Let's imagine the boundary lies at sector 3,141,592,653 because of some strange bug in the enclosure.

 first pass: testing = (1 + 8000000000)/2 = 4000000000.
 4,000,000,000 is unreadable, so replace 8,000,000,000 with 4,000,000,000
 second pass: testing (1 + 4M)/2 = 2M
 sector 2M is readable, so replace 1 with 2,000,000,000
 third pass: testing (2M + 4M)/2 = 3M
 sector 3,000,000,000 is readable
 fourth pass: testing (3M + 4M)/2 = 3,500,000,000 which is UNREADABLE
 fifth: (3 + 3.5) / 2 = 3,250,000,000 UNREADABLE
 ...

So READABLE and UNREADABLE stalk the unknown boundary more and more closely, from both directions. When they are close enough you can even go and try all the sectors in between.

To locate the boundary, only log2(max - min) = log2(4TB - 0) = log2(4TB) = log2(2⁴⁰) = 40 (actually I think perhaps 42) sectors need to be read. Given a 30" reset delay on the enclosure when a reading error occurs, that should be 20 minutes at the most; probably much less.

Once you have the boundary B, to confirm it is a boundary you can do a sequential read of large chunks before B (this will not take too long), maybe one megabyte every gigabyte or so; and then a random sampling of sectors beyond B. For example the first 4*63 sectors beyond the boundary, then one sector every 3905 (or every RAND(4000, 4100) ) to try to avoid hitting always the same magnetic platter.

But actually, if you do find a boundary-like behaviour, and confirm that with another enclosure there is no such boundary -- well, I'd declare the case (en)closed.