The PITA that is u/dev
Udev did it again. Wasting my time during emergency maintenance at a remote datacenter server. The box was flunky and we eventually decided to exchange the hardware to cure sporadic reboots (may have been a faulty cooling fan, …). The question was:
Would the remote machine come back to remote managed life, or would it not?
In the past we usually had no problem with this, even tested it to be prepared for such disaster. But you probably already guessed so from the headline, … udev was again in between us and the network packet flow :-(!
Remote management kept black, and scheduling a reboot into the maintenance PXE & NFS recovery system revealed udev used it’s default persistent name glue to rename the new boards’s NIC with (obviously) different MAC from eth0 to eth1. Hallelujah!
A:
rm -f etc/udev/rules.d/70-persistent-net.rules
and some very unnecessary down-time later an the system was back online running on the new server blade.
And this is even the second time this year the persistent naming got in my way - guess I’ll remove this persistent name gibberish from the default build.
Update: Turned out every new version of udev started to use another just new Linux system-call - as T2 uses dietlibc for the initramfs early-userspace we had to add support for a dozen new system-calls to dietlibc, just to update udev, again, sigh!
