I have an SSD with LVM with one LV dedicated to a Win7 VM .vdi file of 80Gb.

The underlying fs is ext4.

After installing a new SSD and setting up the new LV's in migrating, the copy from the old SSD failed on copy with

Input Output Err No.5 

Failed on cp, rsync, dd

And a quick look at


[ 5829.294651] sd 2:0:0:0: [sdb] tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
[ 5829.294653] sd 2:0:0:0: [sdb] tag#14 Sense Key : Medium Error [current] 
[ 5829.294654] sd 2:0:0:0: [sdb] tag#14 Add. Sense: Unrecovered read error - auto reallocate failed
[ 5829.294656] sd 2:0:0:0: [sdb] tag#14 CDB: Read(10) 28 00 51 50 f9 47 00 00 08 00
[ 5829.294658] blk_update_request: I/O error, dev sdb, sector 1364261191 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 

A selftest with smartctl gives the a fail with the LBA

badblocksshows me 6 bad blocks and a further check with debugfs confirms the inode for all bad blocks as belonging to the .vdi file.

There is nothing on that LV bar the VM which currently still boots fine in virtualbox (which also won't copy the VM).

So the assumption is that the bad blocks are in some rarely used part of the VM filesystem and it doesn't care (yet) but the day will come.

Now I can't blame my Linux box for disliking the Win7 VM but I would like to save the old girl if only for sentiment.

Is there a way to recover the .vdi, perhaps by defaulting to a zero filled block on a bad read and skipping to the next block?

Just found


Soon as I typed ....giving it a go

1 Answer 1


I didn't find and answer on U&L but serverfault provided one.

So I will leave their solution here for anyone else. Let me know if there is a dupe in U&L in which case I will take this down.

The solution was as simple as

dd if=Win7.vdi of=~/mnt/Win7.vdi bs=4k conv=noerror,sync

After having checked that the block size was correct.

All good now.

You must log in to answer this question.

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