cloning hard drives

I’ve asked this question before and haven’t found a definitive answer yet - what files besides fstab and menu.lst would need to be modified after cloning with Clonezille/PING or similar clone software (for system backup purposes)? Presumably they would be identical, but, for instance, menu.lst and fstab have entries that are the drive specific identification that doesn’t get cloned. What other system files do I need to know about and fix after cloning? I don’t think it’s standard for apps to use this disk identification scheme, so I think it’s only the OS I have to worry about.

menu.lst
###Don’t change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.1 - 2.6.27.48-0.3
root (hd0,10)
kernel /boot/vmlinuz-2.6.27.48-0.3-default root=/dev/disk/by-id/ata-ST3500630AS_9QG99D7N-part11 resume=/dev/disk/by-id/ata-ST3500630AS_9QG99D7N-part7 splash=silent showopts vga=0x346
initrd /boot/initrd-2.6.27.48-0.3-default

fstab
/dev/disk/by-id/ata-ST3500630AS_9QG99D7N-part8 /OSS/part8 reiserfs defaults 0 0
/dev/disk/by-id/ata-ST3500630AS_9QG99D7N-part13 /OSS/openSuSE10.3 reiserfs defaults 0 0
/dev/disk/by-id/ata-ST3500630AS_9QG99D7N-part5 /OSS/openSuSE10.2root ext3 defaults 1 2
/dev/disk/by-id/ata-ST3500630AS_9QG99D7N-part6 /OSS/openSuSE10.2home ext3 defaults 1 2

Not a file: but fwiw you might have to think about the active flag, depending if you’re cloning a whole drive or just a partition, and what the boot config is.

Some time back, I wrote about using the ‘dd’ method to clone Cloning an old drive to a new drive . I gave a hypothetical example there for fstab modifications needed PRIOR to cloning (and indeed after edits reboot and confirm the edits work properly).

To the best of my knowledge, if you have a nominal setup, its only those 2 files: /etc/fstab and /boot/grub/menu.lst

On 2010-10-31 06:36, PattiMichelle wrote:

> instance, menu.lst and fstab have entries that are the drive specific
> identification that doesn’t get cloned. What other system files do I
> need to know about and fix after cloning? I don’t think it’s standard
> for apps to use this disk identification scheme, so I think it’s only
> the OS I have to worry about.

Perhaps you might have to reinstall grub. Manually or via /etc/grub.conf.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

If it is an exact clone (partitions and OSs are the same, partition size doesn’t have to be the same, etc), then there’s only three text files that you have to modify to reflect the new disk ID and then openSuse should boot straight in, i.e., change all instances of “ST3500630AS_9QG99D7N” to your new ID (usually obtainable from running your manufacturer’s diagnostic disk, freely dowloadable, or some other means of finding the ID:
/etc/fstab;
/etc/mtab; and
/boot/grub/menu.lst

A live CD and either a text line (joe, namo, pico) or GUI text editor such as Kwrite, Gedit will do the search and replace of all instances in a file.

Always worked for me, but I’ve never had Raid or other “sophisticated” disk arrangements, just straight multi-boot partitions on one HDD. Never had to touch/reinstall Grub, beyond doing the search and replace on Disk ID in menu.lst.

/etc/mtab doesn’t have to be edited, it will be rewritten at each boot.

Hi,

When cloning the new HDD, the files /boot/grub/device.map and /boot/grub.conf need to be checked as well.

My file /boot/grub/device.map used the disk-by-id addressing so needed to be changed.

If your new and old system only has one HDD then possibly /boot/grub.conf does not need modifying.

I think thats a good point about /boot/grub/device.map.

There is no /boot/grub.conf, so I assume you mean /etc/grub.conf. I note for a PC with two hard drives it has:

setup --stage2=/boot/grub/stage2 --force-lba (hd0,2) (hd0,4)
quit

… and I can not imagine a setup where that file would have any disk-by-id specific information.

If you label the partitions you can mount by label. This removes the need to edit fstab

Hi oldpcu,

I stand corrected, /etc/grub.conf is the file referenced.

Code:

setup --stage2=/boot/grub/stage2 --force-lba (hd0,1) (hd0,1)
quit

‘disk-by-id addressing’ only referred to /boot/grub/device.map

code:

(hd0) /dev/disk/by-id/ata-WDC_WD5000ABKS-00A7B2_WD-WCASZ5960444

If the files /boot/grub/device.map, /etc/grub.conf and /boot/grub/menu.1st are not synchronised and correct, my suspicion is that the HDD will not be recognised as a bootable system disk. The correct information being retrieved from the Yast-System-Partitioner.

On 2010-11-01 10:36, keellambert wrote:

> If the files /boot/grub/device.map, /etc/grub.conf and
> /boot/grub/menu.1st are not synchronised and correct, my suspicion is
> that the HDD will not be recognised as a bootable system disk.

Correct. So we have:

/etc/grub.conf
/boot/grub/menu.lst
/boot/grub/device.map

/etc/fstab

Possibly grub itself has to be reinstalled (the stages), and possibly
the initrd file remade, because it can contain a copy of fstab that now
would be incorrect.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

I know dd is the Real Programmer’s way to do it - I remember getting quite confused as I tried to read up about it, tho.

OK, so that’s 4 files, and I can use the OpenSuSE repair function to reinstall the bootloader.
(How would I know that needed to be done?) Here’s where things always get dicey for me - when
I do that, the bootloader repair/reinstall function can’t find the other OS’s I have installed (though,
when doing a fresh install, it finds them just fine). I’ve been told the way to get around that is to
keep a backup of menu.lst. Then just replace the fresh menu.lst with the old one (that contains
the references to the other OS’s)?
TY!!! Patti

When I did this with dd, there was no need to re-install the boot loader. After cloning it just worked for openSUSE.

For winXP after cloning I had to reboot once (under winXP instructions).

Of course a risk when using dd is one slip in syntax :stuck_out_tongue: , and all bits and bytes on your hard drive are history. :open_mouth: :cry:

Yes I got the syntax wrong with dd once and wiped the wrong hd :frowning: - Luckily I had a backup of the important data.

OK, so you’re saying that you cloned metal-to-metal with dd, and then were able to unplug the original drive and the “ghosted” (via dd) drive booted and ran normally? How does it “fix” the 4 files that refer to the drive serial and model numbers? Maybe I do need to work toward an understanding of dd. Is this a good howto? Undiff.com Kubuntu How To’s & News. Linux and Opensource. | Undiff.com

Edit: OR this one…
http://www.howtogeek.com/howto/19141/clone-a-hard-drive-using-an-ubuntu-live-cd/

BEFORE cloning, you need to edit the 4 files (or 3 files, … I don’t think it will be 4 files) and then once those changes are made, reboot your PC and test. Does the boot work properly with the ‘generic’ labels in place? If it does then assuming you have also made the appropriate backups, you are all set to clone.

When you clone, you need to go to same size drive to same size drive. … or same size to larger size, but note then the larger size will not be using all of its available space (and you will need to fix that later).

Once the cloning with dd was done, and with the original drive removed (that is IMPORTANT) then a reboot to the new cloned drive just worked. Grub was copied bit by bit so it booted. Now if there is a problem, do NOT put both drives back in … Instead remove the cloned drive, put the original back in, and then ponder what went wrong. Do NOT mess around with both drives plugged in together as that can mess up your mapping, ESPECIALLY if you have an MS-Windows partition.

Sorry, I don’t have time to read those how tos.

On 2010-11-02 01:06, PattiMichelle wrote:

> OK, so you’re saying that you cloned metal-to-metal with dd, and then
> were able to unplug the original drive and the “ghosted” (via dd) drive
> booted and ran normally? How does it “fix” the 4 files that refer to
> the drive serial and model numbers?

There are for types: labels, uuids, ids, paths. The first two are
created when the partitions are formatted, and thus, cloned. So, the
system will boot with no modification, provided that the original disk
is not plugged in (a conflict). The other two depend on the hardware or
its position, can not be cloned, and will not conflict.

> Maybe I do need to work toward an
> understanding of dd.

dd is just a byte by byte copy, with a command line interface that needs
some learning. A carbon copy, an exact copy. You can clone a small photo
on a big paper, leaving blank margins which is what happens with dd-ing
disks.

It can copy disks, or partitions, or files. It can also do some
translations on the go.

Thus, there is space for “clever” disk cloning tools that do some
modifications, understanding the filesystem, to be able to cope with
different disk sizes. Or for creating partitions images skipping blank
or unassigned spaces.

Dd is not “clever”. It has a fixed mind :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

By ‘generic’ you mean somehow getting rid of the disk-by-id referencing scheme? I’m not sure I picked how to do that up out of the thread.
Here’s my device.map
(hd1) /dev/disk/by-id/ata-Maxtor_6V300F0_V602N42G
(fd0) /dev/fd0
(hd0) /dev/disk/by-id/ata-ST3500630AS_9QG99D7N
A typical menu.lst listing
title openSUSE 11.1 - 2.6.27.48-0.3
root (hd0,10)
kernel /boot/vmlinuz-2.6.27.48-0.3-default root=/dev/disk/by-id/ata-ST3500630AS_9QG99D7N-part11 resume=/dev/disk/by-id/ata-ST3500630AS_9QG99D7N-part7 splash=silent showopts vga=0x346
initrd /boot/initrd-2.6.27.48-0.3-default

So I guess you mean I could just edit menu.lst to read:
title openSUSE 11.1 - 2.6.27.48-0.3
root (hd0,10)
kernel /boot/vmlinuz-2.6.27.48-0.3-default root=(hd0,10) resume=(hd0,6) splash=silent showopts vga=0x346
initrd /boot/initrd-2.6.27.48-0.3-default

…at least that seems to me to be the only way to make menu.lst ‘generic.’

> When you clone, you need to go to same size drive to same size drive. … or same
> size to larger size, but note then the larger size will not be using all of its available
> space (and you will need to fix that later).

Yeppers!

> Once the cloning with dd was done, and with the original drive removed (that
> is IMPORTANT) then a reboot to the new cloned drive just worked. Grub was copied
> bit by bit so it booted. Now if there is a problem, do NOT put both drives back in …

Yeppers. It seems like this approach would work with any ghoster utility.

Thanks for the info, OldCPU. I just had one of my hard drives die, so I’m a bit
nervous about the next few years :wink:

Patti

No, even though the device names are in menu.lst, you should use Linux device paths, not GRUB names, because they are passed as parameters to the init scripts. So that should be:

root=/dev/sda9 resume=/dev/sda7

I hope that for you, /dev/sda9 is / and /dev/sda7 is swap.