[Kernel-packages] [Bug 1652348] [NEW] initrd dhcp fails / ignores valid response
Michael F Winthrop
mwinthrop at comcast.net
Tue Jun 6 20:22:37 UTC 2017
Paul,
[Kernel-packages] [Bug 1652348] [NEW] initrd dhcp fails / ignores
valid response
<https://www.mail-archive.com/search?l=kernel-packages@lists.launchpad.net&q=subject:%22%5C%5BKernel%5C-packages%5C%5D+%5C%5BBug+1652348%5C%5D+%5C%5BNEW%5C%5D+initrd+dhcp+fails+%5C%2F+ignores%09valid+response%22&o=newest>
https://www.mail-archive.com/kernel-
packages at lists.launchpad.net/msg211650.html
I also have this bug
IP-Config: no response after 2 secs - giving up
IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
etc., etc., etc. ...
and tracked it to:
c
I set the countdown to "2 3 4 6 9" and saw the count of failures match
appropriately.
I note that there are no problems if I attach an Ethernet cable from my
router to the PC. A probable solution is to use wlan (to get a
connectible device) or to test and see if the eth actually has a
connected cable. Perhaps both.
Text requiring attention from /usr/share/initramfs-
tools/scripts/functions
# support ip options see linux sources
# Documentation/filesystems/nfs/nfsroot.txt
# Documentation/frv/booting.txt
#for ROUNDTTT in 2 3 4 6 9 16 25 36 64 100; do
for ROUNDTTT in 2 3 4 6 9; do
# The NIC is to be configured if this file does not exist.
# Ip-Config tries to create this file and when it succeds
# creating the file, ipconfig is not run again.
for x in /run/net-"${DEVICE}".conf /run/net-*.conf ; do
if [ -e "$x" ]; then
IP=done
break
fi
done
for x in /run/net6-"${DEVICE}".conf /run/net6-*.conf ; do
if [ -e "$x" ]; then
IP6=done
break
fi
done
# if we've reached a point where both IP and IP6 are
"done",
# then we're finished with network configuration.
if [ "$IP" = done ] && [ "$IP6" = done ]; then
break
fi
case ${IP} in
none|done|off)
# Do nothing
IP=done
;;
""|on|any)
# Bring up device
ipconfig -t ${ROUNDTTT} "${DEVICE}"
;;
dhcp|bootp|rarp|both)
ipconfig -t ${ROUNDTTT} -c ${IP} -d "${DEVICE}"
;;
*)
ipconfig -t ${ROUNDTTT} -d $IP
# grab device entry from ip option
NEW_DEVICE=${IP#*:*:*:*:*:*}
if [ "${NEW_DEVICE}" != "${IP}" ]; then
NEW_DEVICE=${NEW_DEVICE%%:*}
else
# wrong parse, possibly only a partial
string
NEW_DEVICE=
fi
if [ -n "${NEW_DEVICE}" ]; then
DEVICE="${NEW_DEVICE}"
fi
;;
esac
case ${IP6} in
""|none|done|off)
# Do nothing
IP6=done
;;
*)
# if this is not the first loop, sleep to
provide the backoff.
[ "$(($ROUNDTTT-2))" = "0" ] || sleep $ROUNDTTT
# check the content of IP6, if we have
something other
# than a device name there and BOOTIF isn't
set, clear
# DEVICE6 and we'll try all available devices.
if echo "${IP6}" | grep -qv
'^\(on\|dhcp\|any\)$'; then
DEVICE6="$IP6"
fi
# if we don't have a device specified, try to
bring up
# any eligible device.
if [ -z "${DEVICE6}" ]; then
DEVICE6=$(all_netbootable_devices)
fi
# Bring up device
for dev in ${DEVICE6} ; do
dhclient -6 -1 -v "${dev}"
done
;;
esac
done
--
Cordially Yours,
/*Michael F Winthrop*/
Member: Sterling Lions Club, VA
Member: EAA Chapter 186, Manassas Apt. KHEF
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1652348
Title:
initrd dhcp fails / ignores valid response
Status in klibc package in Ubuntu:
Fix Released
Status in klibc source package in Xenial:
Fix Released
Status in klibc source package in Yakkety:
Fix Committed
Bug description:
[SRU justification]
Changes to ordering of kernel enumeration of network interfaces, which may happen in any release, can regress network configuration from an initramfs. Support for netbooting should not depend on interface order, it should work reliably on all systems.
[Test case]
Detailed reproducer described in
<https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/comments/35>.
[Regression potential]
Moderate regression potential, because of a relatively large patch touching a not-widely-used but still critical piece of code. Regression testing should include verifying that MAAS-booted cloud images still work as expected in a variety of environments.
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+subscriptions
More information about the foundations-bugs
mailing list