Upgrading from HDD to SSD, best way to clone drive? (Solved)

[farkas]

I have a Dell Inspriron laptop with a 1 TB 5400 rpm HDD running LM 19.1. Ditched WIN 10 after warranty expired. I'm about to replace it with a 1TB SSD. My laptop's boot times compared to my desktop with an SSD are light years apart! With prices on SSDs becoming more affordable, decided to take the plunge and replace my HDD with an SSD.
What is the best way to clone my HDD to the SSD?
I got a USB 3.0 to 2.5” SATA III Hard Drive Adapter Cable w/ UASP – SATA to USB 3.0 Converter for SSD/HDD - Hard Drive Adapter Cable .
Tried Clonezilla before and almost trashed the original drive. Not using that again.
My alternative choice is a clean install on the new SSD, then I'd have to reinstall my applications and copy all my personal files to it.
A lot of time and fine tuning to get back where I was on my HDD.
I'd appreciate any and all suggestions and opinions.

Edit. April 09, 2020
Before reading further, see topic
viewtopic.php?f=47&t=315557
Foxclone. Easy to use backup/restore and clone application.

[rene]

If the SSD is precisely as large or larger than the HDD certainly the simplest approach is dd if=/dev/sdx of=/dev/sdy bs=100M status=progress from a Live system where /dev/sdx is the HDD and /dev/sdy the SSD. Make sure to not reverse them...

Use sudo fdisk -l to be informed of device sizes in sectors. Would be expected to take some 3 hours for 1 TB I guess. Afterwards, if the SSD was a bit larger you'd use e.g. gparted to grow the last partition on the SSD.

[AndyMH]

I wouldn't use dd simply on the basis that make a very simple mistake and you have trashed your system, dd aka disk destoyer. I would have suggested clonezilla, but you've tried that and not liked it (neither do I). When I did similar I used redo - much simpler to use than clonezilla. Now obsolete, last update in 2012 but can still be downloaded here:
https://sourceforge.net/projects/redobackup/

Be aware, when I did this, don't think it copied MBR (I'm legacy boot) and had to use boot-repair to fix grub.
https://help.ubuntu.com/community/Boot-Repair

Alternatives - take a snapshot with timeshift, backup /home with your favoured backup tool (I use backintime). Do a fresh install and restore from both.

[farkas]

I think I'll go with the safest route for me. Which is do backup, timeshift snapshot to external HDD. Then a clean install, restore with timeshift and backup.
This way I'll have my original HDD to reinstall in case things go wrong.
Which should I do first after a clean install of Mint, timeshift or backup?
Thanks for your replies!

[JeremyB]

I have used clonezilla for all my cloning, you just have to watch what you set for source. The only issue I ever had was trying to clone to a smaller SSD and one time I put the wrong HDD in, and I had to do the clone over with the correct HDD

[farkas]

IF I use clonezilla, can I use SATA III to USB 3.0 cable? Can I run clonezilla from USB stick the same time my new drive is connected with the adapter cable? When I tried to use clonzilla before I found the instructions very confusing and hard to follow. It might be better it had a GUI.
Maybe I should my use name to "old dog" trying to learn new tricks.

[JeremyB]

I used Clonezilla on a USB thumb drive to clone a dual boot Win10/Mint 19 from the 1TB HDD to a 1TBB SSD that was in a caddy connected by USB. It was easy to notice as the HDD and SSD were made by different companies

[farkas]

I'm about to clone my HDD to an SSD. What does the " bs=100M status=progress " do in the command

Code: Select all

dd if=/dev/sdx of=/dev/sdy bs=100M status=progress

do?
Haven't decided on which method to use suggested in previous posts.

[jchelpau]

bs=100M makes it copy in faster chunks, and status=progress will show how much has been copied at regular intervals.
Before doing this run 'lsblk -b' in a terminal and check that the HDD and SSD drives have the same byte amount, or the SSD has a larger size.
Copying the HDD to a SSD that's smaller (even by a few bytes) may lose data.

[farkas]

Thanks jchelpau.

[farkas]

Thank you to all who replied!
Before replacing my HDD with an SSD I copied my HDD to the SSD with the "dd" command, after researching the the various options. Made a Backup using Mint Backup Tool and a Timeshift snapshot to an external USB drive. Using the "dd" command is a one step operation, dangerous maybe?. Used this method because Clonezilla has many menus and (Y/n) questions. Many more chances to make a mistake.

Tried to use Backintime to make a backup, couldn't get it to work, it newer saw the USB drive, even though it was on my desktop and was accessible from there. Tried using AndyMH's tutorial in viewtopic.php?f=90&t=290899. Unfortunately it messed things up and had to use Timeshift to restore.

Connected the SSD to my laptop with a SSD/HDD to USB 3.0 adapter cable. Checked sizes of both drives, they were identical down to the last bit.
Took a leap of faith and copied and pasted the code from rene's reply

Code: Select all

dd if=/dev/sdx of=/dev/sdy bs=100M status=progress

into terminal, changing x to a and y to b, after triple checking for syntax errors and shutting down all applications and disconnecting from the internet, I finally pressed the enter button. It told me that I didn't have permission. Changed to root privileges, tried again. It ran. Took little over three hours to finish.
Checking with with the folders menu and Gparted they looked identical.

Dell has good on line manual for my laptop. https://www.dell.com/support/manuals/us ... lang=en-us

The hardest part of replacing the drive was removing the bottom cover, it took me about an hour of prying and poking, after that it was fairly easy.
After replacing drive and putting everything back together booted up. The boot started normally but it didn't finish. It went to command line with tiny print in the upper left hand corner of my screen. I think my problem that the SSD was labelled as sdb not sda, I don't know. Is there a way to change sdb to sda? That might have solved my problem.

Went to my fall back option. Made a clean install of Mint 19.1 from a USB and restored with Timeshift and Mint Backup on the SSD. Had to reset my settings on my desktop, Thunderbird, Firefox, the only thing I'm missing is the Virtual box machines. I'll have to reinstall them.

My overall my opinion is to make a Timeshift and Mint Backup of the original HDD to an external drive, skip the cloning.
Just in case I copied all my picture, document files and other stuff to another external drive. Replace your drive. Make a clean install of Mint 19.1 and use them to replace your applications.
Another observation is that the boot time is about the same as before, however applications, such as Firefox , Thunderbird and Libre Office and other applications load almost instantaneously. Personally I think it was worth the effort!
Is there a way to speed up boot time?

Once again thank you to all who responded to my post!

[rene]

It doesn't make immediate sense that something didn't work; dd does nothing other than loop reading bytes from its "if" file/device and writing them to its "of" file/device; "of" will end up a byte-for-byte clone of "if", which is to say that after connecting "of" to the same SATA connector as "if", software wouldn't have noticed a difference.

It is however also as far as I've experienced not in fact to be expected that the SSD really was the exact same size as the HDD; memory technology chip sizes tend to multiply to more specific totals than magnetic storage technology even with internal reserved space subtracted. I advised checking the output of sudo fdisk -l for size in sectors and see you got a bit more creative. Thing I can think of is that things went wrong there. No, "sda" vs "sdb" is not the issue as long as you connected the SSD to whichever connector the HDD used to be on.

Anyways/moreover... you certainly should have experienced a boot time difference; from 1+ minute on HDD to 30- seconds on SSD at its most conservative. The usual reason for a boot delay is a missing or UUID-mismatched swap partition, which could if it used to be the last partition on your disk confirm your SSD having in fact been slightly smaller. Please post the output of sudo fdisk -l /dev/sda so as to check (not near a GPT system currently to quickly check; unless I'm mistaken fdisk works for GPT as well as MBR currently but use sudo gdisk -l /dev/sda if not).

[EDIT] Mmm, it is of course the case that if the SSD were larger the GPT backup at the end of the SSD would need to be recreated as well. Easy to do, but should've remarked on it. In any case, will still want the requested output to see what's happening...

[rene]

By the way, rereading this now that actually have time to do so, and I see that the cloned partitioning is likely gone already, you having reinstalled the system from scratch; the fdisk output would as such no longer be relevant. Yes, restoring a timeshift backup to a newly installed system would (supposedly, I should say; never used the dumb thing) restore an e.g. /etc/fstab with improper UUIDs, causing boot-time timeouts.

There's two things you can do; as vindication of dd I'd prefer simply repeating the exercise; I suppose you still have the HDD in original state. This time we'd want to see the sudo fdisk -l output from the Live system first...

Second, you could also just update the UUIDs; refer to the output of blkid to note the UUID for your swap, / and possibly other mounted filesystems. For swap, update /etc/initramfs-tools/conf.d/resume with the proper UUID and run sudo update-initramfs -u -k all. For both swap and the others, update the UUIDs in /etc/fstab.

[farkas]

Thanks for your reply rene.
Here is the output fdisk -l. sda is the Wester Digital SSD, sdb is the Toshiba HDD connected to my laptop with a HDD/SSD to USB 3.0 cable.

Code: Select all

steve@steve:~$ sudo fdisk -l /dev/sda
[sudo] password for steve:      
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FA21E27B-A4CE-497D-9FB6-92029ADE9267

Device       Start        End    Sectors  Size Type
/dev/sda1     2048    1050623    1048576  512M EFI System
/dev/sda2  1050624 1953523711 1952473088  931G Linux filesystem
steve@steve:~$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 1C4D870A-413D-4D7B-A3E2-09FF72FB6489

Device       Start        End    Sectors  Size Type
/dev/sdb1     2048    1050623    1048576  512M EFI System
/dev/sdb2  1050624 1953523711 1952473088  931G Linux LVM
steve@steve:~$

I'm also including a couple of screenshots from Disks.
[img][/img]

I hope they help,  thanks again.

[AndyMH]

My best guess, already mentioned, for a slow boot would be an incorrect UUID on swap - been there done it. Check the contents of fstab against the output of blkid.

[rene]

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
[ ... ]
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors

Golly. I was rather convinced we were going to see an issue there: there is exceedingly little else that can go wrong with a simple dd. No real idea then what could've gone wrong for you originally. Little unfortunate seeing as how a thread such as this now contributes to this completely unfounded fear of dd this forum tends to display, advising all sorts of convoluted, bug-ridden and/or practically abandoned "user friendly" cloning projects in stead of this simplest byte copying tool imaginable...

Oh well. There's some potential for trouble if you originally had partitions mounted on either drive while copying with dd but very little else I can think of. If it were me I'd redo just for kicks (be sure to have if=/dev/sdb of=/dev/sda this time...) but if you're not too interested, the above advise about editing the UUIDs in /etc/initramfs-tools/conf.d/resume and /etc/fstab should also get you back up.

[farkas]

I'm considering both options. Will editing /etc/initramfs-tools/conf.d/resume and /etc/fstab speed up my boot times?
Everything else is a lot faster with the SSD. What edits should I make?
Here are the content of the two files:

/etc/initramfs-tools/conf.d/resume
RESUME=UUID=f65f7eb1-c6d3-4f0d-875c-230f47c559d6

/etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/mint--vg-root / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=0A17-23E5 /boot/efi vfat umask=0077 0 1
/dev/mapper/mint--vg-swap_1 none swap sw 0 0

Tried to check the files on the HDD but it comes back with "Unable to mount location". I booted the HDD via USB cable but it still came back with "Unable to mount location". GParted shows both drives, Disks does too.

Also noticed that
sda has: Sector size (logical/physical): 512 bytes / 512 bytes, the SSD
sdb has: Sector size (logical/physical): 512 bytes / 4096 bytes, the HDD
Does that make a difference in in boot speed?

Again thank you for your reply rene.

[rene]

You have installed with disk encryption which, for some unimaginable reason, doesn't set up mounting file systems by UUID in /etc/fstab. That part's fine as is then. /etc/initramfs-tools/conf.d/resume should however still be edited: get the correct UUID from the output of blkid, the /dev/mapper/mint--vg-swap_1 line. Don't forget the sudo update-initramfs -u -k all afterwards.

If that doesn't get you to a (much) faster boot than on HDD it's not immediately clear what the issue is. Supposedly not this, viewtopic.php?f=46&t=287026, since that seems to say you'd explicitly be staring at a Grub menu, but since you're using LVM on EFI, still note it.

No, the 4K for (relatively modern) HDDs vs. 0.5K for (older HDDs and) SSDs is as expected and not an issue here.

[farkas]

Hello rene.
I understand that this might to much to ask, but could you walk me through your solution step by step. I understand that your time is precious. If not, that's OK.
Thank you.

[rene]

I'd as mentioned primarily just redo the clone even if only out of curiosity; was trying to think of UEFI-specific reasons the clone could've failed originally but not coming up with any. However, you can always still do that.

As to fixing your current setup open a terminal and enter

1. blkid

Note the UUID="..." part of the /dev/mapper/mint--vg-swap_1 line; select the UUID itself (i.e., the part inside the quotes) and rightclick-copy it.

2. xed admin:///etc/initramfs-tools/conf.d/resume

Change, if as expected not equal now, the in that file displayed UUID by pasting in the in step 1 copied one. Should end up looking like RESUME=UUID=... (this time no quotes around the UUID). Save and exit. Yes, you can ignore the multitude of xed "Gtk-CRITICAL" dumps in your terminal screen; xed is not a good program.

3. sudo update-initramfs -u -k all

... and reboot to test. If you in fact changed the UUID in 2 the expectation is that you gain 30 seconds.

I've no full-disk encrypted installs here to test, but generally speaking it would make sense if the boot time speed gain of SSD versus HDD were less than with regular installs, the decryption rather than drive bottlenecking you. It should still of course certainly be faster than HDD.