0

I have a brand new ubuntu 16.04 image that I've created with packer based on the bento configs. My config is nearly identical to the 16.04 config here

My ubuntu vm fails to get a dhcp lease, even after rebooting. Other windows and centos VMs on the same vlan get their dhcp leases no problem.

The only way I get a lease is if I manually run dhclient

/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens32
iface ens32 inet dhcp
pre-up sleep 2

When I check cat /var/log/syslog | grep -Ei 'dhcp', I see the dhcp client starting. Strangely it is requesting an IP in the 172.16.x.x network ( I'd expect a 10.x.x.x IP).

Dec  2 21:17:02 vagrant dhclient[688]: Internet Systems Consortium DHCP Client 4.3.3
Dec  2 21:17:02 vagrant sh[676]: Internet Systems Consortium DHCP Client 4.3.3
Dec  2 21:17:02 vagrant dhclient[688]: For info, please visit https://www.isc.org/software/dhcp/
Dec  2 21:17:02 vagrant sh[676]: For info, please visit https://www.isc.org/software/dhcp/
Dec  2 21:17:02 vagrant dhclient[688]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 3 (xid=0x76d9e602)
Dec  2 21:17:02 vagrant sh[676]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 3 (xid=0x76d9e602)
Dec  2 21:17:03 vagrant dhclient[688]: DHCPREQUEST of 172.16.148.140 on ens32 to 255.255.255.255 port 67 (xid=0x2e6d976)
Dec  2 21:17:03 vagrant sh[676]: DHCPREQUEST of 172.16.148.140 on ens32 to 255.255.255.255 port 67 (xid=0x2e6d976)
Dec  2 21:17:03 vagrant sh[676]: DHCPOFFER of 172.16.148.140 from 172.16.148.254
Dec  2 21:17:03 vagrant dhclient[688]: DHCPOFFER of 172.16.148.140 from 172.16.148.254
Dec  2 21:17:03 vagrant dhclient[688]: DHCPACK of 172.16.148.140 from 172.16.148.254
Dec  2 21:17:03 vagrant sh[676]: DHCPACK of 172.16.148.140 from 172.16.148.254
Jan  5 16:53:56 vagrant kernel: [    6.068252] audit: type=1400 audit(1483635236.420:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=951 comm="apparmor_parser"
Jan  5 16:53:56 vagrant kernel: [    6.068256] audit: type=1400 audit(1483635236.420:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=951 comm="apparmor_parser"
Jan  5 16:53:58 vagrant dhclient[1115]: Internet Systems Consortium DHCP Client 4.3.3
Jan  5 16:53:58 vagrant ifup[965]: Internet Systems Consortium DHCP Client 4.3.3
Jan  5 16:53:58 vagrant ifup[965]: For info, please visit https://www.isc.org/software/dhcp/
Jan  5 16:53:58 vagrant dhclient[1115]: For info, please visit https://www.isc.org/software/dhcp/

Looking at cat /var/log/syslog | grep network I see it failed to start the network interface.

vagrant@vagrant:~$ cat /var/log/syslog | grep network
Dec  2 21:14:06 vagrant systemd[1]: Strating Raise network interfaces...
Dec  2 21:14:06 vagrant systemd[1]: Started Trigger resolvconf update for networkd DNS.
Dec  2 21:14:06 vagrant ifup[2794]: /sbin/ifup: waiting for lock on /run/network/ifstate.ens32
Dec  2 21:14:07 vagrant systemd[1]: Started Raise network interfaces.
Dec  2 21:15:54 vagrant systemd[1]: Started Trigger resolvconf update for networkd DNS.
Dec  2 21:17:02 vagrant systemd[1]: Starting Raise network interfaces...
Dec  2 21:17:02 vagrant systemd[1]: Started Trigger resolvconf update for networkd DNS.
Dec  2 21:17:02 vagrant ifup[724]: /sbin/ifup: waiting for lock on /run/network/ifstate.ens32
Dec  2 21:17:03 vagrant systemd[1]: Started Raise network interfaces.
Jan  5 16:53:56 vagrant systemd[1]: Started Trigger resolvconf update for networkd DNS.
Jan  5 16:53:58 vagrant systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Jan  5 16:53:58 vagrant systemd[1]: networking.service: Unit entered failed state.
Jan  5 16:53:58 vagrant systemd[1]: networking.service: Failed with result 'exit-code'.

From my research that can happen when upgrading ubuntu from 14.04 and 16.04 and the network interfaces don't get renamed properly from the legacy eth0 to the modern ens32. Since this is a brand new ubuntu install, that seems unlikely. Since I can simply run dhclient to fix the problem, it seems my interface is initialized.

https://askubuntu.com/questions/758594/no-networking-failed-to-bring-up-eth0

Where else can I look to find why the networking interface fails to initialize.
Why would dhcpclient not be running automatically?

Update

Running the following gets the network device up, but still no automatic dhcp lease

root@vagrant:~# ip link set ens3 up
root@vagrant:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:0f:a4:c0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fe0f:a4c0/64 scope link
       valid_lft forever preferred_lft forever

Update

The 172.x.x.x ip address showing up in the logs was from december 2nd. This was when the image was built on vmware.

  • How is it not getting a lease? Your screen shot shows it requesting, receiving, and acknowledging 172.16.148.140 . [eta]: ok, next screen shot shows problem with interface coming up, but that doesn't match the current title of the question. – user4556274 Jan 5 '17 at 20:11
  • Yes, but this is a 10.x network. I have no idea where 172.16.x.x is coming from. – spuder Jan 5 '17 at 20:14
  • I have transcribed the contents of your screenshots for you, but you may want to check for errors in transcription. – Fox May 7 '17 at 0:28
1

Why do logs show 172.16.x.x network?

The vm was created on vmware (with packer), then migrated to kvm. The logs are from before the vm was migrated.

Why does vm not get an ip address?

When the vm was on vmware, its network adapter was ens32 After migrationm, the vm network adapter is now called ens3
/etc/network/interfaces still references the old ens32

This is a side affect of the new 'Predictable Network Interface Names' that started in Ubuntu 15.10

The short term fix is to edit /etc/network/interfaces. The long term automated fix is covered here:

Predictable Network Interface Names break vm migration

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.