Snappy waits 2 minutes while booting if eth0 is not connected

[Simon Eisenmann]

Ubuntu core 5 ships /etc/network/interfaces.d/eth0 with "auto eth0". This leads to a 2 minutes boot delay because of /lib/systemd/system/ifup-wait-all-auto.service if the network is not connected during boot.

"auto eth0" should be removed from /etc/network/interfaces.d/eth0 and let the hotplug code handle the rest.

[Simon Eisenmann (longsleep)]

As per request on IRC this happens with my armhf image for ODROID-C.

Image was built with

sudo ubuntu-device-flash core \
 --channel stable \
 --oem odroidc_0.3_all.snap \
 --device-part device-odroidc_0.5.tar.xz \
 --developer-mode \
 -o odroidc-15.04-stable.img \
 15.04

Resulting in
(ODROIDC)ubuntu@odroid:~$ snappy list
Name Date Version Developer
ubuntu-core 2015-09-17 5 ubuntu
odroidc 2015-09-19 0.3 sideload

If you want to reproduce you find all the gear and information on https://github.com/longsleep/snappy-odroidc or can download the image, oem snap or device tarball from https://www.stdin.xyz/downloads/snappy/odroidc/20150919/

[John Lenton (chipaca)]

To reproduce with kvm, using the bog standard 15.04.5:

kvm -net none -device pcnet -snapshot -m 2048 15.04.5.img

you can then hit ctrl-alt-3 to watch the serial console for the fun.

Note also it doesn't happen with 15.04.4.

[Mark Shuttleworth (sabdfl)]

If there is no networking information provided to snappy on boot (think
cloud-init or another mechanism) then we should look at the physical
interfaces to see which have link, and only try to DHCP on those.

Mark

[Oliver Grawert (ogra)]

isnt that what the "allow-hotplug eth0" line usually does ?

"auto eth0" should only be used for static interfaces (if at all) i think and allow-hotplug for everything else instead (afaik the kernel will only emit the hotplug uevent if there is a link)

[Mark Shuttleworth (sabdfl)]

On 23/09/15 11:35, Oliver Grawert wrote:
> isnt that what the "allow-hotplug eth0" line usually does ?
>
> "auto eth0" should only be used for static interfaces (if at all) i
> think and allow-hotplug for everything else instead (afaik the kernel
> will only emit the hotplug uevent if there is a link)

If there's a mechanism that does what we need, perfect :) But let's
generate the ENI based on the hardware we actually see, not guess that
there's an eth0.

Mark

[Simon Eisenmann (longsleep)]

Yes the "allow-hotplug eth0" line should be sufficient. Note that if eth0 is not there then it also does not wait. It only waits if there is eth0 but not connected.

[Michael Vogt (mvo)]

@Mark: the name of the network hardware is looked up as part of the firstboot job, we do not hardcode "eth0" anymore.

As for the content of the file:
"""
allow-hotplug eth0
iface eth0 inet dhcp
"""

but now its:
"""
auto eth0

allow-hotplug eth0
iface eth0 inet dhcp
"""
This will need fixing.

[Michael Vogt (mvo)]

We should also consider how we transition existing systems that are affected by the bug.

[Mark Shuttleworth (sabdfl)]

You guys rock. Thank you!

[Simon Eisenmann (longsleep)]

I just tested a fresh image with ubuntu-core 6 and it no longer blocks on boot when eth0 is not connected. Though it still constantly tries DHCP on eth0 even if it is not connected.

Like Mark mentioned, DHCP should only be tried if there is a physical link.

[Simon Eisenmann (longsleep)]

After discussion on IRC i added the DHCP issue separate: https://bugs.launchpad.net/snappy/+bug/1503680