Arch Linux

mutlu_inek

Member

From: all over the place

Registered: 2006-11-18

Posts: 686

[SOLVED] Botched dd: How to recover?

One of my SSDs (sda) seems to be dying so I bought a new SSD (sdc) and tried to clone it. However, something went awry. I would appreciate any help.

The SSDs are of different make, but both are 128GB in size. One is hooked up via SATA, the other is connected via an USB enclosure for now.

Before issueing the `dd` command, I checked the size of the drives in this manner:

cat /sys/class/block/sda/size
cat /sys/class/block/sdc/size

Both commands returned 250069680.

I felt it was safe and did

dd if=/dev/sda of=/dev/sdc bs=64K conv=noerror,sync

I know, I know, the choice of a block size of 64k was wrong and using the two options was silly, but that's what a quick Google search had returned and I was in a hurry. :facepalm:

What I got was this:

dd: error writing '/dev/sdc': No space left on device
1913766+0 records in
1913765+0 records out

I checked with `gdisk` and found out that suddenly, `/dev/sdc` is less than 10GB in size. The GPT partitions listed were the same as on `sda`, but the program complained about sector mismatches and when I fiddled with it, I accidentally wrote some values to disk.

So I tried `dd` again, this times with better(?) values, for example:

dd if=/dev/sda of=/dev/sdc bs=4K

But to no avail!

This is what `gdisk` gives me:

GPT fdisk (gdisk) version 1.0.5

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): p
Disk /dev/sdc: 15310120 sectors, 7.3 GiB
Model: Generic         
Sector size (logical): 512 bytes
Disk identifier (GUID): E46051A3-8C8F-4FF5-B619-3889CD17B068
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          497663   242.0 MiB   EF00  primary
   2          497664        17274879   8.0 GiB     8200  
   3        17274880       250069646   111.0 GiB   8300

Any ideas?

Last edited by mutlu_inek (2020-02-24 14:17:42)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,647

Re: [SOLVED] Botched dd: How to recover?

What's the size reported by blockdev?

blockdev --getsize64 /dev/sda
blockdev --getsize64 /dev/sdc

With dd conv noerror sync noerror there are two things to consider:

1. dd conv=sync,noerror (or conv=noerror,sync) corrupts your data.

2. a symptom of the conv noerror sync that occurs when the device size is not an exact multiple of the dd block size.

in general, for dealing with drives that may or may not be faulty, ddrescue is the better choice

# dd if=/dev/sda of=/dev/sdc bs=64K conv=noerror,sync
dd: error writing '/dev/sdc': No space left on device
1913766+0 records in
1913765+0 records out

1913766 blocks of 64K comes out as 125420568576 bytes. (125GB)

However you said the sys block size was 250069680 sectors which comes out as 128035676160 bytes. (128GB)

Unless you misread and sdc is smaller than sda after all, that sounds like whatever conv sync noerror did in your case, it was wrong.

EDIT:

wait wait wait, in your gdisk output the sdc was a 7.3GB drive, you killed an usb stick maybe? drive letters change, please be careful.

check dmesg, syslog for any disconnects or similar events

Last edited by frostschutz (2020-02-24 11:47:30)

mutlu_inek

Member

From: all over the place

Registered: 2006-11-18

Posts: 686

Re: [SOLVED] Botched dd: How to recover?

What's the size reported by blockdev?

blockdev --getsize64 /dev/sda
blockdev --getsize64 /dev/sdc

This is what I get:

# blockdev --getsize64 /dev/sda
128035676160
# blockdev --getsize64 /dev/sdc
blockdev: ioctl error on BLKGETSIZE64: Inappropriate ioctl for device

wait wait wait, in your gdisk output the sdc was a 7.3GB drive, you killed an usb stick maybe? drive letters change, please be careful.

check dmesg, syslog for any disconnects or similar events

I wish! But alas, /dev/sdc is indeed the brand new SSD.

Here, btw. is what `dmesg` gives me:

[170969.413958] sd 4:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[170972.527400] usb 3-1: new SuperSpeed Gen 1 USB device number 11 using xhci_hcd
[170972.545054] usb 3-1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice= 5.08
[170972.545061] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[170972.545065] usb 3-1: Product: USB to ATA/ATAPI Bridge
[170972.545068] usb 3-1: Manufacturer: JMicron
[170972.545070] usb 3-1: SerialNumber: 0123456789ABCDEF
[170972.553780] scsi host4: uas
[170972.554792] scsi 4:0:0:0: Direct-Access     JMicron  Generic          0508 PQ: 0 ANSI: 6
[170973.055385] sd 4:0:0:0: [sdc] 250069680 512-byte logical blocks: (128 GB/119 GiB)
[170973.055392] sd 4:0:0:0: [sdc] 4096-byte physical blocks
[170973.055547] sd 4:0:0:0: [sdc] Write Protect is off
[170973.055551] sd 4:0:0:0: [sdc] Mode Sense: 53 00 00 08
[170973.055903] sd 4:0:0:0: [sdc] Disabling FUA
[170973.055908] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[170973.056261] sd 4:0:0:0: [sdc] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[170973.095427]  sdc: sdc1
[170973.097745] sd 4:0:0:0: [sdc] Attached SCSI disk

frostschutz

Member

Registered: 2013-11-15

Posts: 1,647

Re: [SOLVED] Botched dd: How to recover?

a problem with the usb enclosure perhaps?

can you hook it up directly (but doing so may cause mayhem with the boot process if you already duplicated partitions and filesystem uuids - boot a live cd, not the installed system)

Last edited by frostschutz (2020-02-24 12:25:48)

Wild Penguin

Member

Registered: 2015-03-19

Posts: 399

Re: [SOLVED] Botched dd: How to recover?

My thoughts:

1. your new drive is faulty (from factory). Have you tried it otherwise and verified it works?

2. Which (old or new) is in the enclosure?

I've had problems with USB enclosures before, they are just made shoddy (especially cheaper ones) sometimes.

In any case, since you get errors on the NEW drive you are trying to clone the image to, I'd erase it and start over (you got nothing to lose here). First, try to write something you know should work and determine if it works in the first place.

I must admit I've got only a little experience with HDD / SSD crashes (I've heard SSDs can crash in a way they are impossible to recover), so this is just my 0.02€...

Last edited by Wild Penguin (2020-02-24 12:46:37)

mutlu_inek

Member

From: all over the place

Registered: 2006-11-18

Posts: 686

Re: [SOLVED] Botched dd: How to recover?

Wow. Just wow.

My wife came home with the second laptop and I hooked the drive up (still in the USB enclosure). It works just fine. Blockdev reports a reasonable value, too.

blockdev --getsize64 /dev/sdc
128035676160

So I rebooted the machine in question and - voila - all is fine.

Now I'm running `ddrescue`. Let's see how that goes.

I'll report back. But first let me thank the both of you for your help! It's really annoying to sit there on your own, not be able to figure it out.

Edit: It works just fine now. I'm still not sure what happened. :S But it resolved itself with rebooting.

Last edited by mutlu_inek (2020-03-01 15:12:17)