Paul Graydon, thanks for the clarification.

Paraphrasing Linus, "We don't break userspace!" So, kernel bits being
flipped causing userspace issues would be considered, at least for now,
a kernel issue.

Despite this, the Ubuntu kernel commit bisect results are helpful here
on Launchpad.

However, in order keep this relevant to upstream, you would want to
bisect the mainline kernel as if doing a brand new bisect to see what
the results are there.

Once the mainline kernel commit bisect is done, then someone from
upstream would give their perspective on is this root caused to kernel,
user space, or both.

** Tags removed: bisect-done
** Tags added: downstream-bisect-done needs-upstream-bisect

** Description changed:

  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.
  
- Offending commit:
+ Ubuntu kernel bisect offending commit:
  # first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per 
mount namespace limit on the number of mounts
  
- The offending commit submission:
+ Ubuntu kernel bisect offending commit submission:
  https://lkml.org/lkml/2016/10/5/308

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1652348

Title:
  initrd dhcp fails / ignores valid response

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652348/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to