0

I'm trying to read old IDE disks through an USB adapter on my Linux Mint machine. One issues a "Can't read superblock on /dev/sdb1" when I try to mount it. I use dumpe2fs to get the superblock :

sudo dumpe2fs /dev/sdb1 | grep superblock [sudo] password for mc: dumpe2fs 1.47.0 (5-Feb-2023) Primary superblock at 0, Group descriptors at 1-1 Backup superblock at 32768, Group descriptors at 32769-32769 Backup superblock at 98304, Group descriptors at 98305-98305 Backup superblock at 163840, Group descriptors at 163841-163841 Backup superblock at 229376, Group descriptors at 229377-229377 Backup superblock at 294912, Group descriptors at 294913-294913 Backup superblock at 819200, Group descriptors at 819201-819201 Backup superblock at 884736, Group descriptors at 884737-884737 Backup superblock at 1605632, Group descriptors at 1605633-1605633 Backup superblock at 2654208, Group descriptors at 2654209-2654209

That gives me the value needed : 32768 Then I can use it to perform a fsckcommand:

sudo fsck -b 32768 /dev/sdb1 fsck from util-linux 2.39.3 e2fsck 1.47.0 (5-Feb-2023) /dev/sdb1 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Inode 10642 extent tree (at level 1) could be shorter. Optimize<y>? yes Pass 1E: Optimizing extent trees Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong for group #0 (23866, counted=1085). Fix<y>? yes Free blocks count wrong for group #1 (32080, counted=317). Fix<y>? yes Free blocks count wrong for group #2 (32768, counted=1008). [long list of messages] Directories count wrong for group #82 (0, counted=621). Fix? yes Free inodes count wrong (703125, counted=430832). Fix? yes Padding at end of inode bitmap is not set. Fix? yes Error writing file system info: Remote I/O error /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

Last but one message states "Error writing file system info: Remote I/O error", and the disk is not repaired.

Could anyone help me with this issue? I can't figure it out. Is it due to the fact that I use an USB adapter? Is the issue related to some (un)fixable condition of the disk?

Best regards, MC

Improve this question
1
  • I found some hints online. HDD appears to be faulty, hence its inability to repair itself. As I access it through an USB bridge, smartctl can't be used to check the HDD health. So, I'll make a copy of the partitions on another disk usinf the dd command, and then attempt to repair them. Commented Apr 13 at 8:59

2 Answers 2

Reset to default
0

What I would do in your case is to make an image of the disk with testdisk and after to work on the image (it will help if the disk have some physical errors or write troubles or data communication error )

testdiskand its documentation can be found here: https://www.cgsecurity.org/wiki/TestDisk

If you need a file level recover of the disk, you can use photorec from the same author

To make an image with testdisk you can use:

testdisk /log /debug /dev/sdb

and after follow the menu to create an image.

Not that except if I have no choice, I would never work directly on the physical media I'm trying to recover, the idea is to always make an image (device block copy) of the disk and to work on a second copy of the extracted image (always keep an original copy of the extracted image of the disk and copy it each time you want to try something new to recover)

NB: doing this you're working on a file which reside on modern storage which work without errors and in your case, you can restart the fsck command and you will not have physical write IO errors as you're writing on a file which is on a modern and functional disk. If you need to mount the image you can use losetup --partscan command to "be able to use the image file as a block device the kernel can use like a regular block device"

Improve this answer
2
  • Thak you for your answer. I had no idea the HDD was damaged. Repairing a HDD is not a thing I've done many time. I've ordered a new external SDD, so I can make proper images of the damaged disk. I'm a bit shy to create disk image on my primary SSD. I'll keep this thread updated. Thanks again. Commented Apr 13 at 11:55
  • testdisk is safe but if it's your first use of this low level recovery tool, I understand you prefer take precautions. If the disk is physically damaged, always think that if you successfully make an image of the disk one time, maybe the process will not work a second time due to the damaged state of the media (and surely not due to testdisk program, it's really safe). So to have the best chance to recover your data, always work on a second copy of the image of the disk. NB: testdisk is present in common Linux distributions repository, prefer installing with apt than buil it yourself Commented Apr 13 at 15:00
0

First, thank you all for your answers. I've got a 1 Tb SAT HDD. I've created my first disk image with testdisk. Then, again with testdisk, I've been able to access the files in the image and successfully copy /home to the 1 Tb HDD.

Testdisk is really a powerful tool. Some files failed, but I'll not ask too much. The faulty disk is a "slightly" antiquated Seagate St313620a 13.2Gb.

Best regards, MC

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.