Paul Graydon, thank you for reporting this and helping make Ubuntu
better.
In order to allow additional upstream developers to examine the issue, at your
earliest convenience, could you please test the latest upstream kernel
available from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Please
keep in mind the following:
1) The one to test is at the very top line at the top of the page (not the
daily folder).
2) The release names are irrelevant.
3) The folder time stamps aren't indicative of when the kernel actually was
released upstream.
4) Install instructions are available at
https://wiki.ubuntu.com/Kernel/MainlineBuilds .
If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.
If the latest kernel did not allow you to test to the issue (ex. you couldn't
boot into the OS) please make a comment in your report about this, and continue
to test the next most recent kernel version until you can test to the issue.
Once you've tested the upstream kernel, please comment on which kernel version
specifically you tested. If this issue is fixed in the mainline kernel, please
add the following tags by clicking on the yellow circle with a black pencil
icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ
Where X, and Y are the first two numbers of the kernel version, and Z is
the release candidate number if it exists.
If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ
Please note, an error to install the kernel does not fit the criteria of
kernel-bug-exists-upstream.
Also, you don't need to apport-collect further unless specifically
requested to do so.
It is most helpful that after testing of the latest upstream kernel is
complete, you mark this report Status Confirmed.
Lastly, to keep this issue relevant to upstream, please continue to test
the latest mainline kernel as it becomes available.
Thank you for your help.
** Changed in: linux (Ubuntu)
Importance: Undecided => Low
** Changed in: linux (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1652348
Title:
initrd dhcp fails / ignores valid response
Status in linux package in Ubuntu:
Incomplete
Bug description:
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.
I'm going to try and track back through kernel versions to see if I
can find which version the fix happened in to maybe provide some
additional context. I'll also attach copies of the initrds, packet
captures etc.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652348/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
