I would use GParted to copy the / and winsys partitions.
Grub/linux will boot after the copy as long as you run Boot Repair.
And according to this article, windows should be able to be moved with GParted as long as you have a windows repair disk to repair the installation after moving it.
Although you can safely drop the extended partition on the new drive as long as you only have 4 primary partitions, I wouldn't recommend it. Probably you will want to make the ssd into one extended partition and put all of the other partitions inside that one extended one.
Of course doing operations like this can always fail, even if the cause is something arbitrary like the power going out of the live cd failing, so definitely take a backup of your data before copying it. And I would also recommend that you don't make any changes to the HHD until you have successfully booted into the SSD with both windows and linux.
Probably the steps you would want to take are:
Boot into live CD and run GParted.
Make an extended partition on the SSD covering the whole drive.
Copy linux / partition and winsys partition to SSD, leaving the original still unchanged on the HHD.
If you wanted /home on the SSD, then make a new ext4 partition inside the extended partition, and use rsync to copy all data from the original to the copy.
An example rsync command could be like this:
sudo rsync -rhtvlpEog --progress /media/PATH_TO_HOME_PARTITION_ON_HHD/ /media/PATH_TO_HOME_PARTITION_ON_SSD/
explaination of that command: -r copies recursivly, -h gives human readable output, -t preserves modification times, -v gives more output, -l copies symlinks as symlinks, -p keeps file permissions, -E keeps executablility, -o keeps owner, and -g keeps group.
Mark winsys and / as bootable on the SSD.
Unmount and possibly disconnect your HHD from the computer, then run boot-repair, install grub to the SSD and making the / bootable.
still from the live CD, edit the fstab on the SSD / partition to have the new /home partition UUID.
Test that grub/linux works by booting your computer with only SSD mounted. (Also test that you have all the data in your /home partition)
Then if it does, use a windows repair disk to get the windows partition on the SSD bootable.
After using windows repair disk on the SSD, try booting into both windows and linux, without connecting the HHD.
Note: Be sure to not delete or move anything on the HHD, until you have confirmed that both windows and linux work on the SSD.
If all works on the SSD, then erase the /, /home, and winsys partitions from the HHD, and expand the windata partition to use the whole thing.
I have outlined the steps that I would take. I can't vouch for the windows repair disk working, but according to that article it should. I can vouch for Boot Repair working when moving the / partition though. I know that that works because I have moved my partitions around quite a lot using GParted.
Also if any of these steps fail and the SSD isn't bootable, you still have all of your data and everything still working on the HHD.
Additional experiences from the OP:
- It's good to have 3 live CDs/USB sticks - GParted Live, boot-repair, windows system repair, I needed all three of them
- I ended up not converting the home partition, so I didn't use the rsync step
- Be aware that on partition copying, the UUIDs (unique partition identifiers) stay the same. This is great because you don't have to edit the Ubuntu
fstab, and Windows won't want to be activated again, but after the initial copying stage, for testing you should remove/unplug the HDD from the system, otherwise there exist multiple partitions with the same UUID. This would have unexpected results.
- Useful tools for making bootable USB sticks (if you don't have a CD drive anymore) from live CD images are tuxboot, unetbootin, TotalMounter. Especially for the Windows system repair disk, this can be tricky - use TotalMounter to create it directly into an .iso, and e.g. this guide.
I had the same problem when using an encrypted swap partition. Neither the general Swap FAQ, Puny Geek's solution to the "cryptswap1 is not ready yet or not present" message nor Braiam's answer to this question solved the problem for me - sometimes the swap was available, sometimes it wasn't. After many reboots and some poking around, I think I have found the underlying reason:
The path to the swap partition like /dev/sda3 is sometimes different, e.g. /dev/sdb3. Since the file /etc/crypttab by default seems to identify the swap partition through this path, sometimes it would find it (if that partition happens to get the same path at boot) or not (if the partition gets a different path assigned at boot).
Seems like I wasn't the only one with that problem becasue as described here, a better solution would be to bind the swap partition through it's drive ID instead of its /dev/sd* path. This can be found by running
ls -l /dev/disk/by-id/
which lists the disk IDs for all partitions including the swap, which in my case was
ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 -> ../../sdb3
Double check in a program like Disk Utility that the -> ../../sdb* part of this line is indeed the partition you intend to use for swapping, as this (as I said before) can sometimes change names. As always, keep this in mind:
Caution: fiddling with cryptsetup and disk devices is dangerous for
data and OS. I personally made a full backup on a separate disk and
then umplugged it to be sure it wouldn’t be involved in any mishap.
Then edit your /etc/crypttab file by using the ID link instead of the "raw" path, in my case this line is
cryptswap1 /dev/disk/by-id/ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
I think this method should be the default for new installations, as one apparently can never be sure of the /dev/sd* paths... which I find somewhat worrying as I have the feeling that there are way more scripts and software out there which still rely on these paths (instead of IDs, labels or UUIDs) to stay the same across reboots.
TODO:
I haven't checked if resuming out of hibernation still works with this setup, as this seems to rely on a UUID (which my swap partition didn't have), as stated on this page: https://altinukshini.wordpress.com/2012/10/15/devmappercryptswap1-is-not-ready-yet-or-not-present/
Update:
Hibernation seems to work fine so far. Hope this solves these problems for others as well!
Best Answer
I actually ended up using Gparted from the Live CD. I copied the partition and pasted it in the unallocated space on the other HDD. Then I used blkid to check the UUIDs and edited the fstab file. Worked like a charm!