Before the UUID method was introduced, cloning was not an issue.

This brings up a second issue.  Assume that the cloning works using a 
hardware cloning device -- that has worked before between different 
vendor's physical hard drives of the nominally same capacity or that 
worked by cloning a smaller drive onto a larger drive and then 
formatting the "unformatted" larger portion, etc. (I have done this both 
with EIDE and SATA drives -- and SCSI long ago on rack-mounted systems.) 
What happens if one attempts to use the "old" drive in a, say, SATA to 
USB adapter that normally would allow a SATA drive to mount as a USB device?

As the internal harddrive and the USB mounted external hard drive have 
the same UUIDs (clones), there would be a conflict. (This approach did 
work before UUIDs, even with the same named partitions -- one manually 
mounted a /usr partition on the external drive under a mount point such 
as /usrusb, and the like -- new mount points for, say, /dev/sdc1 that 
had the same name -- /usr -- as /dev/sda1.)

Is there any similar "trick" for mounting an external hard drive via a 
USB interface (or any other such interface to a different standard) even 
though nominally each has the same "identifier", now a UUID?


On 5/11/21 8:34 PM, Alec Habig wrote:
> If you clone the whole thing using a lowlevel tool, say "dd": it will
> also clone the UUIDs.
> 
> In your case, if you plan on removing the old disk before booting up
> with the new disk, that means it should just happily "wake up" in its
> new disk and never know the difference.
> 
> On the other hand, if you're trying to clone partitions around onto new
> disks this way without pulling the old disk out (trying to expand your
> storage), then the duplicate UUIDs cause you trouble, because you'd have
> devices with the same UUID.  You can generate new UUIDs if this is the
> case, by temporarily addressing things using hardware addresses instead.
> 
> I've done this using similar disks (replacing failing drives) and it
> worked fine.  But, I'm not sure if the differences in low-level
> geometry/blocksizes between different technology disks could cause a
> problem.  I suppose it can't hurt to try: you can always reformat the
> new disk if it doesn't work.
>