migrating to an SSD

Dear openSUSE users: Is there a DIY on the offical procedure for this task?

Thank You,

Just like moving to any other type drive

I add “noatime,nodiratime,discard” to any partition To reduce writes and deal with trim

You do have to deal with the any change in UUID and you may have to do a chroot and run mkinird

Thanks - is there some official HowTo on drive migration? It’s tricky, I understand. :stuck_out_tongue:

Maybe just easier to do a fresh install and migrate only my /home directory?

I pretty much covered it. change in UUID from one drive to another has to be taken into account in /etc/fstab Note you don’t need the parameters I add if using BTRFS that is for ext4

You may need to do the chroot and makinitrd to reset things for the new envrionment

Note that if you do a full binary clone UUID’s may be cloned. But if you make new partitions you get new UUID’s

On 2015-08-07 02:26, PattiMichelle wrote:

> Thanks - is there some official HowTo on drive migration?

Well, there is a howto in the Linux Documentation Project, since many
years. :slight_smile:

> It’s
> tricky, I understand. :stuck_out_tongue:

No, why?

Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

Hi gog - now sure what you’re referring to with chroot and makinitrd. I think I did what you’re referring to a “binary clone” with clonezilla… (device to device). Now I’m trying to find the right identifiers (from the new SSD) to modify it’s version of fstab. In the old days, I would also modify the boot file in GRUB. I have no idea how to do that, although I do remember attempting to research it back when OS first switched to GRUB2 (there were no easy answers). I think I’m going to wind up doing a reinstall while simply keeping my old /home dir…

Hi Robin - do you have a link for that? It’s always
been very difficult for us normal mortals. But maybe
that’s just my stupidity! rotfl!

On 2015-08-29 16:56, PattiMichelle wrote:
> Hi Robin - do you have a link for that? It’s always
> been very difficult for us normal mortals. But maybe
> that’s just my stupidity! rotfl!

Google “Linux Documentation Project”

—→ http://www.tldp.org/ —→ howtos

—→ http://www.tldp.org/HOWTO/HOWTO-INDEX/howtos.html

Search “Upgrade”.

—→ http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/index.html

HTH :slight_smile:

Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))




The key to any project like this is to first understand that it’s a lot easier to make any modifications on a working and running system rather than to try to repair a non-working system. So, if you know what may fail as a result of the main project favor prepping your machine to avoid those failures rather than fix the problems when they are real.

Prep your machine
Delete everything unnecessary, and empty the trash.
Safeguard anything critically important by moving (not just copying) to external storage.
Defrag if desired which should also compact your files, this consolidates your files so you will be moving less data.
Zero your free space so that things like hidden characters and artifacts aren’t copied.
Edit your fstab, changing UUID disk identifiers to device id

Do your clonng
Can use clonezilla. dd is also good.


I find this wiki item to be a good background read on the topic.
I am about to do a fresh install on a new SSD.
Across several write ups, I have seen several warnings about mounting with the discard option.
A big difficulty in evaluating all these is the significant variation among SSDs, specifically their internal fw and wear optimization algorithms.

I am not sure I see a concrete benefit to btrfs over ext4 for /.
I still use a 7200 rpm drive for /home and big data/
I plan to use SSD for / and a directory that contains my VirtBox file.vdi images.
The arrangement provides awesome VM performance on a Linux host.
However, I read that vdi volumes on btrfs is a bad (very slow) idea.

My plan is to go with ext4 with noatime and nodiratime, but run fstrim as an occasional background service rather than the discard option.
I am NOT claiming that is the “right” answer, more a safe one that I understand a little better.

Good luck!

Thanks, Tsu - Thanks. I did some more googling and saw that there seems to be the feeling that one should install a fresh system on a new drive - mostly to fix broken files and to clear the empty space as you suggest - and just import your old /home when the OS installer asks.

I clonezilla’d the disk to a USB drive containing the SSD. Then I mounted the SSD (not booted from it yet) and edited the fstab on the SSD and changed the drive ID (I found these in YaST/Partitioner). I looked in “Boot Loader Options” in YaST > Bootloader and it claims GRUB2-EFI is currently my bootloader - and there is an Optional Kernel Command Line Parameter which is:

 resume=/dev/disk/by-id/ata-HGST_HTS541075A9E680_JD13021X06UH4K-part6 splash=silent quiet showopts

…so GRUB2 does have a reference to the hardware which needs to be “fixed” or the SSD won’t boot. GRUB had a text file where I could edit this as-needed, but I don’t know where GRUB2 holds this reference so I can edit it on the SSD. Maybe I’ll do a text-within-file search of my entire system to see where “ata-HGST_HTS541075A9E680_JD13021X06UH4K” shows up and edit all those files on the SSD before trying to boot from it?

OK - so kfind on the disk ID returned: fstab and crypttab as the only two files on my system referencing my current master HD (at least in ASCII):

cr_swap         /dev/disk/by-id/**ata-HGST_HTS541075A9E680_JD13021X06UH4K**-part6 /dev/urandom swap

Now, where is GRUB2 hiding that hardware reference…? Oh, well, I guess I’ll just try to boot from the SSD as it is, and if it fails, then reinstall 13.1x64 and import /home. As I recall, the wisdom on a dual-boot win7 machine is to always choose the root partition to install the bootloader… or was the extended partition? And UEFI makes this confusing for mere mortals…

Thank you very much for the link! I have a fairly good relationship with our IT folks at work and the recommended two SSD manufacturers. They’re putting SSD’s on all the new laptops they’re deploying. I do a lot of big number crunching and a big SSD swapfile really helps sometimes (not as fast as RAM, but at least tolerable, unlike an spinning HD swapfile - which can essentially shut down your desktop). From what I can glean, wisdom about SSD’s is changing fast, mostly because SSD’s are improving so fast. Even 2013 information may no longer be relevant for top-of-the-line SSDs. I don’t know if there even are any major “gotchas” any more.

I’ve tried JFS, XFS, BTRFS (back when it was standard in Opensuse), and I guess I gave in to ext4 some time ago, and haven’t read anything bad about it, and I guess it’s still improving. So I’ve been sticking with it. I don’t really know what noatime and nodiratime do, and like you say, I think the main thing is to choose known good SSD’s and all I really have to go with on this is what a couple of IT folks have told me (including our IT folks at work).

I think the main speedup comes just from access time, so I’m not sure it’s very important to tweak. Just make sure you get a top-of-the-line SSD.

The noatime and nodiratime options tell the file system not to record (meaning write to file) when a file is read, so only file writes get recorded.
This is a big deal in a partition with root(/), since most files are read mostly and write seldom.

Unless you have programs that base actions on atime parameter, these are good options to use as they significantly cut down on trivial writes back to the SSD.

I should mention that I have the following entries in my /etc/fstab

tmpfs    /tmp    tmpfs    defaults,noatime,mode=1777 0 0 
tmpfs    /var/tmp    tmpfs    defaults,noatime,mode=1777 0 0 

Using ramdrive for these system scratchpad folders also cuts down on SSD wear.

Yes, ramdrives are volatile, but I sleep (rather than shut down) most of the time, so losing a cache once in a while is no big deal.

On 2015-08-29 22:06, PattiMichelle wrote:
> LILO???

LOL X’-)

Well, the document is old. Many things remain the same, others you have
to change. The basic idea holds, the details don’t.

Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

Thanks - what no/dir\atime settings do you have for / and /home partitions?

The DEVIL is in the details of Linux, I find <<grin>>

Thanks - what no/dir\atime settings do you have for / and /home partitions?

My /home is a spinning hard disk, so

/dev/disk/by-id/ata-ST1500DL003-9VT16L_5YD3YAKW-part1    /home    ext4    acl,user_xattr 1 2 

Currently, my / is

/dev/disk/by-id/ata-SanDisk_SDSSDXP120G_141084400034-part2    /    ext4    noatime,acl,user_xattr,discard 1 1 

On my new /, I will add nodiratime and likely remove discard and run ftrim in a service.

This issue I have seen with discard is interruption of power losing data.
My UPS support is good, so discard seems to work OK.

Ahhh, I see. I am doing this on a laptop, so built-in UPS :slight_smile:

Hi Robin - I’m messing around with GRUB2-EFI (the bootloader on the disk I’m migrating from). I guess I need to do something to the new SSD drive to configure GRUB2 correctly? I found the /boot/grub2/grub.cfg file but I’m not sure I should edit that by hand or use a known procedure. Do you know of a link for that?