Today (3 July 17) I followed the process suggested by JJJCR except I ran from my Clonezille Live CD throughout; did not copy Clonezilla onto the new drive and then run thru RAM. The clone appears to boot normally and seems to be a complete and working dupe. of my original "sda" drive so I am happy.

The clone does not ask for a password which puzzles me--why would that be the case?

Does not ask a password for what?

It's a bit dangerous to run dd on a active system that is in the midst of writing transactions to disk. You don't know what state your "clone" is in.
If you boot from a live USB with the HD partitions unmounted you will get a consistent clone.

Just in case I didn't read it. Be sure you boot to some live media to use dd command. It won't work correctly within the subject booted hard drive.

fdisk and gdisk require you to specify /dev/sdX device when using -l


From the gdisk manpage.

It is parted that has an -l option that lists all attached drives.

sudo parted -l works. You may have been confusing {f,g}disk with parted.

sudo parted -l will list all actual /dev/sdX devices as well as all LVM and mdraid virtual devices. It lists everything. You should use sudo parted -l instead as it is what you are looking for.

Not so for fdisk.

will list all devices.

As per man fdisk:

This seems to be a sometimes thing! No device is necessary!
gives the following outputgives more readable information.

I was unaware that there was this difference between fdisk and gdisk (GPT fdisk). I use gdisk as I have all GPT partitions except for an old data drive. However parted -l does give more information.

To the OP there is absolutely no need for any screenshot such as in post #11 when the information is textual such as in a terminal window. It is wasteful and actually shows less information than a scrollable code block. Text should simply be copied and pasted into a code block, which is scrollable if the contents are long. Text can also be copied and referred to in future posts.

In addition you gave a full screen grab when your terminal window is about a quarter the area of the whole screen. If you ever do need to make a screen grab to describe a GUI problem do it only for the window in question and not the full screen.

That said in your unneeded screen grab there appears to be a full set of partitions on /dev/sdb. Using dd with the target of sdb would overwrite the whole drive which would be unnecessary. Either the cloning was already done or sdb is in fact the original drive or you should just use rsync with each partition for the cloning. Since you made an unnecessary screen grab I can't scroll up to see what the partition table for sda looks like.

I've used dd dozens of times on a live system. The image is is identical to the original. I think it's an urban myth not to use dd on a live system.

Or, perhaps, if one is making a forensic duplicate, and the machine is the shut down state, you could boot from the Helix live CD in order to avoid changes to the subject file system.

EDIT: I read through the discussion again. It is true that you might not get an exact image using dd on a live system, because of disk writes that may occur after dd has copied a file(s).

But that is also fairly inconsequential, because the image is only useful for back-up once it completes. You can't delete files you might need, while the image is being made, and expect them to be in the image.

Final CloneZilla clone boots properly and appears to be complete,. Only odd thing is it opens without asking for a password, which is good!!. Many thanks for all your pointers and comments and apologies for confusing my screenshots.

dd never did perform; refused to take any action. CloneZillia needs a thorough editing and simplification; I basically followed the defaults, running from a booting CD and ignored all the storm and thunder and warnings and came out OK.

Not an urban myth. Technical fact. It is so easy to boot to a live media and use dd it isn't worth the effort to try it any other way.

i use most on Deft Zero for cloning, special cases on malware stuff.. plain and simple, be careful on encrypted(LUKS) drives, i suggest to unencrypt it first.

Hm, yes, the above methods work ... often, but that's not guaranteed and depends on the disk geometry to be identical to be bootable and giving an identical partition layout. Keep in mind that anything that's dd-based is a byte-by-byte copy of the entire device, so even if you have just 10% of the capacity used on a 500G drive, you still transfer the entire 500G, which, as was pointed out, takes a long time.

I have been using variants of a different scheme for many years. It allows to clone to a disk that has a size different from the original, and also allows to make relatively small-sized backups that can serve as restore points.

1) The idea is that you re-create the same partition layout on the target disk. This even allows you to adjust the partition sizes in the process as long as they are large enough to hold the original content. This is useful if you clone your system to a smaller disk and want to be less generous with the sizes.

2) We then format the new partitions on the target disk the same way.

3) We mount the new partitions somewhere, and

4) we copy (preferably with rsync) the content of each data partition to the equivalent one of the target drive

5) we make the new disk bootable.


For example, here is a partition layout on one of my servers:

that I obtained with the "fdisk -l" command that started this thread.

Using fdisk or parted, create the same layout on the target disk. If you do not want to change anything, and if your disk is below 2G, you can use sfdisk to streamline that process - make sure you don't confuse source and target disk!

sfdisk -d /dev/sda | sfdisk /dev/sdb


(for peace of mind, you might try adding the -n option to make a "dry run" first and see that all is ok:
sfdisk -d /dev/sda | sfdisk -n /dev/sdb
)

You should end up with the exact same layout on /dev/sdb as you have on /dev/sda.

Note: I rarely use this because you can end up with unused space. It's just a few keystrokes to accomplish that layout interactively and subtly adjust sizes so you fill the entire disk. Also, I always make it so that the last /dev/sda8 partition is mounted as /home, and I increase or shrink the space here and /home takes the "overflow", if any.

Here is what is mounted as what on my system:

and /dev/sda6 is the swap partition.

I format the new partitions on sdb the same way:

Before going on, here are the actually used sizes:

You see that the relatively large (20G) /usr partition (sda5) is only 54% used, so if we were to clone to a significantly smaller disk (often happens if you switch from spinning disk to SSD), we could recoup some space by reducing the size to, say, 15G only.

Now let's make the corresponding mount points:

(the "n" stands for "new"). You mount the target partitions:

and then we rsync the file systems over one by one:

(note that each source in rsync ends with a slash (/) - important. The "x" says not to cross file system boundaries, which is needed here.)

How to make the target disk bootable depends on whether you use grub or grub2, but I usually chroot to the new root partition and make it bootable there. (I can provide more info if you don't know how).

At this point, we have a guaranteed-to-work clone in hand.

This method is super-versatile. I use this scheme for many other applications, and as you may have guessed, I have this all scripted. I often install dozens of machines in one fell swoop, and I use this method to set up each system from a "restore point" - the ultimate backup. In this way I get 100% identical systems, and all it takes is to customize a few configuration files to give the new clone its new identity (that is automated, too). Ip address, hostname, ssh host keys, and the like.

How to get such a restore point?

Staying with my partition layout, I make a tarball of each partition's contents:

If my harddisk crashes one day, I boot from a CD and do the same make partitions/format/mount steps, only instead of the rsync commands above I populate the partitions from the tarballs. Make the new disk bootable as before, done.

I hope this helps and shows a more versatile way.

But it isn't dangerous either. The entire purpose of dd is to use it on a live system. That's why it was written. That's the way it's been done for almost fifty years!

We didn't always have live CDs.

But not to belabor the point, if anyone feels better using a live CD to clone, far be it from me to contradict such a thing. I still cannot find a single documented instance in which cloning a live system caused a problem.

The US Department of Justice has done extensive testing with dd on live systems. Many times it is the preferred method!

If you use dd to copy an active read/write filesystem, what you get is an image of what you would have if you yanked the power plug on the running system.** There may be partially written open files, inodes using space but with no link in any directory, block usage bitmaps that are not consistent with the blocks actually claimed by inodes, and various other inconsistencies in the filesystem metadata. It's probably nothing that a quick preen by fsck can't patch up, but it's a rather foolish way to clone a system.

**Somewhat worse than that, really, since the dd operation takes significant time, so there can be inconsistencies between parts of the filesystem that were copied earlier and parts that had subsequent changes that were seen later in the operation.

2 members found this post helpful.