CCF Archive Site

This is with a Kingston 480GB SSD that I bought on the Cyber Monday deal. It only took me part of the weekend to get it right. 


I managed to get Linux "reconfigured" so that all of the root / path with the exception of my highly porky /home/gorn directory are located on the SSD. I left the /home directory on the hard drive. I remapped all of the paths so that the file system is seamless between the SSD and the hard drive's data contents.


I did a direct copy of what was installed in Mint onto the SSD. So it's not a fresh Linux install onto the new SSD with me having to set every little thing up. Which originally took weeks to get right over the last year. Everything works as before the SSD, with no exceptions.

Any interest in how I did it? It was hell to figure out how to do it effectively.    I made MANY false attempts that failed with segfaults and kernel panics. It was actually one of the more frustrating things I've done in "tech support. "

K.

Basically... What worked was:

1) Set the SSD as the boot HD in the BIOS.  (I kept my HD partitions active and bootable so I was flip flopping between startups based upon what I needed to do.)

2) Install the same Linux distro (Mint 18.2, Sonya) onto the SSD. (All I'm doing with the fresh Linux install onto the SSD is establishing the boot sector and the GRUB stuff. )

3) Boot from a recovery disk (Hiren Boot CD) so neither hard drive nor SSD is the boot device for a session.

4) Copy the /etc/fstab file from the SSD (placed by the Linux install just now) to a safe location.

5) Use Hiren's command line to mass copy all directories and files from the HDD into the SSD, *except* the /home (too much data) and except the /boot directory (has special sauce to boot from this SSD.) I used rsync which allows convenient exclusion of directories you don't want in the copy operation.

6)  edit  the fstab file that was on the SSD formerly, to include mappings of /home to the old hard drive's home (I am mainly interested in a bootable system, not in having EVERYTHING on the SSD at present.) Also the /root which also still resides on the hard drive.

7) Save the edited fstab as /etc/fstab on the SSD.

Reboot with SSD as boot device.

*All* my shit worked straight-up. I was quite, uh, proud, really. 

Absolutely none of the writeups on the subject of SSD migration under Linux that I found on the web advocated such a path of selectively copying the old install's data content.

Almost everyone is saying either do a direct partitition to partition copy (not practical since the SSD is << the HD) or do a fresh install and reinstall your apps (not practical because it took months to build up a decent work environment.)

Prior to this I was trying to do the boot up stuff on my own. I am not well conversant with GRUB so my attempts failed with GPFs and segfaults. I finally let the Linux installer do the heavy lifting of creating its bootloader and GRUB menu. Learning the GRUB tool would be a lot faster to do that step, though.

The actual core of Linux PLUS all of my many installed applications is only about 30 GB. And I have a LOT of stuff. So the bootable image itself, exclusive of all of my data like images and movies, is QUITE compact relatively speaking. So it was straightforward to make "working backups" of the SSD install onto a safe hard drive place just to speed up recovery, when I was experimenting.

Example of speed: on a i7-920 Bloomfield processor (10+ year old original i7), "The Gimp" comes up from the SSD in about 2 seconds flat. It took more like 4-7 seconds before.

I can probably get a lot more speed out of the setup by moving all of my user config for /home/gorn to the SSD. I'm planning to use the HDD for bulk data. The SSD for bulky data such as movies I edit.

Quote

Almost everyone is saying either do a direct partitition to partition copy (not practical since the SSD is << the HD

It would be if you kept the sizes the same. I make it really simple and keep all my SSDs an identical 1TB. It is a little more expensive but I don't ever run into issues related to size difference. Easy to copy the contents of the  entire drive back and forth if I must

The dd command is the equivalent of macrium reflect in Windows, or rather vice-versa.

and you can designate multiple boot devices in bios.. you don't have to have just one bootable ssd drive.

All true (and I used the multiple boot devices in the BIOS to switch between the SSD and the HD during testing.)

I just prefer more flexibility. My idea here is to structure my storage in the old "hierarchical" manner with fast  storage (SSD) for frequently used material and slower storage for larger data and archival stuff.

Macrium and DD is a good comparison. I used Macrium once to make a backup of a laptop's initial instance of Windows and it was super straightforward, and not the clusterf*ck of Acronis.

I used DD in this process to make a backup file copy of the SSD when I had an OS installed and I wanted to play with it. It's very cool that I can mount that file as another Unix device!

In an office I worked in back in '95, one guy in the office said that he would email this guy in Detroit at the home office his hard drive. We all thought that was pretty funny. Now, it's sort of practical to do so... (as a DD archive.)