2

I recently purchased an SSD to upgrade my 6 year old laptop to use for school. I just spent a lot of time customizing Ubuntu to how I like it and I didn't want to do it again, so I thought I could save some time and just clone my HDD to the new SSD.

Currently using Ubuntu 16.04.

I realized I probably messed up at several steps below. I hope it can be fixed.

The steps I used:

  1. Using USB 2.0 to SATA converter, connected SSD to laptop. It showed up as /dev/sdb in Disks. My current HDD shows up at /dev/sda1.

  2. Formatted /dev/sdb to NTFS

  3. Ran sudo dd if=/dev/sda1 of=/dev/sdb

  4. It was running for two hours but it's a 500Gb HDD that I'm cloning. It was going too slowly and I needed the laptop the next morning, so I did some more googling.

  5. I stopped the dd run

  6. Disks > Formatted /dev/sdb again (my logic was that I wanted to start over.. but I chose "Don't overwrite existing data" because overwriting was going to take a long time...)

  7. Terminal: sudo dd if=/dev/sda1 | pv | sudo dd of=/dev/sdb bs=100M

  8. Leave it sitting overnight, it's finished in the morning

  9. I get home from work and try to boot from the SSD, but it can't. When I look in Disks, it doesn't even see the SSD when it's plugged in. Same thing in GParted, there's nothing.

I royally messed up. Help. :( I just want to be able to see the SSD again and I will just install Ubuntu normally.

Edit: was able to fix it by connecting the ssd to a desktop with windows and reformatting using their disk management tool. Reconnected to Linux, made a bootable partition and installed Ubuntu. Transferred files over, swapped drives out physically. I'll be more careful next time and just stick to methods I know that work. Thanks for the help.

4

I have had similar issues before, particularly with flash drives. To fix the issue with gparted not seeing the disk try erasing the beginning of the disk with:

    sudo dd if=/dev/zero of=/dev/sdb bs=1m count=128 && sync

Then unplug and plug in your usb adapter. This will nuke the partition table on the ssd and should allow gparted to see the disk again.

It is also important to add:

  && sync 

When working with dd and a device connected over usb. This is because most operating systems will cache data in ram to make usb disks appear to write faster. The sync command will force this data to be written to disk and prevent data loss/corruption.

As for copying data to your ssd with dd, it should work in principle, but you may not be able to do it in practice. I personally have had mixed luck when doing this, sometimes it works flawlessly, others not at all.

Further reading/Source:

|improve this answer|||||
  • 1
    That should help to make the SSD visible again. The OP nuked the MBR and partition-table with the dd-command. The original MBR was overwritten by the partition-boot-record of the input-file sda1... – mook765 Oct 20 '16 at 4:09
  • 1
    @mook765 "nuked" is exactly how I'd have put it. I've only ever used dd to make a live usb, or wipe a drive by copying /dev/null to it. It's a very dangerous command indeed if the drives are not identical in type, size, and/or nature as I've experienced. – Dooley_labs Oct 20 '16 at 4:25
  • 2
    @Dooley_labs I agree, I learned to not use dd for copying disks the hard way. After doing it successfully a few times I managed to copy a blank disk to my hard drive right before having a college paper due... There is a reason it is nicknamed data destroyer. – kd0hdf Oct 20 '16 at 4:41
  • Stuffing zeros to front of MBR as you suggest helped me convert UEFI format back to legacy on USB drive. +1. – WinEunuuchs2Unix Oct 20 '16 at 12:11
  • I fixed it before seeing this, but thank you for your informative post. :) – Hann Solo Oct 20 '16 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.