Long network timeout on booting subiquity test ISO

[David Britton]

Similar to: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1716500, I get a long boot timeout on a VM on first boot (no networking has or should have been brought up, subiquity does that only after a couple of steps).

Again in this case, systemd-networkd-wait-online.service is on the top of systemd-analyze blame with ~2m until it times out.

I'm capturing this in case this is a subtly different bug that should be explored.

Here is relevant debugging interaction, please ask for more if needed, I can repeat this every time the VM boots.

------------------------------

ubuntu-server@ubuntu-server:~$ snap list subiquity
Name Version Rev Developer Notes
subiquity 0.0.38 7 canonical classic

ubuntu-server@ubuntu-server:~$ dpkg -l |grep nplan
ii nplan 0.26 amd64 YAML network configuration abstraction for various backends

ubuntu-server@ubuntu-server:~⟫ ll /etc/networkd
ls: cannot access '/etc/networkd': No such file or directory
2 ubuntu-server@ubuntu-server:~⟫ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<host>
        loop txqueuelen 1000 (Local Loopback)
        RX packets 976 bytes 60864 (60.8 KB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 976 bytes 60864 (60.8 KB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ubuntu-server@ubuntu-server:~⟫ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ee:14:92 brd ff:ff:ff:ff:ff:ff

ubuntu-server@ubuntu-server:~⟫ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:54:00:ee:14:92 brd ff:ff:ff:ff:ff:ff

ubuntu-server@ubuntu-server:~⟫ journalctl -u systemd-networkd-wait-online.service
-- Logs begin at Thu 2017-09-14 03:25:34 UTC, end at Thu 2017-09-14 03:27:42 UTC. --
Sep 14 03:25:35 ubuntu-server systemd[1]: Starting Wait for Network to be Configured...
Sep 14 03:25:35 ubuntu-server systemd-networkd-wait-online[973]: ignoring: lo
Sep 14 03:25:35 ubuntu-server systemd-networkd-wait-online[973]: ignoring: lo
Sep 14 03:27:35 ubuntu-server systemd-networkd-wait-online[973]: Event loop failed: Connection timed out
Sep 14 03:27:35 ubuntu-server systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILU
Sep 14 03:27:35 ubuntu-server systemd[1]: Failed to start Wait for Network to be Configured.
Sep 14 03:27:35 ubuntu-server systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state.
Sep 14 03:27:35 ubuntu-server systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
ubuntu-server@ubuntu-server:~⟫

ubuntu-server@ubuntu-server:~⟫ systemd-analyze blame | head -5
      2min 227ms systemd-networkd-wait-online.service
          3.532s lxd-containers.service
          2.513s dev-sr0.device
          2.511s dev-loop0.device
          1.298s accounts-daemon.service
ubuntu-server@ubuntu-server:~⟫

[Michael Hudson-Doyle (mwhudson)]

I think xnox has a plan for this (although the DHCP-by-default thing will also fix it in most situations)

[Steve Langasek (vorlon)]

This is related to / blocked by bug #1664844.

[Launchpad Janitor (janitor)]

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

[Dimitri John Ledkov (xnox)]

nplan has optional:true support

livecd-rootfs change to use optional:true landed

once that migrates, and new images spin up, I expect no delays getting to the installer welcome screen on systems:

- without any NICs
- with NICs but that are not connected to networks
- with NICs connected to network, but no DHCP there
- with NICs connected to a very slow DHCP
- with NICs connected to fast DHCP servers

However I cannot commit to testing all of the above scenarios =)

I'll update the bug, once livecd-rootfs migrates and a new image is spun up.