2

On some ArchLinux servers I've switched from dhcpcd to dhclient, but the servers are not receiving IP. Upon inspection with journalctl I see that, on all occasions the IP was not received, dhclient attempted to operate on the interface and then the interface got renamed. The lines in question are:

dhclient[461]: Failed to get interface index: No such device
...
kernel: igc 0000:6f:00.0 enp111s0: renamed from eth1

What is this "interface renaming" business and how is it possible that dhclient is not predictably ordered around it?

Then of course, later on, the following command fixes DHCP:

sudo systemctl restart dhclient@enp111s0.service

More logs:

May 14 19:03:32 serverski systemd[1]: Reached target Multi-User System.
May 14 19:03:32 serverski systemd[1]: Reached target Graphical Interface.
May 14 19:03:32 serverski dhclient[487]: Cannot find device "enp111s0"
May 14 19:03:32 serverski dhclient[461]: Failed to get interface index: No such device
May 14 19:03:32 serverski dhclient[461]: Failed to get interface index: No such device
May 14 19:03:32 serverski dhclient[461]: If you think you have received this message due to a bug rather
May 14 19:03:32 serverski dhclient[461]: than a configuration issue please read the section on submitting
May 14 19:03:32 serverski dhclient[461]: bugs on either our web page at www.isc.org or in the README file
May 14 19:03:32 serverski dhclient[461]: before submitting a bug.  These pages explain the proper
May 14 19:03:32 serverski dhclient[461]: process and the information we find helpful for debugging.
May 14 19:03:32 serverski dhclient[461]: exiting.
May 14 19:03:32 serverski dhclient[461]: 
May 14 19:03:32 serverski dhclient[461]: If you think you have received this message due to a bug rather
May 14 19:03:32 serverski dhclient[461]: than a configuration issue please read the section on submitting
May 14 19:03:32 serverski dhclient[461]: bugs on either our web page at www.isc.org or in the README file
May 14 19:03:32 serverski dhclient[461]: before submitting a bug.  These pages explain the proper
May 14 19:03:32 serverski dhclient[461]: process and the information we find helpful for debugging.
May 14 19:03:32 serverski dhclient[461]: 
May 14 19:03:32 serverski dhclient[461]: exiting.
May 14 19:03:32 serverski systemd-udevd[380]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 14 19:03:32 serverski systemd[1]: dhclient@enp111s0.service: Main process exited, code=exited, status=1/FAILURE
May 14 19:03:32 serverski systemd[1]: dhclient@enp111s0.service: Failed with result 'exit-code'.
May 14 19:03:32 serverski audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dhclient@enp111s0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=fail>
May 14 19:03:32 serverski systemd-udevd[427]: Using default interface naming scheme 'v247'.
May 14 19:03:32 serverski systemd-udevd[427]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 14 19:03:32 serverski kernel: r8169 0000:70:00.1 enp112s0f1: renamed from eth0
May 14 19:03:32 serverski kernel: iTCO_vendor_support: vendor-support=0
May 14 19:03:32 serverski systemd-udevd[382]: Using default interface naming scheme 'v247'.
May 14 19:03:32 serverski systemd-udevd[382]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 14 19:03:32 serverski kernel: ee1004 0-0051: 512 byte EE1004-compliant SPD EEPROM, read-only
May 14 19:03:32 serverski kernel: ee1004 0-0053: 512 byte EE1004-compliant SPD EEPROM, read-only
May 14 19:03:32 serverski kernel: igc 0000:6f:00.0 enp111s0: renamed from eth1
haelix
  • 187
  • 2
  • 6

1 Answers1

0

Posting a workaround to my own issue.

After troubles with dhclient (this question) as well as other troubles with dhcpcd (that I didn't fully get to the bottom of, but simply switching to dhclient as a drop-in replacement solved them, since for both you need to just to systemctl enable dhclient@iface.service), I have come to the conclusion it's best and cleanest, to ditch both dhclient and dhcpcd in favour of systemd-networkd, which can be configured easily to handle DHCP, see here, without the need for extra packages.

Using systemd-networkd's own DHCP handling logically would solve the naming issue since I believe it's the same systemd component that does the interface renaming.

haelix
  • 187
  • 2
  • 6