Ubuntu server 20.04 fails to get IP address from DHCP server (no network connectivity)

Bug #1881832 reported by psl
30
This bug affects 4 people
Affects Status Importance Assigned to Milestone
netplan.io (Ubuntu)
Invalid
Undecided
Unassigned
subiquity (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Ubuntu 20.04 server amd64, running as virtual machine on FreeNAS-11.3-U3.2.
Network interface was configured with driver VirtIO, and network interface is bridged at FreeNAS.

The issue is that I have DHCP server in my LAN and Ubuntu installer gets IPv4 address and applies updates from internet. Install process is OK. Once installation is finished, reboot is required but Ubuntu will start but no IP address is assigned to enp0s4 interface, so Ubuntu 20.04 server has no network connectivity. I can manually force IP address allocation with command "sudo dhclient enp0s4" and it works but that is just a workaround. IP address should be allocated automatically during server boot...

I have older Ubuntu machines on the same FreeNAS box and those work fine, so I assume there is a bug in Ubuntu 20.04 and DHCP client is broken or not reliable... :-( Some problem in netplan utility??

I tried to install fresh 18.04.4 to my FreeNAS box and I see the same problem, no IP address is assigned during boot. That is strange because old installation of 18.04 from the past works fine.

I tried to install 20.04 to VMware ESXi 6.7 and I see the same problem, no IP address is assigned to the new instance (install is OK, but after restart, no network connectivity, "dhclient ensp0s4" is working fine).

Summary is that I see similar problem on fresh installs of 20.04 and 18.04, FreeNAS or ESXi. I can connect instances with "dhclient enp0s4", so it looks like DHCP server works fine and there is no problem on LAN...

psl (slansky)
description: updated
Revision history for this message
psl (slansky) wrote :

This is in file etc/netplan/00-installer-config.yaml (enp0s5 is configured with DHCP4, but real NIC is enp0s4...)

#####
# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s5:
      dhcp4: true
  version: 2
#####

This is visible in output from "sudo journalctl":

...
Jun 05 02:53:44 t2004 kernel: virtio_net virtio1 enp0s4: renamed from eth0
...
Jun 05 02:53:53 t2004 systemd-resolved[718]: Using system hostname 't2004'.
Jun 05 02:53:53 t2004 systemd[1]: Started Network Name Resolution.
Jun 05 02:53:53 t2004 systemd[1]: Reached target Network.
Jun 05 02:53:53 t2004 systemd[1]: Reached target Host and Network Name Lookups.
Jun 05 02:53:54 t2004 cloud-init[727]: Cloud-init v. 20.1-10-g71af48df-0ubuntu5 running 'init' at Fri, 05 Jun 2020 02:53:53 +0000. Up 15.84 seconds.
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: +++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: | enp0s4 | False | . | . | . | 00:a0:98:4f:5d:d5 |
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: | lo | True | ::1/128 | . | host | . |
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: +-------+-------------+---------+-----------+-------+
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: | Route | Destination | Gateway | Interface | Flags |
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: +-------+-------------+---------+-----------+-------+
Jun 05 02:53:54 t2004 cloud-init[727]: ci-info: +-------+-------------+---------+-----------+-------+
...

Revision history for this message
psl (slansky) wrote :

I fixed /etc/netplan/00-installer-config.yaml, I replaced "enp0s5" with "enp0s4" and I rebooted virtual machine. Issue is fixed, it gets IP address from DHCP server during server boot! So it looks like "subiquity" just created wrong netplan configuration. So basic configuration and it was not done right... :-(

I have found other similar bug report, #1824483, so it looks like this problem is in Ubuntu for long time; that surprises me...

Revision history for this message
psl (slansky) wrote :

I created bug against subiquity, #1882162

Revision history for this message
Nicholas Payne (nicpayne713) wrote :

I am having these simlar issues but haven't even been able to get the netplan config changes to fix the network connectivity on startup

Revision history for this message
Troy High (jthigh) wrote :

I have the same issue with my Ubuntu Server 20.04, after each reboot, I only appear to get IPv6 from DHCP.

Manually renewing using:
sudo dhclient -r eth0 & sudo dhclient eth0

Resolves the issue but I would like to find a way to consistently get both IPv6 & IPv4 on eth0 every time I restart.

Revision history for this message
Stefan Biermann (stefanbiermann) wrote :

Same issue here:
Multiple Ubuntu 20.04.1 LTS (Desktops & Servers) affected:
Only IPv6 address via DHCP after reboot, no IPv4, thus no (internal) DNS resolution (network shares fail when binded via hostnames).
As a workaround all network shares are now mounted via IP address and dhclient has to be called after each reboot manually (to get SLURM workloadmanager working).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in netplan.io (Ubuntu):
status: New → Confirmed
Revision history for this message
Anthony Bush (distributedfog) wrote :

Same issue on multiple Ubuntu 20.04 VM's. My fix differs since the name of my adapters differs, but my solution similar:

sudo dhclient -r enp1s0 && sudo dhclient enp1s0

Revision history for this message
Lukas Märdian (slyon) wrote :

The core problem seems to be the changed interface names. I'm not sure why this might happen after a reboot? (LP: #1882162)

@distributedfog have you been able to try adopting the netplan YAML in /etc/netplan/*.yaml to the correct interface name? Does this make it work?

Using dhclient in parallel to netplan/systemd-networkd might lead to conflicts, as there are two DHCP clients running at the same time.

Revision history for this message
Anthony Bush (distributedfog) wrote :

@slyon, I just attempted this on one of my VM's. Modified the netplan yaml file (only one in there, titled 000-installer-config.yaml). Modified en1s0 to enp1s0, and rebooted the machine and it pulled an IP correctly via DHCP.

Revision history for this message
Lukas Märdian (slyon) wrote :

Okay. In this case I think this is not a netplan problem. But the config provided to netplan is somehow wrong.

Did you change your hardware in between? Or maybe it's the installer setting an invalid interface name? What installer did you use on your system?

Changed in netplan.io (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Kalev Ilves (k76) wrote :

Installed 20.04LTS Desktop on Hyper-V, after install there is no network connectivity, host network is ipv4 only network with dhcp, no other VM (or physical) has any issues. This is how it is immediately after install and updates.

/etc/netplan/01-network-manager-all.yaml only constains 3 lines:

network:
  version: 2
  renderer: NetworkManager

Nothing else. After manually adding:
  ethernets:
    eth0:
      addresses: [ 192.168.0.20/24 ]
      gateway4: 192.168.0.1
      nameservers:
        addresses: [192.168.0.1, 1.1.1.1, 1.0.0.1]

there is connectivity. But now DNS doesn't work (plenty of topics this around internet without a definite resolution), quick fix is to:

sudo echo nameserver 192.168.0.1 > /etc/resolv.conf

unfortunately i've no idea of a more permanent fix, this must be done after every boot.

Revision history for this message
Lukas Märdian (slyon) wrote :

That netplan config looks correct. Basically it just hands off to NetworkManager.

Are you sure the DHCP is passed through to your VM? NetworkManager would normally setup a DHCP connection for you – if available.

IMHO there is something wrong with the network setup on your host about passing through the DHCP.
With your updated netplan config you specify a static network configuration (no DHCP), which is apparently working.

Revision history for this message
psl (slansky) wrote :

I have an update. I tried yesterday TrueNAS Core 12.0U1.1 and I tried to install Ubuntu server 20.04.1 to test Virtual machine configuration. I cannot report any good news, bug was not fixed. Installation of Ubuntu was easy, it got IPv4 address from local DHCP server and installed several updates during installation process. Once installation was finished and virtual machine was rebooted, new virtual server was not able to get IP address from DHCP server. I have to manually fix file /etc/netplan/00-installer-config.yaml, network interface was wrong (by 1).

This issue is really simple to reproduce. Ubuntu and TruNAS Core are free software, anyone can download these and replicate the issue.... I believe there is a bug in Ubuntu installer, it creates netplan config file in a wrong way. I am not sure just now but I think I modified enp0s5 to enp0s4. Virtual machine had the only one virtual network interface and I use VirtIO network adapter.

Revision history for this message
psl (slansky) wrote :

I have a comment to issue reported by user "k76". I guess you updated your netplan config file in a wrong way. It is unlikely that your network interface is "eth0" in Ubuntu 20.04. Check what is your real network interface name with cli command "ip a" or "ipconfig"...

"eth0" was in the past the first Ethernet interface. It was working good for long time and it was really boring so developers (systemd??) decided to generate new cool names that are different on each PC so users have more fun when they troubleshoot their network issues.. ;-)

Revision history for this message
psl (slansky) wrote :

I tried to create another virtual machine with Ubuntu running on TrueNAS server and I carefully monitored devices during install process.

The source of this problem is at I have to use CD-ROM image during install but I have to remove CD-ROM device to start Virtual machine with Ubuntu. TrueNAS doesn't offer any option to use CDROM without disk image (it reports an error when file with ISO image is not found) and I have to remove CD-ROM device (SATA controller). When I remove CD-ROM device, device indexes at PCI bus (lspci output) are changed. ETH device is during install really enp0s5 but once CD-ROM device is removed from virtual machine configuration, it becomes enp0s4. This was not a problem in the past when the first ETH device was always "eth0 " but now it is a problem because any change on PCI can result in different interface name; enp0s5 in the install configuration becomes en0s4 in the run configuration...

Revision history for this message
psl (slansky) wrote :

CDROM cannot be empty in FreeNAS/TrueNAS (bhyve): https://redmine.ixsystems.com/issues/65313

Revision history for this message
Grzywa (grzywa) wrote :

So I'm on Ubuntu server 20.10 guest on KVM host (currently Unraid). I should mention that I'm not using virtio network but I have passedthrough my physical Intel network card.

I'm not getting ipv4 on boot, only ipv6.
After it's booted I can log in and simply renew dhcp using dhclient command. And it works finr I'm finally getting ipv4 from my DHCP server on the network.

Now I didn't have any problems with netplan config file. Device name was correct and corresponded with my current device name - in my case enp3s0.

I did not remove iso after install as this KVM host will not boot from ISO after installation. I have removed it asfter few reboots to see what will happen and - nothing chnaged my network interface is still enp3s0.

So tu summarise, this issue might not be exactly related to config in netplan. As it seems to be all in order in my installation. But still I'm not getting ipv4 at boot. Well it happened maybe once or twice when on boot it got ipv4. Maybe 1 in 10/15 reboots.

ps. I have cteared 3 VM's with same ubuntu 20.10 iso, with 3 different physical NIC's passed to VM. Same problem on each machine.

It's surprising to see that's it's happening since over six months. Is seems like it came with one of kernel updates.

Revision history for this message
Grzywa (grzywa) wrote :

OK, update. I found the reason why it's happening.
I have two HDCP servers running in my lab. Different networks but on the same switch you could see both. As ssoon as I shut down one of DHCP servers all went back to normal. Each machine on each reboot it getting proper IP from DHCP that is alive.

As soon as there are two DHCP servers on the same physical network ubuntu sometimes is not getting ip on boot. It would pull an IP every 2-3 reboots.
What is strange it has no problem getting IP with two DHCP servers once it's fully booted. I could release IP and renew multiple times and it would get one each time. The issue is only on boot. No oher of my machines in lap are showing this behavior, only ubuntu ones (not that I tested a lot in this configuration).

Revision history for this message
Lukas Märdian (slyon) wrote :

Okay. It looks like we're discussing all sorts of DHCP issues here. Let's stick to the original problem of invalid interface name, which seems to be a subiquity issue and duplicate of LP: #1882162 caused by attaching/detaching CDROM drive.

Changed in netplan.io (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Anthony Bush (distributedfog) wrote :

@slyon - I use unraid here, and if I modify the VM configuration at all (I just mounted an unraid share through unraid's VM manager, and rebooted my Ubuntu Server - no IP address). I made no changes beyond that, which seems odd, (and I understand that unraid's VM manager is not applicable per-say here) just figured I would provide the additional information. Seems to happen anytime the configuration changes - the device name in Ubuntu is modified, but the netplan configuration keeps the original ethernet device name from the install. In this specific case, 00-installer-config.yaml has the device name as enp1s0, but the correct device name is now enp3s0. Luckily, I know how to fix, but its quite impactful.

IMHO, the issue is the installer's eth device path, which clearly changes later on in the lifecycle of the VM but netplan doesn't recognise nor modify it's config.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in subiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
LarryT (zapart) wrote :

Hi.
Ubu 20.04.3 - Virtual machin - vSphere - dhcp v4
I my case, the eth card detection is okay (ens32)
So no need to change eth name

Solution similar after each reboot :
sudo dhclient -r ens32 && sudo dhclient ens32

Revision history for this message
psl (slansky) wrote :

I have new, interesting case.

Ryzen motherboard with empty NVME slot. I installed Ubuntu to SATA drive, it worked for several days. I added NVME SSD disk to M.2 NVME slot on motherboard, disk is empty. After reboot, network interface was not configured. Reason? Once NVME disk was added, eth interface was renumbered from enp4s0 to enp5s0 and DHCP client was not started for enp5s0. I modified /etc/netplan/00-installer-config.yaml file, I replaced enp4s0 with enp5s0...

$ lspci | grep -i nvme
01:00.0 Non-Volatile memory controller: Sandisk Corp WD Blue SN500 / PC SN520 NVMe SSD (rev 01)
$ lspci | grep -i eth
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.