You have been subscribed to a public bug:

Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been
(re?)introduced that is breaking dhcp booting in the initrd environment.
This is stopping instances that use iscsi storage from being able to
connect.

Over serial console it outputs:

IP-Config: no response after 2 secs - giving up
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up

with increasing delays until it fails.  At which point a simple ipconfig
-t dhcp -d "ens2f0"  works.  The console output is slightly garbled but
should give you an idea:

(initramfs) ipconfig -t dhcp -[  728.379793] ixgbe 0000:13:00.0 ens2f0: 
changing MTU from 1500 to 9000
d "ens2f0"
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
IP-Config: ens2f0 guessed broadcast address 10.0.1.255
IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
 addres[  728.980448] ixgbe 0000:13:00.0 ens2f0: detected SFP+: 3
s: 10.0.1.56        broadcast: 10.0.1.255       netmask: 255.255.255.0
 gateway: 10.0.1.1   [  729.148410] ixgbe 0000:13:00.0 ens2f0: NIC Link is Up 
10 Gbps, Flow Control: RX/TX
      dns0     : 169.254.169.254  dns1   : 0.0.0.0
 rootserver: 169.254.169.254 rootpath:
 filename  : /ipxe.efi

tcpdumps show that dhcp requests are being received from the host, and
responses sent, but not accepted by the host.  When the ipconfig command
is issued manually, an identical dhcp request and response happens, only
this time it is accepted.  It doesn't appear to be that the messages are
being sent and received incorrectly, just silently ignored by ipconfig.

I was seeing this behaviour earlier this year, which I was able to fix
by specifying "ip=dhcp" as a kernel parameter.  About a month ago that
was identified as causing us other problems (long story) and we dropped
it, at which point we discovered the original bug was no longer an
issue.

Putting "ip=dhcp" back on with this kernel no longer fixes the problem.

I've compared the two initrds and effectively the only thing that has
changed between the two is the kernel components.

Ubuntu kernel bisect offending commit:
# first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per 
mount namespace limit on the number of mounts

Ubuntu kernel bisect offending commit submission:
https://lkml.org/lkml/2016/10/5/308

** Affects: klibc (Ubuntu)
     Importance: High
     Assignee: Jay Vosburgh (jvosburgh)
         Status: Confirmed

** Affects: klibc (Ubuntu Xenial)
     Importance: High
         Status: Triaged


** Tags: downstream-bisect-done kernel-bug-exists-upstream 
kernel-bug-exists-upstream-4.10-rc1 needs-upstream-bisect regression-update 
xenial
-- 
initrd dhcp fails / ignores valid response
https://bugs.launchpad.net/bugs/1652348
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to klibc in Ubuntu.

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to