1

Testdisk deep search is unable to detect the correct partition table for /dev/sdb, after starting the PC from DVD (Ubuntu 14.04 LTC Trusty Tahr - Release amd64 (20140417)), and experiencing the following invasive action right at the beginning of the DVD startup:

Unable to open '/dev/dm-0'
The disk contains an unclean file system (0, 0).
The file system wasn't safely closed on Windows. Fixing.
The disk contains an unclean file system (0, 0).
The file system wasn't safely closed on Windows. Fixing.
The disk contains an unclean file system (0, 0).
The file system wasn't safely closed on Windows. Fixing.

Unable to open '/dev/sdb'
The disk contains an unclean file system (0, 0).
The file system wasn't safely closed on Windows. Fixing.

Unable to open '/dev/sdd'
/init: line 7: can't open ?????? (my edit: maybe /dev/sr0): No medium found
Generating locales...

My guess is that /dev/dm-0 refers to /dev/sdc, because it was the only drive to have 3 partitions at that point, and there are 3 file system fixes listed for this drive. /dev/dm-0 (shown as /dev/sdc by Testdisk) is also a designation for part of a RAID volume, of which /dev/sdb is the second drive in what Ubuntu (wrongly) thought is an active RAID array.

This /dev/dm-0 designation is a wrong carry-over from a botched Intel Rapid Storage Driver installation that happened when Windows was installed the first time, this Intel Driver tried to pair 2x 1.5 TB drives (/dev/sdc & /dev/sdb) together in a RAID array without warning. Windows was promptly reinstalled without this Intel Driver and the partition table of /dev/sdb was recovered after the install with Testdisk, this was more than a year ago.

The PC worked fine since then with Windows 7, until I tried to start an Ubuntu DVD simply to Try Ubuntu today. How unfortunate that it would overwrite partition tables and filenames right at startup, without even a hint of a prompt or agreement from my side.

The current drive configuration in the PC is as follows:

Disk /dev/sda - 1500 GB / 1397 GiB - Samsung HD154UI
Disk /dev/sdb - 1500 GB / 1397 GiB - ST31500341AS
Disk /dev/sdc - 1500 GB / 1397 GiB - ST31500341AS
Disk /dev/sdd - 200 GB / 186 GiB - ST3200826AS

/dev/sda:   [1397.26 GiB NTFS (Healthy, Primary)]
/dev/sdb:   should be [1251 GB NTFS] [249 GB NTFS], but currently is 
                    offline [774.57 GiB][390.63 GiB][232.07 GiB]
/dev/sdc:   [774.57 GiB NTFS (Healthy, Primary, Active)] [390.63 GiB NTFS Healthy, Primary]
                    [232.07 GiB Unallocated]
/dev/sdd:   [100 MiB NTFS (Healthy, System, Primary, Active)] [186.21 GiB NTFS (Healthy, Boot, Primary)]

The approximately correct partition table of /dev/sdb, the drive I want to recover, is as follows, although I'm not 100% sure:

Disk /dev/sdb - 1500 GB / 1397 GiB - CHS 182401 255 63
Partition       Start           End         Size in sectors
1 * HPFS - NTFS 0 32 33         152106 139 33   2443599146  [Piet]  (1251 GB)
2 P HPFS - NTFS 152107    0   1     182400 254 63     486673110     [Files]     (249 GB)

It could also maybe be, although in that case partition #2 was never seen or used, and I only want to recover partition #1 and #3.

Disk /dev/sdb - 1500 GB / 1397 GiB - CHS 182401 255 63
Partition       Start           End         Size in sectors
1 * HPFS - NTFS 0 32 33         x x x   1956926036  [Piet]  (1002 GB)
2 P HPFS - NTFS x   x   x   152106 139 33     486673110     [?]     (249 GB)
3 P HPFS - NTFS 152107    0   1     182400 254 63     486673110     [Files]     (249 GB)

A Testdisk Quick Search reveals the following partition table for /dev/sdb:

Disk /dev/sdb - 1500 GB / 1397 GiB - CHS 182401 255 63
Partition       Start           End         Size in sectors
1 * HPFS - NTFS 0 32 33         10113 179 58    1624389632  [Francois Files]    (831 GB)
2 P HPFS - NTFS 101113 179 59   152106 139 33     819200000                     (419 GB)
3 P HPFS - NTFS 152107    0   1     182400 254 63     486673110     [Files]     (249 GB)

(NTFS, blocksize=4096, 831 GB / 774 GiB)
(NTFS, blocksize=4096, 419 GB / 390 GiB)
(NTFS, blocksize=4096, 249 GB / 232 GiB)

After Testdisk Deep Search the following is displayed for /dev/sdb:

Disk /dev/sdb - 1500GB / 1397 GiB - CHS 182401 255 63

The harddisk <1500 GB / 1397 GiB> seems too small! << 1749 GB / 1629 GiB>
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partitions can't be recovered:
Partition       Start           End         Size in sectors
FAT16 LBA       155655 200 54   186533 126 25   496050380       (253 GB)
HPFS - NTFS 182400 254 63   212694 254 62   486673110

After pressing [Enter] the following Deep Search result for /dev/sdb is shown, but it is wrong.

Disk /dev/sdb - 1500 GB / 1397 GiB - CHS 182401 255 63
Partition       Start           End         Size in sectors
HPFS - NTFS 0 32 33         10113 179 58    1624389632  [Francois Files]    (831 GB)
HPFS - NTFS 0 32 33         182401 35 34    2930272256  [Francois Files]    (1500 GB)
HPFS - NTFS 101113 179 59   152106 139 33     819200000                     (419 GB)
HPFS - NTFS 152107    0   1     182400 254 63     486673110     [Files]     (249 GB)

    (NTFS, blocksize=4096, 831 GB / 774 GiB)
    (NTFS found using backup sector, blocksize=4096, 1500GB / 1397 GiB)
    (NTFS, blocksize=4096, 419 GB / 390 GiB)
    (NTFS, blocksize=4096, 249 GB / 232 GiB)

When [P] is pressed for each listed partition, the files that are shown for partition #1 [Francois Files], and partition #3 [419 GB] are exactly the files that are on the two partitions as they appear on the other 1.5TB drive /dev/sdc, so the filenames and foldernames were also copied from /dev/sdc to /dev/sdb by the Ubuntu DVD, like the partition table, which was completely invasive and undesired.

Partition #2 [Francois Files] (1500 GB) cannot find a valid file system, and Partition #4 [Files] actually shows the correct files for the correct partition, so now only the first correct partition must be recovered.

Please take note of the partition table of the other 1.5TB drive, /dev/sdc, and notice how the Ubuntu DVD copied this partition table of /dev/sdc to /dev/sdb. But, not only was the partition table copied to /dev/sdb, but also the file names and folders (MFT?).

Disk /dev/sdc - 1500 GB / 1397 GiB - CHS 182401 255 63
Partition       Start           End         Size in sectors
1 * HPFS - NTFS 0 32 33         10113 179 58    1624389632  [Francois Files]    (831 GB)
2 P HPFS - NTFS 101113 179 59   152106 139 33     819200000                     (419 GB)

    (NTFS, blocksize=4096, 831 GB / 774 GiB)
    (NTFS, blocksize=4096, 419 GB / 390 GiB)

I am desperate to recover the exact partition table of /dev/sdb, in particular the first partition as it was before I started the Ubuntu DVD, which was a truly regrettable action of which I never would've imagined it would do something so invasive without even a prompt, right at the startup. Luckily I had the presence of mind to take a photo with my cellphone when I saw the 'fixing' messages as the DVD booted up.

Is it possible to try something more than the Testdisk Deep Search to try and recover the partition table?

I feel that this question is appropriate for AskUbuntu, because it very much pertains to how Ubuntu tried to fix a partition table, under the wrong assumptions due to an incorrect disk designation. Maybe we can get an answer as to the exact process or program that was used in the Ubuntu DVD startup that fixes disk issues.

Testdisk.log

Screenshots

0

You must log in to answer this question.

Browse other questions tagged .