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.
>
|