1

While playing with my new Debian 9 on Hetzner cloud I've noticed one strange thing. When VM is booted I can see, that eth0 interface is renamed to ens3 (I suspect predictable network names mechanism comes into play). But right after rename is done I can see that ens3 interface name is renamed back to eth0. I see these renames in dmesg output.

[    1.471140] virtio_net virtio0 ens3: renamed from eth0
[    3.212154] virtio_net virtio0 eth0: renamed from ens3

Can someone help me to find out where is this second interface rename is configured as I'm not able to find such configuration nowhere:( Thanks.

  • Have you checked the udev rules? – Gerard H. Pille Feb 19 '18 at 8:24
  • 1
    Yes, I've checked the rules. I looked at /etc/udev/rules.d folder and it is completely empty:/ So because of that I'm saying that I'm not able to find where the second renaming is configured:( – Rimvydas Feb 19 '18 at 8:45
  • telcoM either doesn't believe you or hasn't read your comment. Still, best to check his last suggestion, about "nameif". Let us know how it goes. – Gerard H. Pille Feb 19 '18 at 9:14
  • cat: /etc/mactab: No such file or directory :) So I think that suggestion about "nameif -s" thing is wrong. But I'm starting to think that second renaming is done by the cloud-init. I've tried to disable cloud-init by creating sloud-init.disabled file in /etc/cloud directory and after I rebooted my VM I can see only one renaming to ens3. So as for now I need a way and help to find out how interface renaming is done by cloud-init. – Rimvydas Feb 19 '18 at 9:25
  • In the cloud all these things become much clearer. ;-) – Gerard H. Pille Feb 19 '18 at 9:51
1

If Debian 9 was installed from scratch, it uses the new "predictable network interface names" mechanism. If it was upgraded from an earlier version, it still uses old-style naming - and the file /etc/udev/rules.d/70-persistent-net.rules should be present.

The timing information in your log entries indicates there is about 1.7 seconds time between the two rename operations. That would suggest there might be two mechanisms in play: the first line might be systemd-networkd within initramfs setting up the new-style names, then the second could be when the root filesystem has been mounted and the "real" udev (as opposed to the mini-udev within initramfs) starts up.

Or, if the admins of the Hetzner cloud have implemented the legacy-style names using a different tool, it might be e.g. /etc/rc.local running something like nameif -s, which would read /etc/mactab and set the interface names according to it.

Or if the Hetzner cloud is using cloud-init as you commented, then you might want to check if the /etc/cloud/cloud.cfg.d/custom-networking.cfg file is present. For more details, see:

http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v1.html

http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html

cloud-init can have many possible sources of network configuration information, see:

http://cloudinit.readthedocs.io/en/latest/topics/network-config.html#network-configuration-sources

  • Debian was not upgraded and it is brand new installation. As I said, rules directory is completely empty. There is no /etc/mactab file on my VM. There is no /etc/rc.local file on my system. I'm starting to think that second renaming is done by the cloud-init. I've tried to disable cloud-init by creating sloud-init.disabled file in /etc/cloud directory and after I rebooted my VM I can see only one renaming to ens3. So as for now I need a way and help to find out how interface renaming is done by cloud-init. – Rimvydas Feb 19 '18 at 9:26
  • Updated my answer. – telcoM Feb 19 '18 at 9:43
  • I'm not able to see such a file - /etc/cloud/cloud.cfg.d/custom-networking.cfgon my system. But looking at the cloud-init logs I can see that cloud-init is trying to rename my network interface util.py[DEBUG]: Running command ['ip', 'link', 'set', 'ens3', 'name', 'eth0'] with allowed return codes [0] So, I think that I'll uninstall all of this cloud-init nonsense or will leave cloud-init disabled :) – Rimvydas Feb 19 '18 at 10:03
  • Cloud-init may be doing other things too, that might be important for your ability to use the cloud VM. Like setting up SSH keys to allow you to access your cloud instance. But if you are sure (or willing to experiment), go ahead... – telcoM Feb 19 '18 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.