This article has been originally published in Italian (here). Feedbacks on content and translation are appreciated. Contributions are welcome. The original article must be considered the reference in case of updates.
Tinkering, as usual, with installations, partitions and re-installations, a question came to my mind: can I transfer a full installation from one disk or partition to a different one? And how? And why? What’s the sense of life? Well, this was off topic…
As the good Capt. James T. Kirk would ask ol’ Scotty to beam him up ‘n’ down the Enterprise, so I wanted to teleport a full install, all ready and tuned, to a new target, instead of reinstalling from scratch.
The only way to know was to pile up the proper hardware and software to run some experiments, following the crazy rule not to look for any tutorial on topic. I don’t want to spoil the happy ending, but anyway nothing blew up.
In particular, I used Virtualbox to create what I needed, being sure to leave my real system untouched and able to restart from scratch in case anything goes the “f.u.c.k.” way. This is what Trekkers might recognize as the equivalent of the “red shirt” crew member ;-)).
One thing that is worth highlighting is that this procedure only requires software included in any live CD or a standard installation. I know programs like Clonezilla should do the trick but I’ve never used it and I thought it was more “natural” to trust more common and well-known system tools.
There are many reasons to call mr. Scotty instead of challenging your patience and reinstall/”clonezillate” a system:
- you are/we are/I am nerd without hope of redemption,
- available space on disk is running out,
- disk is showing mechanical problems and has to be replaced,
- installation is moved to a faster disk,
- settings of current install have to be fully saved (themes, installed programs, system settings, etc.) instead of starting from scratch,
- a voice in your head convinced you this is a good thing to do.
Whatever your reason is, let’s get it started.
A little warning: be careful where you lay your nerdy hands, you’re not just going to change the wallpaper. Any data loss or other issues is your responsibility, as well as backing up important data before you begin. So far the procedure I am going to describe has worked for me and I couldn’t find any issues. I’ll keep you updated in case something strange happens. If any step is not clear enough, don’t hesitate to ask. Suggestions and feedbacks are welcome.
#0: “Starfleet” – Hardware
In Virtualbox, I made a virtual machine with two disks attached, one containing Kubuntu 10.04 “Lucid” (“target” disk, /dev/sda, 20GB) the other containing 12.04 “Precise” (“source” disk, /dev/sdd, 20GB).
Although the following example is targeted to have a dual boot environment, the procedure can be used for any of the purposes listed above.
Booting the VM through Kubuntu Precise live CD, partition scheme is as shown in the picture below.
I added to the same VM two small disks that proved useless in the end: Backup (/dev/sdb, 6GB) and 10GBDISK (/dev/sdc, 10GB).
In the most general case, target and source disks can even be connected as external storage (USB) and assembled inside the pc at a later stage. Anyway, I am not covering this case and the related differences in the procedure.
#1: “Lt. Sulu, clear the spacedock!” – Prepararing the target disk
I am going to move Precise onto the disk containing Lucid, in a dedicated partition. Procedure doesn’t change regardless target and source are disks or partitions.
Booting in live session (in order to modify partitions), I sliced /dev/sda to make room for Precise. Size of new partition (primary, /dev/sda3) is 8 GB, to be formatted in ext4.
#2: “Energize!” – File transfer
Partition manager has an handy “copy & paste” function to duplicate a partition in a few clicks. Such operation is allowed only if the target partition is the same size or larger than the source. Actual space taken by data is not considered. You might anyway conveniently resize the source beforehand in order to allow the operation.
Just out of curiosity I tried a transfer between the two spare disks I had attached to the VM (from the 6GB one to the 10 GB one). Not only data but also the filesystem is “pasted” on the target partition: sdb1, initially formatted ext4, has been converted to ext3, filesystem used on sdc1.
More generally and without constraints on size of involved partitions, a simple cp (copy) can be used to trnasfer all files preserving the owner and the attributes (that’s important!). First things first, we have to mount the target partition in its own folder:
$ sudo mkdir /media/precisesdd
$ sudo mount /dev/sda3 /media/precisesdd
Now we can start to copy from source (that I mounted in
/media/Precise) to target, adding options “-r” (recurse subdirectories) and “–preserve=all” (preserves all file attributes):
$ sudo cp -r --preserve=all /media/Precise/* /media/precisesdd/
Least of the work is done…
#3: “All systems clear, cap’n!” – GRUB and fstab
When the copy is over we have to make the newcomer penguin feel comfortable in its new home. We’ll proceed now to remove the source disk or unmount the source partition, so that GRUB won’t detect it. We might even format the source partition if we feel brave and self-confident or unplug the disk; Virtualbox makes no exception to the case.
By instinct I felt I had somehow to mess with GRUB and
/etc/fstab of the new installation. After a couple of failed attempts, always leading to
busybox and errors in partitions UUID, my last hope was to restore GRUB as described in the Ubuntu wiki. In short, although I already had modified
fstab, “something” unknown to me was still pointing to the old partition identifier. If you have any hint about this, please share. Personally, I suspect a sabotage by Romulans, although I have no confirmation about that.
Whatever! I go through the steps in the wiki applying them to the transferred installation (
/dev/sda3) and, surprise, “it works like a charm!”. Last thing to do (now it’s the right time) I replace the old UUID in
/etc/fstab with the new ones. Basically I get the list of partitions with
$ sudo fdisk -l Disco /dev/sda: 21.5 GB, 21474836480 byte 255 testine, 63 settori/tracce, 2610 cilindri Unità = cilindri di 16065 * 512 = 8225280 byte Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Identificativo disco: 0x00091d34 Dispositivo Boot Start End Blocks Id System /dev/sda1 * 2 1414 11349922+ 83 Linux /dev/sda2 2497 2611 916481 5 Esteso /dev/sda3 1415 2496 8691165 83 Linux /dev/sda5 2497 2611 916480 82 Linux swap / Solaris
Then I get the UUID with
$ sudo blkid /dev/sda5: UUID="4f505803-cca8-475e-92da-ad2b9be1d675" TYPE="swap" /dev/sda1: LABEL="Lucid" UUID="cf4b9093-bde0-4159-be79-a5f121b7bd88" TYPE="ext4" /dev/sda3: LABEL="Precise" UUID="e2795fb1-a973-4389-a792-d1a03a77dfe4" TYPE="ext4"
I can now fix
fstab to tell the system where the new root and swap partitions are. In the same way I might update information about a possible separated
/home or other “migrated” partitions.
#4: “Warp speed, Scottie!” – System reboot
Fianlly out of the live session to (try to) boot into the newly populated system. If GRUB restore went well, you should be presented with something like this:
Precise (kernel 3.2) and Lucid (kernel 2.6) are there and that’s a good start. Since Lucid was already on the disk and left untouched, booting it shouldn’t be a problem. Let’s try the hard way then and boot the new resident:
To my great satisfaction, it works!