[Linux, Testdisk] Should I repair partition table with wrong sector size due to USB-adapter but on a disk with errors?

[autogris]

Hi, I'm new to Testdisk and need advice on how to proceed with this repairing. I have a 4TB WD hdd (with sector size of 512e/4096) that was first formatted as GPT/ext4 with an usb-sata enclosure/adapter on a Raspberry Pi 3. Apparently the load was too much for Rpi3, and inconsistency on usb port voltage eventually fried the enclosure. This enclosure controller was one of those which "translated" sector size of larger disk to 4096 for the OS, while the disk itself had the emulated 512e sector size to the enclosure. So trying to access it without that enclosure won't find the partition correctly.

On Testdisk, without that enclosure, setting geometry of the sector size to 4096 and indicating a GPT table, I can access the content and apparently everything is ok regarding data. I wasn't sure if writing this partition on Testdisk was the right step right away, because I changed the geometry sector size. To double check I bought an exact same enclosure that was used to format the disk in the first place. To my surprise fdisk also saw a corrupted partition table, suggesting the disk itself was corrupted with the voltage fluctuation. So i further investigated:

The partition listed correctly with changed sector size and partition table as GPT, through Testdisk, is this:

Code: Select all

Disk /dev/sdc - 4000 GB / 3726 GiB - CHS 476930 64 32
     Partition               Start        End    Size in sectors
   P Linux filesys. data          256  976754638  976754383

While fdisk -l gives me this wrong partition:

Code: Select all

Device     Boot Start        End    Sectors Size Id Type
/dev/sdc1           1 976754378 976754378  3,6T ee GPT

dmesg spills the following when the disk is first accessed by smartctl:

Code: Select all

sd 3:0:0:0: [sdc] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
Buffer I/O error on dev sdc, logical block 0, async page read
sd 3:0:0:0: [sdc] tag#21 device offline or changed
I/O error, dev sdc, sector 1 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2

This message is repeated for logical blocks from 0 to 7 and sectors 0 to 7, but only once.
gdisk also informs me this:

Code: Select all

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

By issuing hdparm -N /dev/sdc I get the following

Code: Select all

/dev/sdc:  max sectors   = 7814035055/1(7814037168?), HPA setting seems invalid (buggy kernel device driver?)

According to SMART the disk seems fine:

Code: Select all

SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.
,,,,
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   171   167   021    Pre-fail  Always       -       6441
  4 Start_Stop_Count        0x0032   093   093   000    Old_age   Always       -       7730
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       7018
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       54
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       39
193 Load_Cycle_Count        0x0032   193   193   000    Old_age   Always       -       21893
194 Temperature_Celsius     0x0022   117   109   000    Old_age   Always       -       33
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing

Checking with dumpe2fs /dev/sdc it attest the problem with the partition table being recognized with MBR and with wrong superblock information:

Code: Select all

dumpe2fs: Bad magic number in super-block while trying to open /dev/sdc
Couldn't find valid filesystem superblock.
/dev/sdc contains `DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 976754643 sectors, extended partition table (last)' data

I tried to fix this by copying with fsck -b and fsck.ext4 -p -b 32768 -B 4096 /dev/sdc the available superblocks backups (found with mke2fs -n) but all of them failed because couldn't be read as ext4 valid information:

Code: Select all

# fsck -b 32768 /dev/sdc

fsck from util-linux 2.38.1
e2fsck 1.47.0 (5-Feb-2023)
/sbin/e2fsck: Bad magic number in super-block while trying to open /dev/sdc

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:

Running gdisk with verify option v reports this:

Code: Select all

Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 976754379 sectors, needs to be 976754644 sectors.)
The 'e' option on the experts' menu may fix this problem.

Warning: There is a gap between the main partition table (ending sector 5)
and the first usable sector (256). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using 'j' on the experts' menu can adjust this gap.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 976754638, but backup header is at
976754643 and disk size is 976754379 sectors.
The 'e' option on the experts' menu will probably fix this problem

Problem: partition 1 is too big for the disk.

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Caution: Partition 1 doesn't end on a 256-sector boundary. This may
result in problems with some disk encryption tools.

Identified 6 problems!

Running the e expert command and then verifying again with v also reported problems:

Code: Select all

Expert command (? for help): e
Relocating backup data structures to the end of the disk

Expert command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Warning: There is a gap between the main partition table (ending sector 5)
and the first usable sector (256). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using 'j' on the experts' menu can adjust this gap.

Problem: partition 1 is too big for the disk.

Warning! Secondary partition table overlaps the last partition by
515 blocks!
You will need to delete this partition or resize it in another utility.

Caution: Partition 1 doesn't end on a 256-sector boundary. This may
result in problems with some disk encryption tools.

Identified 3 problems!

I didn't wrote the changes to the disk, as I feared it could introduce more problems that would turn impossible to backup from Testdisk.

And I'm not sure about what really happened to the disk, but I guess is not a physical damage, just logical. My question is: should I just force Testdisk to write the partition found with the correct geometry or should I try to fix this problem first? What you suggest for fixing it?

Also, as a newbie to Testdisk, what would be the correct steps to write the partition table (SAFELY, WITHOUT LOSING THE DATA) in a situation where i changed the geometry of the sector size to find the partition? My goal is set the partition table to work without the enclosure and preferably with 4096 sector size instead of 512 emulation (but if the only option is using 512 emulation it would be ok also).

Thank you!

[cgrenier]

I don't like the error messages about the first sectors.
Run TestDisk, select /dev/sdc, EFI GPT, do not change the geometry, Analyse, Quick Search, if your partition is listed, try 'p' to list the files, if it works, use 'q' to stop the file listing, choose Write, confirm, Quit.
Restart your computer. You should be able to mount the partition /dev/sdc1 and access your data.

[autogris]

Thanks. But it won't see the partition without changing sector size because the filesystem/partition table was created with an enclosure that simulated a 4096 sector, without that enclosure the disk itself presents a 512 sector size so it won't align. The problem is similar to one described here https://superuser.com/questions/1562160 ... that-trans . I wonder if by changing the geometry in Testdisk and writing that partition information to the disk will have the correct sector size (is this information written in the partition table itself or somewhere else?) and if it has any risk of overflowing into the section which contains the actual data for the files.

Edit: I noticed this morning that maybe the error blocks may be related to the fact that I'm using a dock hub (which does not translate the sector size but present as it is to the OS), turning it on without a disk attached present a similar dmeg log. But still the other finding with gdisk and HPA error, makes me uncertain what really happened to make the partition broken in the first place, even with the original "translating" enclosure used again.

[recuperation]

Thanks. But it won't see the partition without changing sector size because the filesystem/partition table was created with an enclosure that simulated a 4096 sector, without that enclosure the disk itself presents a 512 sector size so it won't align. The problem is similar to one described here https://superuser.com/questions/1562160 ... that-trans . I wonder if by changing the geometry in Testdisk and writing that partition information to the disk will have the correct sector size (is this information written in the partition table itself or somewhere else?) and if it has any risk of overflowing into the section which contains the actual data for the files.

No, the sector size is not part of the information stored in the Master boot record nor it is an information that is contained in a MBR- or GPT-style partition table.
If you can access your data as you described you can copy the content of your possibly dammaged disk to a new one on file-level. This way you are not affected by the 512/4096 translation issue.

Edit: I noticed this morning that maybe the error blocks may be related to the fact that I'm using a dock hub (which does not translate the sector size but present as it is to the OS), turning it on without a disk attached present a similar dmeg log. But still the other finding with gdisk and HPA error, makes me uncertain what really happened to make the partition broken in the first place, even with the original "translating" enclosure used again.

Rule out that possibility by connecting your disk directly to the SATA connectors of a mainboard.

[autogris]

Ok, I am preferably looking for a "fix the partition" solution because at the moment I only have access to a laptop with a dock hub (no direct sata access) and a spare hdd that won't fit the 4TB for backing up.

So: 1)if i write the partition after identifying it with the correct sector size on Testdisk I could then theoretically mount it with losetup or something similar by specifying that 4096 geometry to the command line, right?

2) considering that Testdisk found the partition at sector 256, reconstructing the GPT table won't mess the file data section of the disk? If I understand it right, it fits right before that 256 starting point and also recreates a backup and the ending bytes of the disk, correct?

3) just double checking: by writing the partition table found on Testdisk by changing sectorsize/geometry, and since the sector information is not written on table or partition itself, chances of messing up the file/data section of the disk to a point becoming unrecoverable later with Testdisk are very low, right?

Thanks.

[Maximice]

Did you managed to solve it?