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

Bug #1631474 reported by Scott Emmons on 2016-10-07
62
This bug affects 8 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
High
Unassigned
Xenial
High
Unassigned
Yakkety
High
Dave Chiluk
Zesty
High
Unassigned

Bug Description

[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) wrote :
Download full text (15.5 KiB)

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) on 2016-10-07
tags: added: regression-update
Dave Chiluk (chiluk) on 2016-10-07
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Dave Chiluk (chiluk)
status: New → In Progress
Jason Gerard DeRose (jderose) wrote :

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) wrote :

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) wrote :

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) wrote :

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)

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.]

tags: added: patch
Dave Chiluk (chiluk) wrote :

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

Dave Chiluk (chiluk) on 2016-10-08
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in initramfs-tools (Ubuntu Xenial):
status: New → Confirmed
Jason Gerard DeRose (jderose) wrote :

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

Changed in initramfs-tools (Ubuntu Xenial):
importance: Undecided → High
Changed in initramfs-tools (Ubuntu):
importance: Undecided → High
gregory (butron) wrote :

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) wrote :

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

Dave Chiluk (chiluk) wrote :

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

Dave Chiluk (chiluk) wrote :
Dave Chiluk (chiluk) wrote :

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) on 2016-10-12
description: updated
Dave Chiluk (chiluk) wrote :

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) wrote :

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)

Dave Chiluk (chiluk) on 2016-10-12
description: updated
Jason Gerard DeRose (jderose) wrote :

@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) wrote :

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

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!

Changed in initramfs-tools (Ubuntu Xenial):
status: Confirmed → Fix Committed
tags: added: verification-needed
Martin Pitt (pitti) wrote :

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.

Changed in initramfs-tools (Ubuntu Yakkety):
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

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) wrote :

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.

description: updated
Jason Gerard DeRose (jderose) wrote :

@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) wrote :

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) wrote :

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) wrote :

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)

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) wrote :

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) wrote :

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) wrote :

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) wrote :

After more discussion, marking this verification-done.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

Changed in initramfs-tools (Ubuntu Xenial):
status: Fix Committed → Fix Released

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) wrote :

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

Changed in initramfs-tools (Ubuntu Yakkety):
status: Fix Committed → Fix Released
description: updated
Changed in initramfs-tools (Ubuntu Xenial):
status: Fix Released → In Progress
Changed in initramfs-tools (Ubuntu Yakkety):
status: Fix Released → In Progress
Changed in initramfs-tools (Ubuntu Xenial):
status: In Progress → Fix Released
Changed in initramfs-tools (Ubuntu Zesty):
status: Fix Committed → In Progress

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!

Changed in initramfs-tools (Ubuntu Yakkety):
status: In Progress → Fix Committed
tags: removed: verification-done
tags: added: verification-needed

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

Scott Emmons (lscotte) wrote :

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

Jason Gerard DeRose (jderose) wrote :

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!

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

tags: added: verification-done
removed: verification-needed
Martin Pitt (pitti) wrote :

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

Robie Basak (racb) wrote :

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) wrote :

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!

tags: removed: verification-done
tags: added: verification-needed
Brian Murray (brian-murray) wrote :

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!

LaMont Jones (lamont) on 2016-12-19
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

Changed in initramfs-tools (Ubuntu Yakkety):
status: Fix Committed → Fix Released

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.

Changed in initramfs-tools (Ubuntu):
status: In Progress → Fix Released
assignee: Dave Chiluk (chiluk) → nobody
Changed in initramfs-tools (Ubuntu Zesty):
status: In Progress → Fix Released
wendal (wendal) wrote :

are there any update for ubuntu 14.04 ?

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments