Wait for interface link ready before starting udhcpc

Bug #1768955 reported by Ihar Hrachyshka on 2018-05-03
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

(This is somewhat related to https://bugs.launchpad.net/cirros/+bug/1273159 though I think it's a separate bug, even if its exacerbated by the bug I linked to.)

The issue that when cirros boots, it ups the interface, then immediately starts udhcpc. In some environments, the interface may not establish link quick enough, and so DHCP requests sent by udhcpc are lost.

The slowdown of interface link bring up may have different sources (general slowliness of the kernel could be one), but in my particular scenario it takes 2 seconds for the kernel to bring up the link for eth0 when I use 'e1000' interface model type in libvirt definition for the machine that runs cirros image. If I switch to 'virtio' interface model type, it doesn't take that long to set up the link, and the first DHCP request reaches the DHCP server.

While one could argue that cirros should be executed with virtio and not e1000, it may not be the default (or even possible) in some scenarios. For example, kubevirt (VMs for kubernetes) doesn't currently allow to pick interface model type, using e1000 for all machines, which slows cirros boot by 1 minute.

I think the right thing to do here is:

0. Document e1000 behavior somewhere (not sure if the project has documentation; I for one couldn't find it).
1. Wait until the link is ready.
2. (To mitigate any other sources of frame drop) Become more aggressive in issuing DHCP request. (This is the exact topic for https://bugs.launchpad.net/cirros/+bug/1273159)

For the record, kubevirt issue that revealed the problem is: https://github.com/kubevirt/kubevirt/issues/936

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

Other bug subscribers

Remote bug watches

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