Migrating My Linux Install To An SSD

Last year, I had the pleasure of being in my former roommate’s wedding. As a “thank you,” he gave me the nerd’s credit card – a gift certificate to NewEgg.com. I sat on it for nearly 6 months before finally giving into the temptation and buying a Solid State Drive. As I have programs compiled, configuration files done, non-standard programs installed, I thought this would be a great reason to do a migration rather than a clean install.

I started by searching for my bootable thumbdrive with Ubuntu 14.04 32-bit LTS. Couldn’t find it. Bonus tip: to create a bootable thumbdrive, just use:
sudo dd if=/path/to/ubuntu/image.iso of=/dev/sdX bs=512k, where X is the thumbdrive’s device letter in /dev/. Totally works!

Anyways, got a 32-bit version going. Created a new partition table, created an ext4 partition that filled up the drive, and mounted it at ~/new and the old at ~/real original, huh? Did a mass-rsync with:

rsync -Pa ~/old ~/new

Once that was done, I needed to install the GRUB2 bootloader. There wasn’t a direct way to do it, but you can use the chroot method to do it:

sudo mount –bind /dev ~/new/dev
sudo mount –bind /proc ~/new/proc
sudo mount –bind /sys ~/new/sys
sudo chroot ~/new

This was working great, but ran into a problem. I was attempting to use a 32-bit version to write a bootloader with a 64-bit version of Ubuntu. Take away: if you use a 64-bit OS, use a 64-bit live CD or USB!

Once this is done, run:

sudo update-grub2
sudo grub-install /dev/sdX

Again, where X is the letter of the new SSD.

Now, we have a bootable SSD with all of your data back on it. BUT there are still a few more things that need to be done in order to finish up. Still in the terminal, type:

sudo blkid /dev/sdX

and make note of the UUID of your new SSD.

sudo vim /etc/fstab

(replace vim with gedit, nano, other preferred editor). You should see all of your mountpoints, including the information of your old drive pointing to “/” in a long UUID. Replace the old one with the new one (or, comment it out and copy/paste in a new line with your new SSD UUID).

Now, one final task. If you’ve read anything about SSDs, there is talk about TRIMing the drives. This is the OS’es way of identifying which pages (which are made up of blocks, which are large compared to sectors in a hard drive) in the SSD are empty and can be written to. With a traditional HDD, when a file is “deleted,” the sectors that correspond to the file are marked as safe to overwrite. Until that time, the files CAN be recovered – a sometimes necessary act that will make you happy you knew how to do it. An SSD will mark the blocks as available to be rewritten, but the process of finding a block that is marked as free, copying the blocks that still hold data of a page to an internal buffer, and rewriting the page with new information in place take a significant amount of time to accomplish.

It can be done two ways in linux — automatically upon file deletion (which is specified with the “discard” option in the fstab) or with a cron job. The discard option seems like the better choice off the bat, as it is performed as soon as a file is deleted. This however can lead to performance decreases if you do this with a large number of smaller files. A single command will run the TRIM command on the file system and do this for you though.

sudo fstrim -v /

Where “/” is your mount point. Since the SSD is our root mount, it is /. Run:

sudo vim /etc/cron.daily/fstrim

and use whatever you’d like to execute that command (outputting to a log file, not being verbose, different mount points, comments, etc). After this is done, mark it as executable:

sudo chmod 755 /etc/cron.daily/fstrim

I personally prefer the hex/binary method of entry for chmod, as they make perfect sense to me. Read/Write/Execute in binary order for the User, Group, and Everyone.

Now, we are done. Log out of the chroot environment, unmount your ~/new/dev, ~/new/sys, ~/new/proc, and ~/new directories, and reboot. Tada!

My desktop is a Core2Duo E6400 w/ 4GB of RAM. My linux OS WAS on a slower, 120GB IDE HDD, which also conatins my Windows 7 install. Because I more often use my Linux install, I chose to migrate it over instead of the Windows install. I am able to boot into either Windows or the old Linux installs off of the IDE or the new, Linux install on the SSD. My boot times went from 1:20+ to boot to 0:19 after GRUB. The vast majority of this tutorial came from this site, but I did not change the SSD’s UUID – I instead modified the fstab file to accommodate the SSD’s UUID so I could use boot back to my HDD-based Windows 7 install.