[Linux, Testdisk] Should I repair partition table with wrong sector size due to USB-adapter but on a disk with errors?
Posted: 21 Apr 2023, 00:15
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:
While fdisk -l gives me this wrong partition:
dmesg spills the following when the disk is first accessed by smartctl:
This message is repeated for logical blocks from 0 to 7 and sectors 0 to 7, but only once.
gdisk also informs me this:
By issuing hdparm -N /dev/sdc I get the following
According to SMART the disk seems fine:
Checking with dumpe2fs /dev/sdc it attest the problem with the partition table being recognized with MBR and with wrong superblock information:
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:
Running gdisk with verify option v reports this:
Running the e expert command and then verifying again with v also reported 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!
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 976754383Code: Select all
Device Boot Start End Sectors Size Id Type
/dev/sdc1 1 976754378 976754378 3,6T ee GPTCode: 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 2gdisk 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.
****************************************************************************Code: Select all
/dev/sdc: max sectors = 7814035055/1(7814037168?), HPA setting seems invalid (buggy kernel device driver?)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_testingCode: 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)' dataCode: 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: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!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!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!