Clone/copy current installation

English Install/Boot/Login
#1

I have openSUSE 13.1 64bit KDE installed onto a desktop box and have it running and updated to perfectly suit my needs. Now I have added a new (larger) hard drive and would like to clone or copy my running installation to it so I can retire the existing drive. Normally I would just re-install from the DVD but I spent MUCH more time updating, installing added third party software and configuring than I spent on installing from the DVD. The running drive has four partitions. The new drive has nine partitions four of which are slightly larger than the running drive partitions. What is the simplest, fastest way of doing this? I realize I will have to re-configure grub to account for the changed drive id references.

Any suggestions would be much appreciated.

#2

Use Clonezilla, partition images.

Of course, when you go to restore the images to the new drive, you are likely to be wanting to restore to different partitions than on the original disk.

If so, that is done by opening the directory on the backup device where you have stored the Clonezilla backups.

You will have a list of files in there such as this:

sda1.ext4-ptcl-img.gz.aa
sda1.ext4-ptcl-img.gz.ac
     **"**
     **"**
    ** "**
sda1.ext4-ptcl-img.gz.aj 
sda3.ext4-ptcl-img.gz.aa
sda3.ext4-ptcl-img.gz.ab
**     "**
**     "**
**(etc.)**

Mostly self-explained, sda1-- is, of course, sda1, and so on.

To restore, say, sda1 from the original drive to, say, sda4 on the new drive, just rename the sda1-- backup files to the new partition number sda4–, then run Clonezilla’s restore function.

Just watch out. Start with the highest partition number of the backup set. In my example, if you had an sda4 on the original disk, you would first have to rename the sda4 files to the new destination partition name, or you would have a problem when you renamed the sda1 to sda4.

The other thing to watch out for: The new destination partitions must be the same size or larger than the originals. Clonezilla can expand the backups to a larger partition size, but cannot shrink the originals.

#3

Just copy the files you will have to adjust grub and mkinitd to adjust for different drive and possible partition positions. Cloning is fine if you don’t want to change sizes Also not sure why a new drive has 9 partitions??? Certainly you can partition it the way you want.

#4

You probably need to also change “/etc/fstab”, unless you are using cloning software that handles this change.

#5

On 2014-05-21 22:06, ionmich wrote:
>
>

> The new
> drive has nine partitions four of which are slightly larger than the
> running drive partitions.

What are the source partitions, and what are the destination partitions?

If you want to distribute the original 4 partitions into 9, you must
know what each one is for…

Or else, you did not explain your case correctly.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#6

Thanks for the detailed explanation. However I have never used Clonezilla and I am disinclined to learning and using a new tool if I am familiar with old tools (“cp” and “dd”) that work. It’s my old age you see. If the old tools won’t work then it’s time to switch.

#7

I think I will try this method first as copying is faster that using “dd”. I partitioned the new drive to accomodate two extra distributions for experimantal purposes. Three primary root partitions, three extended /home partitions, one extended swap, one large extended data partition and of course one primary to create the extended partitions. Total nine.

#8

“to switch”

… you mean, to another age? :open_mouth:

#9

lol!.

Clonezilla (BTW has the gui improved?) uses “partclone” which I use via SystemRescueCd. As you know it copies just the used blocks, whereas “dd” also copies unused blocks [for the user with “ages” to spare].

#10

On 2014-05-22 12:06, consused wrote:

> Clonezilla (BTW has the gui improved?)

GUI? It is a TUI.

> uses “partclone” which I use via
> SystemRescueCd. As you know it copies just the used blocks, whereas “dd”
> also copies unused blocks [for the user with “ages” to spare].

With the side effect that dd copies grub and other boot managers, and
smart copiers may fail, unless they are aware they have to copy those
“empty” sectors as well. Or some of them at least, and as they are empty
officially, the problem is finding out which of them to copy.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#11

On 2014-05-22 07:56, ionmich wrote:

> I think I will try this method first as copying is faster that using
> “dd”.

Actually, dd is faster, if there are many files.

Copying file by file involves tons of disk head movements, having to
locate the files all over the place, the inodes, etc. A dd simply copies
tracks in sequence, so it goes at the max speed the hardware is capable of.

However, if the target is bigger than the source, you get the extra
complication of expanding the target filesystem aftwards.

Another advantage of ‘cp’ is that the layout is refreshed. Destroys
fragmentation if present. But you have to beware to copy hardlinks and
softlinks as such.

I use rsync myself. It can verify the copy, can be interrupted and
continued.

> I partitioned the new drive to accomodate two extra distributions
> for experimantal purposes. Three primary root partitions, three extended
> /home partitions, one extended swap, one large extended data partition
> and of course one primary to create the extended partitions. Total nine.

Well, in that case, you simply mount the source tree, and the
destination tree, fully, and rsync from one to the other. It does not
matter if the destination has a different partition structure.

But it better be run from a separate live system (I suggest the openSUSE
XFCE rescue USB), so that the source does not have /proc, /sys, and /dev
populated, and that the files are static.

Then, a different issue is installing grub.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#12

Whatever. A mess is a mess lol!.

> uses “partclone” which I use via
> SystemRescueCd. As you know it copies just the used blocks, whereas “dd”
> also copies unused blocks [for the user with “ages” to spare].

With the side effect that dd copies grub and other boot managers, and
smart copiers may fail, unless they are aware they have to copy those
“empty” sectors as well. Or some of them at least, and as they are empty
officially, the problem is finding out which of them to copy.

Has “partclone” failed? I’ve not seen it fail on any backup or recovery, but then I tend to use it regularly for cloning system partitions. I only backup the MBR once using “dd”, of course unless I repartition the HDD.

#13

I modified /boot/grub/menu.lst and /etc/fstab using the new /dev/disk/by-id/ descriptors, but after reading its “man” page I still don’t understand how to invoke mkinitrd from inside a live openSUSE boot (USB). Would I not have to “chroot” to the newly copied drive root directory?

Thanks in advance.

#14

On 2014-05-22 15:46, consused wrote:

> Has “partclone” failed? I’ve not seen it fail on any backup or
> recovery, but then I tend to use it regularly for cloning system
> partitions. I only backup the MBR once using “dd”, of course unless I
> repartition the HDD.

Yes, I have seen it. Some documentation says that grub is not cloned,
but reinstalled.

With some config changes, clonezilla copies some extra sectors
separately from the partition image, precisely for the purpose of
restoring the boot manager.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#15

What documentation says grub (installed where?) is not cloned? Reinstalled how?

With some config changes, clonezilla copies some extra sectors
separately from the partition image, precisely for the purpose of
restoring the boot manager.

I don’t use “clonezilla”, I use “partclone” straight from the command line and it copies all used blocks of a partition. That would need to include the boot sector of a root partition. If it didn’t I wouldn’t have been able to multi-boot several of those after recovery, that I did without any issues.

Clonezilla is based on partclone, partimage, dd, etc. but it contains other programs to save restore a whole disk.

#16

Yes you need to do a chroot to the new drive to run mkinitrd

Also to remake the grub

#17

I must be doing something wrong. I booted from an openSUSE 12.3 Live USB stick. Then …

# mount /dev/sda1 /mnt
# chroot /mnt
# mkinitrd
Kernel image:    /boot/vmlinuz-3.7.10-1.1-default
Initrd image:    /boot/initrd-3.7.10-1.1-default
KMS drivers:     nouveau
Root device:     /dev/root (mounted on / as auto)
Device root not found is sysfs
There was an error generating the initrd (1)

Any suggestions?

#18

After “chroot /mnt”, you should mount at least /proc and /sys

#19

You have to mount /dev/, /sys/, and /proc/ as well.
See mkinitrd’s man page: (“man mkinitrd”)

**RECOVERY
**       What should you do if the initrd is broken and you want to fix it using
       a chroot? I assume /mnt is your target root and /boot is mounted
       inside.

        1. mount --bind /dev /mnt/dev

        2. chroot /mnt

        3. mount /proc

        4. mount /sys

        5. mkinitrd
#20

Thanks for the speedy response. I did read the “man” page but missed the example you quoted which was at the very bottom. However when I followed the instructions…

# mount /dev/sda1 /mnt
# mount --bind /dev /mnt/dev
# chroot /mnt
chroot: failed to run command ‘/bin/bash’: Exec format error
#

I have never seen this error before and do not understand what it means.