The options to disable “predictable device names”, e.g. “net.ifnames=0 biosdevname=0” appended to /boot/cmdline.txt, is currently broken. Eth0 gets renamed though wlan0 does not.
I’m running a cluster of 8+ rpis with a common system image. Requiring each one to be hand tweaked from a local keyboard, mouse, and monitor is untenable as all need to run headless.
I fully understand the motivation for “predictable device names” for single server configurations, but they completely break normal network configuration management. I don’t mind that it’s there, I don’t even mind if it is the default, but making it mandatory (trashing backwards compatibility) is unnecessary and high undesirable.
Perhaps it’s just a bug, but it sure isn’t a feature!
1 Like
Isn't the normal place to set those kernel parameters in /etc/default/grub ?
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0"
Perhaps, but not on a Raspberry Pi, which doesn’t boot with grub.
1 Like
Looks like predictable device names were set by /lib/udev/rules.d/80-debian-compat.rules so all I had to do was to mask it:
# ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules.
Now I have my eth0 back 
Thanks.
I found another solution that works like a charm. Edit
/lib/udev/rules.d/73-usb-net-by-mac.rules and break the line starting
with “IMPORT” at the first comma. Reboot and sanity returns.
It appears that they decided to introduce “predictable device names” in
a point release, put in a mechanism for backwards compatibility, and
neglected to test it.
The bug was reported in April. There was a false start in fixing the
problem, also from a failure to actually test the the fix, and was
finally fixed a couple of weeks ago, though I don’t think it has been
pushed completely through the update system.
But I’m up and running with 9 cloned systems issued IP and hostnames via
DNSMASQ/DHCPD.
But thanks for the workaround.