No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option

[Scott Emmons]

[Impact]
 * initramfs-tools SRUs introduced regressions in ip= syntax, which cause unexpected behavior

[Test Case]
 * Create a machine that boots using an nfsroot.
 * Use ip=:::::eth0:dhcp on the kernel command line. To set up
   networking.
 * Discover that the device never comes up because, networking is not configured correctly.

[Regression Potential]
Should be back to original behavior before ipv6 support was introduced in the past 2 or 3 SRUs.

[Other Info]

 * There are a number of other issues in this code base that are not solved by this fix.
   - The ?*:?*:?*:?*: use case falls through to the default case, and likely breaks there. As such static assignment via ip= appears broken
   -
 * The networking configuration does not strictly follow the kernel documentation as described https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This should be fixed.

This bug is a regression of changes made under bug 1628306.

====================Original Bug Description Follows==================

initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments.

Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured.

The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set.

AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it.

[Scott Emmons (lscotte)]

This was on xenial, unknown if other versions are affected.

Related:

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631436
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507

[Scott Emmons (lscotte)]

Here's the initial portion of console output, with only a couple of minor redactions related to keys, hostname, MAC address.

The most important bit is:

ip: SIOCGIFFLAGS: No such device
Error getting hardware address for "dhcp": No such device

Where the "ip=dhcp" kernel is not being processed correctly per kernel documentation - see https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt

=== CUT HERE===
[ 2.179049] registered taskstats version 1
[ 2.179074] Loading compiled-in X.509 certificates
[ 2.179821] Loaded X.509 cert 'Build time autogenerated kernel key: REDACTED'
[ 2.179848] zswap: loaded using pool lzo/zbud
[ 2.190763] Key type trusted registered
[ 2.195735] Key type encrypted registered
[ 2.195747] AppArmor: AppArmor sha1 policy hashing enabled
[ 2.195753] ima: No TPM chip found, activating TPM-bypass!
[ 2.195778] evm: HMAC attrs: 0x1
[ 2.213710] blkfront: xvda1: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2.218079] blkfront: xvdb: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2.292145] Magic number: 1:252:3141
[ 2.292190] hctosys: unable to open rtc device (rtc0)
[ 2.292239] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 2.292244] EDD information not available.
[ 2.292964] Freeing unused kernel memory: 1480K (ffffffff81f41000 - ffffffff820b3000)
[ 2.292973] Write protecting the kernel read-only data: 14336k
[ 2.296529] Freeing unused kernel memory: 1868K (ffff88000182d000 - ffff880001a00000)
[ 2.296620] Freeing unused kernel memory: 176K (ffff880001dd4000 - ffff880001e00000)
Loading, please wait...
starting version 229
[ 2.337933] random: udevadm urandom read with 7 bits of entropy available
[ 2.595423] SSE version of gcm_enc/dec engaged.
Begin: Loading essential drivers ...
[ 3.942253] md: linear personality registered for level -1
[ 3.954483] md: multipath personality registered for level -4
[ 3.957749] md: raid0 personality registered for level 0
[ 3.975096] md: raid1 personality registered for level 1
[ 4.059760] raid6: sse2x1 gen() 3697 MB/s
[ 4.124589] raid6: sse2x1 xor() 3003 MB/s
[ 4.192058] raid6: sse2x2 gen() 4609 MB/s
[ 4.260062] raid6: sse2x2 xor() 3242 MB/s
[ 4.335089] raid6: sse2x4 gen() 5511 MB/s
[ 4.400055] raid6: sse2x4 xor() 3912 MB/s
[ 4.400061] raid6: using algorithm sse2x4 gen() 5511 MB/s
[ 4.400064] raid6: .... xor() 3912 MB/s, rmw enabled
[ 4.400068] raid6: using ssse3x2 recovery algorithm
[ 4.407087] xor: measuring software checksum speed
[ 4.468056] prefetch64-sse: 8536.000 MB/sec
[ 4.524066] generic_sse: 8099.000 MB/sec
[ 4.524076] xor: using function: prefetch64-sse (8536.000 MB/sec)
[ 4.527357] async_tx: api initialized (async)
[ 4.548551] md: raid6 personality registered for level 6
[ 4.548560] md: raid5 personality registered for level 5
[ 4.548564] md: raid4 personality registered for level 4
[ 4.595063] md: raid10 personality registered for level 10
done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ...

[Dave Chiluk (chiluk)]

Dediff from 8.2 to 8.3.
http://launchpadlibrarian.net/286956415/initramfs-tools_0.122ubuntu8.2_0.122ubuntu8.3.diff.gz

[Jason Gerard DeRose (jderose)]

As asked by chiluk on IRC, here's my PXE boot configuration (well, representative one anyway, the exact kernel version will obviously change):

DEFAULT ubuntu
LABEL ubuntu
LINUX vmlinuz-4.4.0-36-generic
APPEND initrd=initrd.img-4.4.0-36-generic root=/dev/nfs nfsroot=10.17.76.1:/var/lib/tribble/ephemeral ip=dhcp ro nomodeset net.ifnames=0
IPAPPEND 2

[Dave Chiluk (chiluk)]

I created a PPA with a proposed solution to this issue. If I could get some testing with this ppa I would appreciate it. Additionally if you test the ppa please report back and include your /proc/cmdline in your comment.

Thank you,
Dave Chiluk

[Dave Chiluk (chiluk)]

Woops I forgot to include the PPA
https://launchpad.net/~chiluk/+archive/ubuntu/lp1631474

I will remove this ppa when the package hits -proposed.

[Scott Emmons (lscotte)]

I tested with the PPA and it looks good in an initial test. Before, upgrading initramfs-tools and rebooting would result in AWS instance being unreachable. Now, it looks good!

$ cat /proc/cmdline
root=LABEL=cloudimg-rootfs ro console=hvc0 ip=dhcp tsc=reliable

$ dpkg -l|grep initramfs-tools
ii initramfs-tools 0.122ubuntu8.3+lp1631474 all generic modular initramfs generator (automation)
ii initramfs-tools-bin 0.122ubuntu8.3+lp1631474 amd64 binaries used by initramfs-tools
ii initramfs-tools-core 0.122ubuntu8.3+lp1631474 all generic modular initramfs generator (core tools)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "lp1631474.xenial.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Dave Chiluk (chiluk)]

I fixed up the comment, and the changelog comment and resubmit the debdiff.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jason Gerard DeRose (jderose)]

@chiluk - the package in your PPA fixes it from my use case, thanks!

[gregory (butron)]

I also have had four computers in the last 2 days show this bug.

I reinstalled the OS in those cases, if I find the bug again, I'll test the PPA.

Thanks for finding a fix!

[gregory (butron)]

My computers were not in AWS, they were desktops that I had physical access to running ubuntu 16.04

[Dave Chiluk (chiluk)]

Updated debdiff to handle ip=:::::bootif use case.

[Dave Chiluk (chiluk)]

I have uploaded a new version of initramfs-tools to my ppa, I would again appreciate testing on this. Notably I fixed an bug that was causing all_netbootable_devices to be tried instead of the interface specified on the command line.

I also now handle the case where ip=:::::bootif , which really shouldn't be a concern to most.

I still think ip=bootif might fail *(if /run/net-${DEVICE}.conf does not exist), but as this is an anaconda use case and not a mainline kernel use case I'll ignore it for the purpose of the SRU.

[Dave Chiluk (chiluk)]

I tested maas's command line as well.

/proc/cmdline from a maas pxe boot is
BOOT_IMAGE=ubuntu/amd64/hwe-y/yakkety/daily/boot-kernel nomodeset iscsi_target_name=iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily iscsi_target_ip=192.168.1.5 iscsi_target_port=3260 iscsi_initiator=bonusvm2 ip=::::bonusvm2:BOOTIF ro root=/dev/disk/by-path/ip-192.168.1.5:3260-iscsi-iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily-lun-1 overlayroot=tmpfs cloud-config-url=http://192.168.1.5/MAAS/metadata/latest/by-id/4y3h7t/?op=get_preseed log_host=192.168.1.5 log_port=514 initrd=ubuntu/amd64/hwe-y/yakkety/daily/boot-initrd BOOTIF=01-52-54-00-ca-c0-9e

Notable variables are
ip=::::bonusvm2:BOOTIF BOOTIF=01-52-54-00-ca-c0-9e

This use case continues to function.

[Scott Emmons (lscotte)]

The latest PPA (0.122ubuntu8.3+lp1631474b2) passes verification for me.

$ cat /proc/cmdline
root=LABEL=cloudimg-rootfs ro console=hvc0 ip=dhcp tsc=reliable

$ dpkg -l|grep initramfs-tools
ii initramfs-tools 0.122ubuntu8.3+lp1631474b2 all generic modular initramfs generator (automation)
ii initramfs-tools-bin 0.122ubuntu8.3+lp1631474b2 amd64 binaries used by initramfs-tools
ii initramfs-tools-core 0.122ubuntu8.3+lp1631474b2 all generic modular initramfs generator (core tools)

[Jason Gerard DeRose (jderose)]

@chiluk - I tested the latest package in your PPA, but something seems slightly wonky for my use case.

Networking seems to come up correctly, but it takes longer than it should and I see warnings like this repeated several times:

ip: ether "dev" is duplicate, or "permanent" is garbage

[Jason Gerard DeRose (jderose)]

Attaching a tarbal of everything i have in /var/log, not sure it's useful (not my "ephemeral" environment is read-only with /var/log on a tmpfs, so it's mostly empty).

Also here's my exact /proc/cmdline from within the booted ephemeral environment:

BOOT_IMAGE=vmlinuz-4.4.0-42-generic initrd=initrd.img-4.4.0-42-generic root=/dev/nfs nfsroot=10.17.76.1:/var/lib/tribble/ephemeral ip=dhcp ro nomodeset net.ifnames=0 BOOTIF=01-80-fa-5b-36-f5-86

[Martin Pitt (pitti)]

Hello scotte, or anyone else affected,

Accepted initramfs-tools into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.122ubuntu8.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Martin Pitt (pitti)]

Note: I accepted this into -proposed as 'ip: ether "dev" is duplicate, or "permanent" is garbage' seems to be an unrelated bug. Of course feel free to fix that one as well with a subsequent upload, but this still appears to be an incremental fix as-is.

[Martin Pitt (pitti)]

Hello scotte, or anyone else affected,

Accepted initramfs-tools into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.125ubuntu6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Scott Moser (smoser)]

Hi,
I think the right way to fix this regression would have been to revert the change.
The change made in bug 1628306 made fairly wide spread changes. It caused this regression as seen, but also added behavioral changes.

Previously, 'ip=dhcp' would do a ipv4 dhcp request (via ipconfig).
The change was:
a.) to make it use dhclient
b.) to *also* do a dhcpv6 request in all cases.

[Jason Gerard DeRose (jderose)]

@martin - I tested the proposed package, and it's workable, but there are behavior changes still compared to prior to when this regression was introduced (in particular, the boot is a lot slower when there are mulitple NICs but only one will be configured, even when I use "ip=:::::eth0:dhcp").

@scott - I think I agree with you. Considering this is an SRU for the LTS, I'd prefer that as little behavior change be introduced as possible.

[Jason Gerard DeRose (jderose)]

Oh, and to be clear, I have no problem with this change in Yakkety. It's just starting to feel a bit too invasive in my opinion for Xenial.

[LaMont Jones (lamont)]

0.122ubuntu8.4 still fails to get an IP when the switchport is not 'portfast' (and the switch therefore passes no traffic for 60 seconds after link-up.)

[Scott Emmons (lscotte)]

smoser - I think you make a really good point. A regression in an LTS distribution that results in a working configuration to no longer work is fairly serious - as is introducing behavioral changes in an LTS. While I'm generally in favor of fix-forward, it's not always the right approach. I acknowledge changes are hard, and there's not always a clear or right answer, especially given the vast diversity in exactly what people do with their systems and how they configure them. This is a larger discussion around change management, and my opinions here are a bit off-topic as it relates specifically to this bug, so...

I retested with xenial-proposed and the system rebooted fine for me.

initramfs-tools:
  Installed: 0.122ubuntu8.4
  Candidate: 0.122ubuntu8.4
  Version table:
 *** 0.122ubuntu8.4 500
        500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages

ii initramfs-tools 0.122ubuntu8.4 all generic modular initramfs generator (automation)
ii initramfs-tools-bin 0.122ubuntu8.4 amd64 binaries used by initramfs-tools
ii initramfs-tools-core 0.122ubuntu8.4 all generic modular initramfs generator (core tools)

[Mathieu Trudel-Lapierre (cyphermox)]

Seems to me like we're at the point where considering a straight revert of the SRU would be in order (and I'm certainly considering it for the short term), in order to move forward again at a later time when this is more solid -- not that the end goal is still going to be happening (though maybe not in 16.04), that is to gradually remove klibc from the initramfs. That *will* require changes, such as we see here. If you never fail, it's because you're not innovating...

The changes here were motivated by providing IPv6 support for MaaS deployments in v6-only and mixed networks.

From my understanding of things, we've now fixed (in 0.122ubuntu8.4) the issues with ip=dhcp and some other ip= forms being parsed incorrectly.

There are still two outstanding issues:
 - boot speed (I suspect there is only a limited amount of things we can do about this, given the use of dhclient).
 - "portfast behavior", which is how we handle delays in getting a response from a DHCP server. There was definitely a regression there, for which I have a fix in my ppa at ppa:cyphermox/maas.

Are there any other outstanding issues? If so, what kernel command-line are you using, and please include the exact messages on screen (or in logs) so we can know what we're dealing with.

[Steve Langasek (vorlon)]

Hello scotte, or anyone else affected,

Accepted initramfs-tools into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.122ubuntu8.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Jason Gerard DeRose (jderose)]

Okay, tested 0.122ubuntu8.5 from xenial-proposed, and it fixes the issue for my use-case.

But I'm not changing verification-needed to verification-done yet as I don't know if it fixes the use case of the original reporter.

@scotte - can you please confirm whether this fixes things for you?

[LaMont Jones (lamont)]

I have confirmed that this functions as expected for MAAS (behaves exactly like 0.122ubuntu8.1 did.) Not marking verification-done, but +1 from me/MAAS.

[LaMont Jones (lamont)]

After more discussion, marking this verification-done.

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.122ubuntu8.5

---------------
initramfs-tools (0.122ubuntu8.5) xenial; urgency=medium

  * scripts/functions: Revert configure_networking changes to the state at
    0.122ubuntu8.1. (LP: #1631474)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 13 Oct 2016 17:19:56 -0400

[Steve Langasek (vorlon)]

The verification of the Stable Release Update for initramfs-tools has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.125ubuntu6

---------------
initramfs-tools (0.125ubuntu6) yakkety; urgency=medium

  * Fix case where ip=dhcp and ip=:::::eth0 and other ip= instances exists on
    the kernel command line (LP: #1631474)
  * Also fixed an error discovered by the shellcheck static code analyzer
    where "$DEVICES" would be processed as a single device where-as removing
    the quotes allows the list to be correctly processed by the for loop.

 -- Dave Chiluk <email address hidden> Fri, 07 Oct 2016 16:21:50 -0500

[Martin Pitt (pitti)]

Hello scotte, or anyone else affected,

Accepted initramfs-tools into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.125ubuntu6.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Mathieu Trudel-Lapierre (cyphermox)]

scotte, Jason, could either of you verify that the revert returned initramfs-tools in a state that works for you?

[Scott Emmons (lscotte)]

It's been resolved for us in xenial for quite awhile...

[Jason Gerard DeRose (jderose)]

Mathieu,

I tested your PPA package with Xenial: with no config changes on my end, it's working as expected from my use case.

Thanks!

[Mathieu Trudel-Lapierre (cyphermox)]

Verification completed on yakkety as well; the revert is working as expected.

[Martin Pitt (pitti)]

For the record, releasing this is blocked by getting the fix into zesty. Devel series first!

[Robie Basak (racb)]

This is confusing. Yakkety has never (to date) had an SRU land. So the proposed revert to Yakkety isn't actually a revert from Yakkety's perspective. Doing so would mean a behavioural change to Yakkety users, no?

[Chris Halse Rogers (raof)]

Hello scotte, or anyone else affected,

Accepted initramfs-tools into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.125ubuntu6.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello scotte, or anyone else affected,

Accepted initramfs-tools into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.125ubuntu6.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.125ubuntu6.3

---------------
initramfs-tools (0.125ubuntu6.3) yakkety; urgency=medium

  * Do not rely on debug variables from dhclient.

initramfs-tools (0.125ubuntu6.2) yakkety; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * scripts/functions: for configure_networking:
    - split out IPv6 options in its own cmdline parameter: ip6= ; always use
      dhclient in this case if the value set is anything other than 'off' or
      'none'. Furthermore, parse anything other than 'on', 'dhcp' or 'any' as
      the name of an interface. (LP: #1621507)
    - rework the stop conditions so that we properly handle the ROUNDTTT loop,
      timing out after a short period of time and trying again after a short
      sleep.
    - add a 'done' parameter for both ip= and ip6= so that we can properly
      exit the ROUNDTTT loop once we know that either there is no work to do,
      or that we've achieved what we wanted (that is, to bring up IPv4, IPv6,
      or possibly both).
    - return ip=dhcp to the ipconfig use case; if set, then ipconfig will be
      run using any interface available, or the BOOTIF if it was set.

  [ LaMont Jones ]
  * Only source ipv4 config in configure_networking() if it exists.

initramfs-tools (0.125ubuntu6.1) yakkety; urgency=medium

  * scripts/functions: Revert configure_networking changes to the state at
    0.125ubuntu3. (LP: #1631474)

initramfs-tools (0.125ubuntu6) yakkety; urgency=medium

  * Fix case where ip=dhcp and ip=:::::eth0 and other ip= instances exists on
    the kernel command line (LP: #1631474)
  * Also fixed an error discovered by the shellcheck static code analyzer
    where "$DEVICES" would be processed as a single device where-as removing
    the quotes allows the list to be correctly processed by the for loop.

 -- LaMont Jones <email address hidden> Wed, 30 Nov 2016 08:30:14 -0700

[Mathieu Trudel-Lapierre (cyphermox)]

AFAIK everything landed for this already in zesty (and thus in artful as well). Not sure why it is still "In Progress".

I'm setting this to Fix Released; if there are any other issues anyway, they should get their own bug so we can better track any possible SRUs.

[wendal (wendal)]

are there any update for ubuntu 14.04 ?

[Robie Basak (racb)]

On Thu, May 18, 2017 at 10:07:21AM -0000, wendal wrote:
> are there any update for ubuntu 14.04 ?

This bug is a regression of changes made under bug 1628306. Bug 1628306
never updated 14.04, so this bug doesn't affect (and never affected)
14.04. If you have a problem with the behaviour of ip=dhcp in 14.04,
please file a separate and full bug report.