Cloning Installation

j9x.inca · 08-04-2012, 09:43 AM

I right now have a 16GB SSD in my netbook with Slackware installed on it. I have /dev/sda partitioned to the following:
/dev/sda1 (Swap)
/dev/sda2 (Slackware installation)

I have bought a new 32GB SSD from newegg which I will be installing and would like to clone my Slackware installation so that i can copy it over to a USB, then install my harddrive and install it from USB. This is what I'm thinking of doing but not sure exactly what to do:
1) sda is my harddrive, sdb is my usb. So i start by copying my current installation to my USB so that later I can transfer it to my new hard drive.

Code:

dd if=/dev/sda of=/dev/sdb

2) From here i was thinking of installing the new harddrive, then booting a live usb stick of Damn Small Linux or some type of Live USB. Then fdisk the new harddrive by partitioning the swap and sda2 partition, and then dd from my slackware usb i made earlier to the new harddrive. Or should I just dd my slackware USB and not even fdisk? Also will I need to install LILO again somehow? Not sure honestly how to do this the best way while keeping my slackware installation perfectly like it is, i don't want to lose my configurations and tuned applications I have done.

Didier Spaier · 08-04-2012, 10:09 AM

See here.

vdemuth · 08-04-2012, 10:27 AM

As your going down the live system for restoring purposes, you might want to consider http://partedmagic.com/doku.php?id=start Does everything you want and more.

edbarx · 08-04-2012, 10:33 AM

You try to use the backup utility fsarchiver. This is a CLI tool which archives a whole partition into a single compressed file with the added benefit that it can be restored to a bigger partition that the original.

The commands are these (as root):

Code:

EXAMPLES
   save only one filesystem (/dev/sda1) to an archive:
       fsarchiver savefs /data/myarchive1.fsa /dev/sda1

   save two filesystems (/dev/sda1 and /dev/sdb1) to an archive:
       fsarchiver savefs /data/myarchive2.fsa /dev/sda1 /dev/sdb1

   restore the first filesystem from an archive (first = number 0):
       fsarchiver restfs /data/myarchive2.fsa id=0,dest=/dev/sda1

   restore the second filesystem from an archive (second = number 1):
       fsarchiver restfs /data/myarchive2.fsa id=1,dest=/dev/sdb1

   restore two filesystems from an archive (number 0 and 1):
       fsarchiver restfs /data/arch2.fsa id=0,dest=/dev/sda1 id=1,dest=/dev/sdb1

   restore a filesystem from an archive and convert it to reiserfs:
       fsarchiver restfs /data/myarchive1.fsa id=0,dest=/dev/sda1,mkfs=reiserfs

   save the contents of /usr/src/linux to an archive (similar to tar):
       fsarchiver savedir /data/linux-sources.fsa /usr/src/linux

   save a /dev/sda1 to an archive split into volumes of 680MB:
       fsarchiver savefs -s 680 /data/myarchive1.fsa /dev/sda1

w1k0 · 08-04-2012, 11:02 AM

It isn’t good idea to use dd for that purposes. It copies everything including the boot sector and the partition table. As a result your new 32 GB SSD would look like 16 GB SSD. The minor problem are bad sectors or bad blocks. If the old drive has them dd will copy them to the new drive as is.

I use for that purposes the following procedure:

1. I boot the machine including the source drive using USB stick or CD/DVD including some live distribution (for a few last times I used USB stick with Porteus).

2. I mount the root partition of the source drive in /mnt directory.

3. I use the commands:

cd /mnt
tar czf /the path/to/the_target_file.tgz *

in order to store the root tree in the archive.

4. I move the_target_file.tgz to the USB stick.

(In your case you have to switch the drive after the step 4. and before the step 5.)

5. I boot the machine including the destination drive using the same USB stick or CD/DVD.

6. I prepare the partition table suitable for the destination drive.

7. I prepare file systems using mkreiserfs (for ReiserFS) and mkswap.

8. I mount the root partition of the destination drive in /mnt directory.

9. I use the commands:

cd /mnt
tar xzf /the path/to/the_target_file.tgz

in order to restore the root tree on the destination partition.

10. I chroot to the /mnt directory.

11. I restore LILO using lilo command.

12. I reboot the machine.

I hope I didn’t passed over some important step. The above description is a shortened one so it isn’t fool proof. After the reboot some tuning of the system is necessary in some cases.

kikinovak · 08-04-2012, 11:45 AM

I do have a similar situation sometimes. My solution is to 1) backup my entire system to a local FTP server using Ghost4Linux (raw mode) 2) put the new hard disk in the machine 3) restore it with Ghost4Linux, still in raw mode, and finally 4) load PartedLive and correct the partition size for the disk, which is a simple drag-and-drop operation. Works great, but don't do it without backing up your data first.

j9x.inca · 08-04-2012, 12:39 PM

Thank you all for responses. Not sure which one to try yet :P I will let you guys know which I used and if it worked or not.

Martinus2u · 08-05-2012, 02:56 AM

Quote:

Originally Posted by w1k0

It isn’t good idea to use dd for that purposes. It copies everything including the boot sector and the partition table. As a result your new 32 GB SSD would look like 16 GB SSD. The minor problem are bad sectors or bad blocks. If the old drive has them dd will copy them to the new drive as is.

I second that. Changing disk drives is also a good opportunity to optimize your partition scheme and to start with fresh filesystems. A fresh filesystem allows you to tune parameters more easily. You can optimize your system based on your experience with the previous setup (for instance: optimize the inode count, or use new filesystem features).

Another aspect is the evolution of filesystems, that is kernel and user space, and on-disk-structures.

j9x.inca · 08-05-2012, 07:46 AM

Thanks guys, So I decided to just backup the stuff I really needed and just did a fresh install.

w1k0 · 08-05-2012, 07:19 PM

Anyway that thread is a good place to start for the other people which would like to clone their systems.