1TB ext4 hdd was unreadable with the help of ChatGPT now works again

The situation is quite simple: I have a hard drive that I’ve owned for 10 years; Linux was no longer detecting it, even though it was formatted with ext4.

I decided to test the AI ​​to check the drive and see what commands it would recommend to get it working again.
I didn’t want to use TestDisk because it would have resulted in a huge number of disorganized files; I wanted to find out if the partition table was corrupted.

In the end, after two days, it turned out that only the partition table sectors were damaged. Here is the timeline of events:

Linux detected the disk itself:

/dev/sda 931.5G disk TOSHIBA MQ01ABD100

and also detected a partition:

/dev/sda1 931.5G part

All the commands were generated by ChatGPT (that I checked before executing them).

First Attempt: TestDisk

TestDisk reported an Intel/MBR partition table and showed a partition:

1 P Linux 0 1 1 121600 254 63 1953520002

The partition occupied essentially the entire disk.

However, TestDisk could not find a recognizable ext2/ext3/ext4 filesystem during its analysis (and I didn’t remember what was the partition type).

More importantly, its debug output contained errors such as:

file_pread(...) read err: Error input/output

At this point the problem was no longer simply “the partition table is missing.”

The disk itself was having trouble reading certain sectors.

I then used:

file -s /dev/sda

which reported:

DOS/MBR boot sector

But the partition told a very different story:

file -s /dev/sda1

returned:

Linux rev 1.0 ext4 filesystem data,
UUID=e5f6ef47-5e23-4209-a374-09f6a8348cf1,
volume name "ADATA"

The partition contained an ext4 filesystem and it had a recognizable UUID and volume label:

UUID: e5f6ef47-5e23-4209-a374-09f6a8348cf1

Label: ADATA

So the filesystem itself was not necessarily gone.

Creating a Recovery Image with GNU ddrescue

I did not initially have another 1 TB disk available specifically for the recovery image, but eventually I was able to create one.

I used GNU ddrescue:

ddrescue -f -r3 /dev/sdg /run/media/mte90/bighdd/sdg.img /run/media/mte90/bighdd/sda.log

The important part is that ddrescue works differently from a simple dd.

It is designed specifically for failing disks. It records which areas were successfully copied and which areas could not be read in a mapfile.

After approximately 3.5 hours, the result was:

rescued: 1000 GB

pct rescued: 99.99%

read errors: 33

bad areas: 1

bad-sector: 4096 B

The ddrescue mapfile contained:

0x00000000 0x00008000 +

0x00008000 0x00001000 -

0x00009000 0xE8E0DAD000 +

The - region represented the unreadable portion.

The important result was that 99.99% of the disk was fine.

The image was approximately the full size of the original disk, not merely the amount of space occupied by files.

So I mounted the image instead of working on the damaged disk.

With various commands the filesystem metadata where there including all my files (after I mount the image).

After various test in read-only the AI generated the command to exclude the sector damaged and regenerate a new one: `e2fsck -f -y -b 32768 /dev/sdd1`

Conclusion

The AI was very cautious but when I discovered that it was fine and I had the dd img, I didn’t wanted to recover the file and instead fix the partition table.
At the end of the day the files were copied and safe, the experience was interesting to learn how works a bit the file system and also about the various sectors because n this case 63 was important as store the partition table.

Liked it? Take a second to support Mte90 on Patreon!