Pi running cloned SD has the same IP as the original

[ab1jx]

There's a discussion at https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=238251&e

Basically I was running an up to date Pi3b and I had another Pi down in the basement which had an SD card go bad. So I picked up a 128 GB Sandisk that was sitting here and cloned onto it. Took it downstairs, plugged it in and booted up. Something wasn't right, it took me a couple days to discover that my DHCP server (an Android phone) had assigned the same IP to both Pis. The MAC addresses are different as they should be. Rebooted the downstairs one and it was still on the same IP. I finally plugged in a USB wifi card and that's fine, different IP.

From the discussion on the Pi forums there are files in /etc that shouldn't be cloned, at least not onto another machine that's going to be running at the same time. I don't pretend to know much about that, I just spotted the duplicate IP right away. I don't know if it's more of a problem with the Android DHCP server or cloning too many files. But some are similar to UUIDs and need to be regenerated when cloning.

Maybe it's some strange isolated case but it might happen again.

[spl237]

The purpose of the SD card cloner, as the name suggests, is to completely copy the original card; to create a clone for backup purposes. This may well lead to problems if you try and run 2 Pis with identical cards on the same network, but equally it may well lead to problems if we try to modify someone's image which they are relying on being a drop-in backup of their existing card.

The program is designed to create an exact backup - if you want a card for a second Pi, you will need to make whatever adjustments are required yourself, I'm afraid.

[ab1jx]

Well, yes, if I cloned an SD with dd I might expect that to happen. But since Piclone has the option of generating new DUIDs (or UUIDs, or whatever else you want to call them, I think they're silly), I was hoping you might add that option for this.

It becomes a political problem of whose fault it is, and since DHCP breaks if you clone an SD (by whatever method) I'd say it's the DHCP people that need to fix it. It's counterproductive for every end user to try to fix it individually because we don't have the knowledge or connections and we'd be reinventing the wheel over and over. Or we'd need a how-to from an authoritative source at least.

It's of significant benefit to be able to just clone a card and update/upgrade it rather than starting from scratch especially if you use/build/write software that isn't in the debs so it's not easily reinstalled. I think I downloaded one copy of Stretch and cloned it, until I ran into this time bomb. What happens if I use mkelfimage I wonder. These foolish UUIDs need to be regenerated and there should be a better way of causing that to happen. Hopefully not manually.

[spl237]

It's not possible to anticipate every possible thing that someone might have done to an image which could cause it to have problems if there are two running on the network. I am therefore not even going to try! The purpose of the SD card copier is as a backup tool; it is intended to create an exact image of the source card; every file, every directory, unchanged, and it is intended to be as simple as possible; no config, no options, just source and target.

The UUID issue is different, as the UUID is not something to do with the files in the image (which the user can change themselves); it is a property of the format of the card. It is trivial for a user to clone a card, mount the cloned copy on the Pi on which they cloned it and change whatever files are causing problems with a second Pi; it is non-trivial for them to fix an identical UUID. It is also hugely confusing if someone clones a card and then tries to mount it on the Pi on which they ran the clone and finds out it doesn't show up - hence the option to change UUID is necessary.

[XECDesign]

Just to add that you'd then also need to regenerate ssh host keys, machine-id and god knows what else.

[ab1jx]

So Windows and Symantec Ghost can do something Linux can't? I used to maintain an office full of Windows machines. Make one good original, then sysprep and Ghost, that image could be loaded onto a machine and have it running in half an hour. Did it for years, sometimes I offloaded it onto a grad student.

This falls into the category of hardware abstraction I think. There should be a tool for that.. Somebody that knows about all of them could write something that regenerates each if present. Or an overall framework holds/starts modules for different things to replace. Maybe something to mention to Debian, needs to have clout behind coordinating it. Does this happen in Debian even? If I do a dump and restore onto a different machine what happens? Probably the same thing.