4

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.

2
  • Can you actually provide some more information? Dec 2, 2012 at 14:20
  • I suppose that might help =p. I keep losing the log since it takes so long to work and I usually quit in frustration. Editing.. Dec 2, 2012 at 17:07

3 Answers 3

2
+50

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.

1
  • The dd command worked fine and fsck -b after following that tutorial always returns with "The superblock could not be read..", running mount then dmesg | tail shows "error: can't find an ext2 filesystem on dev loop0", "VFS: Can't find ext4 filesystem, "recovery required on readonly filesystem", and "write access unavailable, cannot proceed" Dec 4, 2012 at 8:52
1

After mounting with vdfuse, I used testdisk which allowed me to view and copy the list of files within the Partition4 file.

0

Instead of dd_rescue, you should use GNU dd_rescue (http://www.gnu.org/software/ddrescue/ddrescue.html), which is not the same. The original dd_rescue is not very safe to use while GNU dd_rescue is.

But as you get a write error, I'd check the target partition first if it can save such big files (most FAT partitions can't) and if your target partition has enough free space.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .