Recovering with DDRescue Cannot Complete (write error: Read-only file system)

dddisaster-recoveryhard drive

I'm trying to recover a corrupt VDI using vdfuse to mount the VDI and using dd_rescue to rescue the borked partition.

dd_rescue seems to be working fine but once it reached about half of the partition, it just STOPs and gives the following error:

ddrescue: write error: Read-only file system

Wait.. what? It suddenly turns the FS it is writing the recovered partition to into a read-only file system. Well… why? Will I never be able to finish this? What's going on?

Update – December 2, 2012

My computer was running VBox when it lost power, when I started it back up and tried to run the vbox instance, it told me that the HDD has no operating system.

So, after checking BIOS options and VBox settings for that profile, I created a new profile using that VDI and got the same error, proving that the VDI is indeed unreadable and that the profile was not just screwed up.

The VDI is a 500GB disk with 4 partitions on it. When I use vdfuse to mount the VDI to a folder, it contains the 4 partition as loopback devices (Partition1, Partition2, etc)

When I try to mount the first partition, it works fine. It was the boot partition so it contains nothing useful. But when I try to mount Partition4, my user home partition, it says Bad superblock at offset ###### a few times and fails to mount.

So, I run ddrescue Partition4 ../partition4_restore.img and that works fine until it reaches ("rescues") about 260 GB, when it just stops and gives the "Read-only file system" error.

The location that putting the img file has 660GB free.

Best Answer

1. Troubleshooting the ddrescue error:

Your write is failing with an error allegedly pertaining to the target volume. I would suggest verifying that it's actually possible to write such a large file to the target volume:

 `dd if=/dev/zero of=testfile bs=32M count=15000`

If that operation succeeds, you can be reasonably confident that the problem is specific to your ddrescue operation. If it fails, you know that the problem is with the target volume.

2. Fixing the original problem:

Of course, taking a step back from your chosen strategy, it would make quite a lot of sense to simply try using fsck -b to restore an alternate superblock.

Related Topic