Thanks. I'm actually not too far from Notre Dame. Not going out to watch the disaster tonight but tomorrow the cityscape won't be too pretty I'm afraid.
That's the other possibility. I was cloning SDs a year or so ago and this never happened. I used piclone. Maybe it should leave out /etc/machine-id or generate a new one, like it can generate new UUIDs.epoch1970 wrote: ↑Mon Apr 15, 2019 7:27 pmIt seems unlikely that the DHCP server only uses 3 bytes to match an IP.
Systemd has made the role of /etc/machine-id (a D-Bus thing) more prominent, perhaps your DHCP client uses that ID when it talks to the server.
Of course, there are special motions to go through in case you want to re-generate /etc/machine-id.
That's what I don't like about setting it from a config file. Used to be, it was in the hardware of the interface card and not changeable.PhatFil wrote: ↑Wed Apr 17, 2019 2:43 amIm sure i have come across a Pi 'How to' that details a method of specifying the mac addy to use, of course i have failed in my google-fu to find it to link .. I can only assume that if my recall is correct and such a 'fix' is Pi applicable, Then in such a case where a user specified Mac addy is applied I would suggest that Yes The mac addy would also be duplicated with a system disk clone since it Must be applied through a file.
I was hoping they might dig into it and provide an option to generate new DHCP UUIDs like they do for partition UUIDs. Maybe somebody (not me) will create a fork that does that. I didn't know it was mostly for backups, I've been using it in place of downloading a fresh image when I get a new machine. For years.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.
Code: Select all
d530# cd /etc d530# ls -lR | grep -i dhcp drwxr-xr-x 4 root root 4096 Nov 18 19:25 dhcp ./dhcp: ./dhcp/dhclient-enter-hooks.d: ./dhcp/dhclient-exit-hooks.d: uname -a Linux d530 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13) x86_64 GNU/Linux
Code: Select all
drwxr-xr-x 4 root root 4096 Nov 13 08:04 dhcp -rw-rw-r-- 1 root netdev 1701 Sep 10 2018 dhcpcd.conf -rw-r--r-- 1 root root 42 Nov 13 09:02 dhcpcd.duid -r-------- 1 root root 192 Nov 13 09:02 dhcpcd.secret lrwxrwxrwx 1 root root 13 Nov 13 08:22 dhcpcd -> /sbin/dhcpcd5 lrwxrwxrwx 1 root root 32 Nov 13 08:22 dhcpcd.8.gz -> /usr/share/man/man8/dhcpcd5.8.gz ./dhcp: ./dhcp/dhclient-enter-hooks.d: ./dhcp/dhclient-exit-hooks.d: -rwxr-xr-x 1 root root 1901 Sep 14 2015 dhcpcd lrwxrwxrwx 1 root root 16 Nov 13 08:22 K01dhcpcd -> ../init.d/dhcpcd lrwxrwxrwx 1 root root 16 Nov 13 08:22 K01dhcpcd -> ../init.d/dhcpcd lrwxrwxrwx 1 root root 16 Nov 13 08:22 S01dhcpcd -> ../init.d/dhcpcd lrwxrwxrwx 1 root root 16 Nov 13 08:22 S01dhcpcd -> ../init.d/dhcpcd lrwxrwxrwx 1 root root 16 Nov 13 08:22 S01dhcpcd -> ../init.d/dhcpcd lrwxrwxrwx 1 root root 16 Nov 13 08:22 S01dhcpcd -> ../init.d/dhcpcd lrwxrwxrwx 1 root root 16 Nov 13 08:22 K01dhcpcd -> ../init.d/dhcpcd -rw-r--r-- 1 root root 0 Apr 20 09:03 dhcp.conf drwxr-xr-x 2 root root 4096 Nov 13 08:22 dhcpcd.service.d lrwxrwxrwx 1 root root 34 Nov 13 08:22 dhcpcd5.service -> /lib/systemd/system/dhcpcd.service ./systemd/system/dhcpcd.service.d: lrwxrwxrwx 1 root root 34 Nov 13 08:22 dhcpcd.service -> /lib/systemd/system/dhcpcd.service
A strange usage of the word "should" there, given that it was me who wrote Piclone. So I think it's probably up to me to decide what it *should* do, not you, don't you?
Maybe I wrote "should" too.
I am cloning hundreds of SD cards and can say that piclone has nothing to do with WLAN MAC addresses.