A trivial question about UUIDs

[dwasi]

If you clone a drive to build another system, do you bother to change the cloned drive's UUIDs?

I have a primary server and a failover server. The failover is basically just a cloned copy of the primary with a few things changed - hostname, hosts file, mdadm.conf, fstab, static IP, cron backups, and the failover monitoring task.

Because I use dd to clone, the partition UUIDs on both machines are identical. This hasn't caused any problems, because they don't ever need to know each other's UUIDs, so I've never bothered to change them. But I feel like I might be violating some sort of best-practices guidelines?

[CwF]

As you observe it doesn't come up much. It's for internal use only, within an OS.
I have used a 'parent' to write out a clone from a image backup of the very system to a ssd. For a moment it's a tad error prone if you then try to mount the fresh image, you can't.
Moved to another machine and running on the same network there is no issue, nothing cares. The ip and MAC are different.
We can use tune2fs to change the id, but I've yet to find any issue outside of multiple copies mounted within a single system, ie. vm clones on devices exposed on the host, as in passing the entire disk each with the same image. Within an image format like qcow2 as a file the uuid is not exposed to the host.

[LE_746F6D617A7A69]

Probably You'll never see any negative consequences of using the same UUIDs on different machines, but obviously this breaks the idea of having universally unique identifiers.

Besides, the dd method is not the best one -> it has many limitations, like f.e. the target drive size.
Much better method is to just copy the filesystem, using rsync or cp -> You can move the system between different file system types, raid arrays of different layout, etc - no limitations.

[Bloom]

Just remember to edit /etc/fstab and /etc/network/interfaces to accomodate your hardware changes before you reboot the new system.

[andre@home]

We have the same situation since 2011: A primary server and a fail-over server.
In principle it works great like that, indeed update your fstab etc.

BUT: Suppose you would like to compare in de 1st computer this cloned disk... then realize that they have the same UUIDs....
So the system cannot distinguish what you are doing.. are you working in the original disk or the cloned one with the same UUID....?
In order to avoid such a future problem I always change the UUID from cloned disks that are moved to the fail-over server.
And do change the fstab..... (again?)....

So I would say,... your question is not that trivial....

https://www.google.com/search?client=op ... 8&oe=UTF-8

[sgage]

You can definitely have problems if you have duplicate UUIDs. The way I've encountered this is as follows: I make a dd image of an installation. I restore that image to another partition on the same system in order to experiment or upgrade to a new version or such. I run update-grub, reboot, and things can get confused, since grub uses UUIDs. So the grub menu comes up, reflecting the update-grub you did in the original system. But if you select the original system, you might end up with the kernel from the new system. If you have updated the kernel in the new system, it will give the kernel not found error.

So yes, nowadays, when I restore an image to another partition, I change the UUID and edit the fstab to reflect the change.

[andre@home]

@sgage: Thanks for your additional support.. that this UUID-issue does matter...
"The power of repetition"....

[Head_on_a_Stick]

I think we can all agree that the canonical answer to the OP's question is "it depends"