Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have Ubuntu 14.04 with a lot of packages and work related stuff that I am very happy with it. It is installed on my main SSD drive which is a 120GB one (I had choosen "/" when I installed ubuntu, so I beleive everything should be on this drive). It shows up as /dev/sda

Now I have added another SSD to my computer which is a 240Gb. I do not have any other storage media at hand at the moment (e.g. external hard drive).

Since the new 240GB drive has obviously more capacity and is faster (a newer generation than my 120GB one), I want to move my Linux to this new drive. This new drive shows up as /dev/sdb and at the moment it is not formatted or anything (I have literally unpackaged and inserted in my PC right now :P)

How can I safely move my linux installation to the new drive?

I can change the SATA cable so the new drive shows as /dev/sda if necessary.

This is the output of "fdisk -l" if that helps:

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00076d7a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   226064383   113031168   83  Linux
/dev/sda2       226066430   234440703     4187137    5  Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5       226066432   234440703     4187136   82  Linux swap / Solaris

Disk /dev/sdb: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 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
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table
share|improve this question
3  
It sounds like you're planning to use both of them now. If so, you should consider just using the newer, bigger one as /home instead of the entire system. It should be an easier change (just move everything over and add a single line to /etcs/fstab), and most large files are likely to go into your home directory (and so onto the larger disk). – Kevin Mar 3 at 21:56
    
Possible duplicate of How to move Ubuntu to an SSD – David Foerster Mar 14 at 7:33
up vote 16 down vote accepted

You can use CLONEZILLA for this purpose.

Clonezilla is a free partition and disk imaging/cloning tool which can be used to backup all your data (whole disks or partitions) in a highly compressed way and later clone it back to your hard disk to get it into exact same condition. This is faster than installing the OS most of the times.

enter image description here

In your case you can use the "device-device" option too, but I am not familiar with it.

You can find a detailed guide about Clonezilla here : http://clonezilla.org

share|improve this answer
    
I suggest you watch these two tutorial videos before : youtube.com/watch?v=41tTudaQb0I and youtube.com/watch?v=LS6VhLDw-io – Severus Tux Mar 3 at 19:15
    
This is also a good option. But I am too lazy to create the clonezilla stick ;-) – Pilot6 Mar 3 at 19:15
    
I found clonezilla didn't copy over mbr so a whole disk image and a bit of worked with gparted should do the trick – adampski Mar 4 at 10:39
1  
wow! glad to hear this ;-) , The boot time, It is because of changed UUIDs , i.e, The new UUIDs and Old ones of your important partitions (home,Swap) has chamged. To correct this, please follow the instructions given here with suitable changes : askubuntu.com/a/737340/497359 If you find any problem, please comment it. – Severus Tux Mar 4 at 13:52
1  
@adampski : This seems to be a bug in Clonezilla 2.4.5. As a workaround you can use Clonezilla 2.4.2 or Clonezilla 2.4.2 Server Edition (DRBL) until it is fixed. :) – cl-netbox Mar 4 at 14:24

It can be done in a few ways. But the easiest one is to just copy all files from the old drive to the new one.

  1. Create an ext4 partition and a swap partition on the new drive.

  2. Boot from LiveUSB.

  3. Mount the old Ubuntu partition to some directory, mount the new one to some other directory.

  4. Copy all files from the old one to the new one using cp -a command.

  5. Install grub to the new drive.

  6. Update /etc/fstab with new UUIDs.

If something is not clear, I can add some explanations.

share|improve this answer
    
So all files, groups and stuff would remain intact? – Saeid87 Mar 3 at 18:57
    
Right, cp -a preserves everything. – Pilot6 Mar 3 at 18:57
    
@Saeid87 Forgot about fstab. Added that too. – Pilot6 Mar 3 at 19:03
    
+1 - it's also possible to avoid booting from a LiveUSB and do everything while booted from the original drive, do all the changes, reboot, voila. – Sergey Mar 8 at 20:17
    
Could you be more precise as to how 'install GRUB to the new drive'? – Marc Vanhoomissen Mar 9 at 8:21

In case you have some time and want to go safe:

$ dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync

Explanation of the command:

  • if is the input, of the destination
  • bs sets the block size. It's the size of the chunks dd will read and write in. Higher Chunk sizes usually means higher performance but also more corruption of data if input disk has errors, see here: archwiki on dd
  • noerror continues in r/w-errors.
  • sync synchronizes the offsets if an error has occured.

This will basically create an image of you disk sda and write it onto sdb (same partition layout etc.) Ofcourse this'll write the whole 120GB as it's file-agnostic. Thus very safe, but not the fastest, if you only use small portions of the disk. However if the input disk is rather full it might even be faster.

BUT:

  • After that you probably want to resize the partitions as otherwise you cannot take advantage of the extra space.
  • In any case it might be needed to edit the /etc/fstab file.
    This is the case if Hardware-IDs are used to recognize the disks.
share|improve this answer
2  
Your dd command will run forever. Consider adding bs=1M to it – Dmitry Grigoryev Mar 4 at 11:07
    
Afaik blocksize doesn't need to be 1M on SSDs but I'll look up on this and update – larkey Mar 4 at 11:09
    
The limitation is not in the SSD technology, but in bs default value which is 512 bytes. – Dmitry Grigoryev Mar 4 at 11:13
1  
extended answer with bs, thanks for the heads-up – larkey Mar 4 at 11:25
1  
Thanks for detailed answer...I learned some stuff! but I decided to go with clonezilla and resize the partitions afterwards. – Saeid87 Mar 4 at 12:26

The way i do it when i switch to a new HDD is:

  • create the partition layout i want on the new drive
  • boot from live cd/usb or install, rescue etc.
  • mount the old hard disk partition(s) to be copied to, say, /mnt/a
  • mount the new hard disk partition(s) to receive files to, say /mnt/b
  • cp -a or use tar to copy the files from /mnt/a to /mnt/b
  • install boot loader (lilo or grub) on new disk
  • update the /etc/fstab
  • reboot and test if everything is ok
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.