Advanced NTFS Boot and MFT Repair indicates testdisk can copy the MFT of an NTFS partition to the MFT mirror, However, when I run the steps as listed "select your NTFS partition, choose Boot, then Repair MFT" TestDisk offers "Fix MFT mirror using MFT ? (Y/N)" I select Y and get "MFT mirror fixed.." After hitting enter, Im back at the Advanced screen and if I select Repair MFT a second time I see: "MFT and MFT mirror matches perfectly."
But I don't see any option to update the disk with the new MFT mirror, and if I exit TestDisk back through the menues to quit to the operating system and then re run TestDisk and get back to the Repair MFT selection Oops, As I step through the options to create this post, Repair MFT now says ""MFT and MFT mirror matches perfectly."
I've been tearing my hair on this issue as in the past attempts, it had announced "Fix MFT mirror using MFT ? (Y/N)" each time I reentered TestDisk.
My original problem still exists when trying to mount /dev/sda3 on /ntfs
My problem with this file system is that it was abandoned (not deleted) when I ran software to restore the Linux partition located just before the ntfs partition. Both partitions were unavailable after the restore (system booted to Grub-rescue). I've been working a week to recover from this problem beginning with using System Recovery ISO to copy the disk to a new disk of the same size and then attempting all recovery on the copied disk so that when things go wrong, I can recopy and start again.smf@smf-desktop:~$ sudo mount /dev/sda3 /ntfs
Did not find any restart pages in $LogFile and it was not empty.
The file system wasn't safely closed on Windows. Fixing.
ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read NTFS $Bitmap: 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.
smf@smf-desktop:~$
Here's an odd factum: I found an fdisk -l record in the primary boot partition (Dos Windows) in boot-save/log/2017-07-23__01h18boot-repair17 With the fdisk -l section showing:
fdisk -l from the System Recovery ISO shows only up to /dev/sda9 (the non accessible Ubuntu partition.)============================ Drive/Partition Info: =============================
Drive: sda _____________________________________________________________________
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
Partition Boot Start Sector End Sector # of Sectors Id System
/dev/sda1 * 63 6,522,389 6,522,327 b W95 FAT32
/dev/sda2 10,924,261 976,771,071 965,846,811 f W95 Extended (LBA)
/dev/sda5 10,924,263 13,301,819 2,377,557 b W95 FAT32
/dev/sda6 13,301,883 24,226,019 10,924,137 b W95 FAT32
/dev/sda7 24,226,083 35,150,219 10,924,137 b W95 FAT32
/dev/sda8 35,150,283 157,935,014 122,784,732 b W95 FAT32
/dev/sda9 157,935,616 534,755,327 376,819,712 83 Linux
/dev/sda10 534,761,472 972,709,887 437,948,416 7 NTFS / exFAT / HPFS
/dev/sda11 972,711,936 976,771,071 4,059,136 82 Linux swap / Solaris
I used fdisk to create the missing partitions from the above list and was able to mount /dev/sda9 and perform grub-install
and get the system booting the sda9 partition. However, the boot fails to mount the NTFS partititon and I have been
working for a week attempting to fix the problem with TestDisk, Gparted, and some windows tools in Ultimate Boot CD and Win7 PE .
I can run chkdsk on the recreated partition but is looses all the VMWare VMDK drive files (sets them to size zero) in all the Virtual machines I have in the ntfs partition (and a Windows 98 VM that uses Fat32 partition).
My last attempt ( copy disk and start over) I deleted the /dev/sda2 extended partition and then fdisk -l only listed /dev/sda1. I recreated two primary partitions /dev/sda2 and /dev/sda3 with the starting and ending sectors shown above for sda9 and sda10 so that my rebooted system fdisk-l shows:
I created /dev/sda8 that should be above the end of /dev/sda3 and used testdisk to copy the directories and files See Win98 below:Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xcebb4c68
Device Boot Start End Blocks Id System
/dev/sda1 * 63 6522389 3261163+ b W95 FAT32
Partition 1 does not start on physical sector boundary.
/dev/sda2 157935616 534755327 188409856 83 Linux
/dev/sda3 534761472 972709887 218974208 7 HPFS/NTFS/exFAT
/dev/sda4 982711936 1953525167 485406616 5 Extended
/dev/sda5 982714368 1016268799 16777216 82 Linux swap / Solaris
/dev/sda6 1016270848 1528270847 256000000 83 Linux
This failed when the /dev/sda8 244GB file system was filled up. So More data exists for /dev/sda3 then the expected 208GBTestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
3 P HPFS - NTFS 33287 92 22 60548 99 31 437948416
Directory /win98/Windows 98
>dr-xr-xr-x 0 0 0 7-Feb-2019 13:16 .
dr-xr-xr-x 0 0 0 29-Nov-2013 15:20 ..
-r--r--r-- 0 0 1139 16-Sep-2016 23:22 VMFolderList.txt
-r--r--r-- 0 0 10551296 15-Nov-2013 01:39 Windows 98 orig.kdmv
-r--r--r-- 0 0 8684 7-Feb-2019 13:12 Windows 98.nvram
-r--r--r-- 0 0 47960489984 7-Feb-2019 13:12 Windows 98.vmdk
-r--r--r-- 0 0 115 17-Mar-2017 09:14 Windows 98.vmsd
-r--r--r-- 0 0 3356 7-Feb-2019 13:12 Windows 98.vmx
-r--r--r-- 0 0 2481 15-Nov-2013 22:35 Windows 98.vmx_back
-r--r--r-- 0 0 426 17-Mar-2017 08:56 Windows 98.vmxf
-r--r--r-- 0 0 1643636 15-Mar-2017 20:42 vmmcores-4.gz
-r--r--r-- 0 0 1548958 18-Jul-2017 13:48 vmmcores-5.gz
-r--r--r-- 0 0 559326 26-Jan-2019 12:59 vmware-0.log
-r--r--r-- 0 0 252564 18-Jan-2019 19:23 vmware-1.log
Next
Use Left arrow to go back, Right to change directory, h to hide Alternate Data S
treaq to quit, : to select the current file, a to select all files
C to copy the selected files, c to copy the current file
shown in Gparted
So it is obvious that the end of the original NTFS partition is something above the 972709887 ending sector.Filesystem 1K-blocks Used Available Use% Mounted on
udev 7840176 12 7840164 1% /dev
tmpfs 1577024 1420 1575604 1% /run
/dev/sda2 185321476 42408344 133476256 25% /
/dev/sda6 251850484 251834064 0 100% /home/smf/mnt
I need help on finding he true ending sector of /dev/sda10 When I recopy and start over (picked up a new 1TB drive today for the new work).
When I edited this post to clean up the typos and reran TestDisk to get a listing of the Windows 7 VM directory for the TestDisk copy example above all the VDMK files are missing although it was copied to /dev/sda6 prior to running out of disk space. Possibly another indication that /dev/sda3 end block is incorrect and copying from /dev/sda3 to the mounted /dev/sda6 stomped over the sectors formerly containing the
Windows 7 files in the ntfs partition
root@smf-desktop:~# cd /home/smf/mnt
root@smf-desktop:~/mnt# ls -l
total 64
drwxr-xr-x 2 root root 4096 Feb 8 16:05 cpio
drwxr-xr-x 2 root root 4096 Jun 9 2014 downloads
drwxr-xr-x 3 root root 4096 Jun 24 2017 GNSVM
drwxr-xr-x 3 root root 4096 Sep 27 2016 Kali Linux 1.0.6 32 bit
drwxr-xr-x 3 root root 4096 Dec 6 2017 Linux Lite
drwx------ 2 root root 16384 Feb 16 15:49 lost+found
drwxr-xr-x 3 root root 4096 Jul 30 2017 RECYCLER
drwxr-xr-x 3 root root 4096 Jul 30 2017 System Volume Information
drwxr-xr-x 2 root root 4096 Apr 28 2017 TestISOS
drwxr-xr-x 14 root root 4096 Jan 5 2018 Test VMS
drwxr-xr-x 3 root root 4096 Jul 23 2017 vmware
drwxr-xr-x 4 root root 4096 Mar 11 2017 win7
drwxr-xr-x 3 root root 4096 Nov 29 2013 win98
root@smf-desktop:~/mnt#
root@smf-desktop:~/mnt/win7# pwd
/home/smf/mnt/win7
root@smf-desktop:~/mnt/win7# cd Windows*
root@smf-desktop:~/mnt/win7/Windows 7# pwd
/home/smf/mnt/win7/Windows 7
root@smf-desktop:~/mnt/win7/Windows 7# ls -lt
total 156003004
-rw-r--r-- 1 root root 945071 Feb 7 13:11 vmware.log
-rw-r--r-- 1 root root 3559 Feb 7 13:11 Windows 7.vmx
-rw-r--r-- 1 root root 8684 Feb 7 13:11 Windows 7.nvram
-rw-r--r-- 1 root root 4242800640 Feb 7 13:11 Windows 7-s012.vmdk
-rw-r--r-- 1 root root 71671218176 Feb 7 13:11 Windows 7-0.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s001.vmdk
-rw-r--r-- 1 root root 4248895488 Feb 7 13:11 Windows 7-s002.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s003.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s004.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s009.vmdk
-rw-r--r-- 1 root root 4249747456 Feb 7 13:11 Windows 7-s014.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s015.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s006.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s007.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s008.vmdk
-rw-r--r-- 1 root root 4252368896 Feb 7 13:11 Windows 7-s013.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s017.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s005.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 7 13:11 Windows 7-s016.vmdk
-rw-r--r-- 1 root root 4252499968 Feb 6 00:07 Windows 7-s010.vmdk
-rw-r--r-- 1 root root 2571567104 Feb 6 00:00 Windows 7-s011.vmdk
-rw-r--r-- 1 root root 4234608640 Feb 5 23:57 Windows 7-s018.vmdk
-rw-r--r-- 1 root root 4247912448 Feb 5 23:55 Windows 7-s019.vmdk
-rw-r--r-- 1 root root 4252499968 Jan 30 16:24 Windows 7-s021.vmdk
-rw-r--r-- 1 root root 1354 Jan 26 16:29 Windows 7.vmdk
-rw-r--r-- 1 root root 850739 Jan 26 12:41 vmware-0.log
-rw-r--r-- 1 root root 4252499968 Jan 26 12:32 Windows 7-s020.vmdk
-rw-r--r-- 1 root root 427884544 Jan 26 12:28 Windows 7-s022.vmdk
-rw-r--r-- 1 root root 399537 Jan 18 19:44 vmware-1.log
-rw-r--r-- 1 root root 2024553 Jan 16 23:50 vmware-2.log
-rw-r--r-- 1 root root 115 Sep 27 10:57 Windows 7.vmsd
-rw-r--r-- 1 root root 6487030 Aug 14 2018 vmmcores-13.gz
-rw-r--r-- 1 root root 3906 Jul 29 2017 Windows 7.vmxf
-rw-r--r-- 1 root root 4980206 Mar 15 2017 vmmcores-12.gz
-rw-r--r-- 1 root root 173 Mar 11 2017 Windows 7.dsmvvmsd
-rw-r--r-- 1 root root 49235352 Sep 16 2016 vm-2016-09-16.19881.tgz
-rw-r--r-- 1 root root 1893 Sep 16 2016 VMFolderList.txt
drwxr-xr-x 3 root root 4096 Apr 20 2016 caches
root@smf-desktop:~/mnt/win7/Windows 7#
Even though the above shows vmdk's VMWare Workstation 11 fails to see the disks so there is no confirmation that they were copied correctly.
I will start back at a new copy of the original disk and post the quick scan results for Testdisk before any other attempts are made to recover the NTFS partition.
