Cloning a disk and leaving the clone plugged into the system during a reboot will nearly always cause problems.

1. Cloning a disk duplicates the UUID/volumn name/... This causes confusion when the system attempts to boot (root= always finds two targets)
2. Duplicates volume information for LVM (causes failures during a boot as well).

And the same failures happen with swap partitions.

If you take the cloned disk out you should have no problems (take either the original OR the clone out).

Gparted is a file by file method.

dd is a bit by bit.

Generally one would want to copy or clone a system file by file.

LVM has little to do with number of drives. It may be a benefit to create a lvm to begin with in order to add later in fact.

XFS is a really old filesystem. It is being updated and promoted by RH. Not a lot of people have really played with it for decades like other filesystems. I've run it under Irix but never messed with it.

There are a number of ways to clone systems. One is to look at how the distro suggests to do it. One might use kickstart on a RH based system.

In some systems you simply use a base install and then copy specific user data.

No real one stop shopping on clones.

As I said, REMOVE THE DISK AFTER CLONING.

dd copies duplicate EVERYTHING. disk identification, filesystem identification, volume labels, UUIDs... everything needed to boot is replicated.

And the system cannot identify what to use during boot (since there are two of them).

There was never a time when both drives were in/plugged into the system at the same time during boot. The main drive was in the system, I booted up gparted live from an external USB key, threw the disk I wanted to clone to into a dock, plugged that in, fired it up, did the cloning, powered down, switched out the main drive with the clone drive, and fired up the system.

So there was never an issue of both drives being on while the main system was booted.

You weren't kidding about the ugly side of cloning.

I initially attempted to clone via gparted's copy method, but for some reason was unable to copy the main partition over; I made sure everything was unmounted, the lvm was unlocked, the drive had enough space, I was able to copy to the drive I was cloning to, everything seemed fine, but when I went to select the partition, right clicked, copy was grayed out. Couldn't figure out why, so I resorted to the dd method instead. And now here I am.

I may try a fresh install and simply move files over, but now I worry about the filesystem choice, and if I were to use something other than XFS would I run into issues.

Then the original drive should boot.

The clone will have some corruption due to the mount/in-use filesystems. In your case, swap (at a minimum) may have been active and gotten corrupted (though not sure how, it should have been treated as a crashed system).

dd has always worked for me when I used it (though only on smaller disks. The largest was a 32GB sd card, all other times dd takes far longer than necessary).

The original drive boots perfectly fine, it's the cloned one that doesn't.

I don't understand how the clone could have been corrupted, though. I booted up gparted live on a usb, and used that to clone. I also ensured everything was unmounted first.

Gparted tells you there is a mount issue if it's wrong. You shouldn't need to do anything other than find correct drive. You would have to copy loader.

Most people don't have this issue.


I guess you could have some memory issue or drive issue or bad cable or bad drive controller too. Maybe live cd is setting wrong drive parameters.