initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Bug #1621507 reported by LaMont Jones on 2016-09-08
44
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MAAS
Critical
LaMont Jones
initramfs-tools (Ubuntu)
High
Mathieu Trudel-Lapierre
Xenial
High
Mathieu Trudel-Lapierre
Yakkety
High
Mathieu Trudel-Lapierre
isc-dhcp (Ubuntu)
High
Mathieu Trudel-Lapierre
Xenial
High
Mathieu Trudel-Lapierre
Yakkety
High
Mathieu Trudel-Lapierre
klibc (Debian)
Confirmed
Unknown
klibc (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned
Yakkety
Undecided
Unassigned
open-iscsi (Ubuntu)
High
Unassigned
Xenial
High
Unassigned
Yakkety
High
Unassigned

Bug Description

initramfs' configure_networking function uses ipconfig to configure the network.
ipconfig does not support dhcpv6. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164

Related bugs:
  * bug 1229458: grub2 needed changes
  * bug 1621615: network not configured when ipv6 netbooted into cloud-init
  * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)

Bugs related to uploads for this specific SRU:

cloud-init:
bug 1460715: different fix unrelated to this SRU
bug 1639930: ip6= on kernel command line
bug 1642679: different fix unrelated to this SRU
bug 1644043: different fix unrelated to this SRU

ifupdown:
bug 1629972: networking.service takes down lo on stop

initramfs-tools:
bug 1621507: no IPv6 DHCP support in early boot
bug 1628306: regression-update (failure when ip="")
bug 1631474: regression-update (failure when ip=:::::eth0:dhcp)

isc-dhcp:
bug 1621507: no IPv6 DHCP support in early boot
bug 1633479: dhclient does not wait for IPv6 DAD

open-iscsi:
bug 1621507: no IPv6 DHCP support in early boot

[Impact]

It is not possible to netboot Ubuntu with a network-based root filesystem in an ipv6-only environment. Anyone wanting to netboot in an ipv6-only environment is affected.

[Stable Fix]

These uploads add "ip6=" to the command line syntax to configure ipv6 using the defacto isc-dhcp-client. IPv4 configuration (and "ip=" syntax) remain unchanged.

Valid format for the ip6= command line option is:
   ip6=none (or ip6=off or ip6=) -- do not configure ipv6
   ip6=DEVICE -- run IPv6 dhclient on device DEVICE.

[Test Case]

See Bug 1229458. Configure radvd, dhcpd, and tftpd for your ipv6-only netbooting world. Pass the boot process an ipv6 address to talk to, and see it fail to configure the network.

[Regression Potential]

1) This increases the uncompressed initramfs size by approximately 500KB, since isc-dhcp-client is added, but klibc is still needed for some other things, and is therefore present. On systems with a very small /boot partition, this could result in failure to upgrade the initramfs.
2) In at least some cases, DHCP network configuration shifts from klibc's ipconfig to isc-dhcp-client's dhclient. This should be of minimal risk, as isc-dhcp-client is in very very widespread use. In the event of a regression, network boot would fail, but the prior kernel should still be bootable.

[Tests for verification]

Whoever checks the last one off, please mark verification done.

MAAS test cases:
 X / Y
[+]/[+] MAAS on IPv6-only network
[+]/[+] MAAS on IPv4-only network
[+]/[+] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
[+]/[+] MAAS booting IPv6 on dual-stack network (with and without dhcp4)

Non-MAAS test cases:
 X / Y
[+]/[+] ip="" and ip6 not present
[+]/[+] ip=:::::eth0:dhcp and ip6 not present
[+]/[+] d-i install with iSCSI remote root should complete normally
[+]/[+] Validate normal boot without remote root
[+]/[+] Booting an iSCSI remote root via IPv4 (using ip=)
[+]/[+] Booting an iSCSI remote root via IPv6 (using ip6=)
[+]/[+] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
[+]/[+] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of booting device)52-54-00-53-5d-24
[+]/[+] Booting an iSCSI remote root on mixed network with no options (IPv4 should be used only)

Related branches

Changed in maas:
status: New → Confirmed
importance: Undecided → Critical
tags: added: maas-ipv6
LaMont Jones (lamont) on 2016-09-08
tags: added: maas-ipv76
removed: maas-ipv6
tags: added: maas-ipv6
removed: maas-ipv76
summary: - ipconfig lacks ipv6 support
+ initramfs-tools configure_networking() fails to dhcp ipv6 addresses
Changed in klibc (Debian):
status: Unknown → New
Steve Langasek (vorlon) on 2016-09-08
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in initramfs-tools (Ubuntu):
status: New → Triaged
importance: Undecided → High

To include dhclient in the initramfs; we should have a task for isc-dhcp too.

Changed in isc-dhcp (Ubuntu):
status: New → In Progress
Changed in initramfs-tools (Ubuntu):
status: Triaged → In Progress
Changed in isc-dhcp (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
importance: Undecided → High
LaMont Jones (lamont) on 2016-09-20
Changed in open-iscsi (Ubuntu):
assignee: nobody → LaMont Jones (lamont)
Changed in iproute2 (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
LaMont Jones (lamont) wrote :

open-iscsi's part of this is fixed in open-iscsi_2.0.873+git0.3b4b4500-14ubuntu4

Changed in open-iscsi (Ubuntu):
status: New → Fix Committed
milestone: none → ubuntu-16.10
milestone: ubuntu-16.10 → none
Scott Moser (smoser) on 2016-09-21
description: updated
LaMont Jones (lamont) wrote :

iproute2 turns out to be not needed for this.

no longer affects: iproute2 (Ubuntu)
no longer affects: iproute2 (Ubuntu Xenial)

Hello LaMont, or anyone else affected,

Accepted isc-dhcp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu12.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!

Changed in isc-dhcp (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed
LaMont Jones (lamont) on 2016-09-24
description: updated
Steve Langasek (vorlon) wrote :

Hello LaMont, 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.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 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: New → Fix Committed
Changed in open-iscsi (Ubuntu Xenial):
status: New → Fix Committed
Steve Langasek (vorlon) wrote :

Hello LaMont, or anyone else affected,

Accepted open-iscsi into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-iscsi/2.0.873+git0.3b4b4500-14ubuntu3.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!

Steve Langasek (vorlon) wrote :

WRT regression potential:

 2) In at least some cases, DHCP network configuration shifts from klibc's ipconfig to isc-dhcp-client's dhclient. This should be of minimal risk, as isc-dhcp-client is in very very widespread use. In the event of a regression, network boot would fail, but the prior kernel should still be bootable.

It is in widespread use; and the set of functionality used by ipconfig in the initramfs is very small, so unlikely to run into any problems as a result of behavior differences between ipconfig and dhclient.

However, the risk is non-zero, and I consider it acceptable to change the dhcpv4 client from ipconfig to dhclient in SRU solely because we should also plan to solve 1) in the longer term, which is only possible by removing klibc-utils completely from the initramfs. Were this not the case, the preferred safer path would be to continue using ipconfig for ipv4 and use dhclient only for ipv6.

Changed in initramfs-tools (Ubuntu Xenial):
importance: Undecided → High
Changed in isc-dhcp (Ubuntu Xenial):
importance: Undecided → High
Changed in open-iscsi (Ubuntu):
importance: Undecided → High
Changed in open-iscsi (Ubuntu Xenial):
importance: Undecided → High
Gavin Panella (allenap) on 2016-09-26
Changed in maas:
status: Confirmed → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu12.3

---------------
isc-dhcp (4.3.3-5ubuntu12.3) xenial; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * debian/isc-dhcp-client.install: install new files for initramfs-tools
    to their proper locations; from debian/initramfs-tools. (LP: #1621507)

 -- LaMont Jones <email address hidden> Fri, 23 Sep 2016 15:09:46 -0600

Changed in isc-dhcp (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in klibc (Ubuntu Xenial):
status: New → Confirmed
Changed in klibc (Ubuntu):
status: New → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu14

---------------
isc-dhcp (4.3.3-5ubuntu14) yakkety; urgency=medium

  * Add an initramfs-tools hook and ship everything we need to run dhclient in
    the initramfs. This is necessary for proper IPv6 netboot support.
    (LP: #1621507)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Sep 2016 09:57:48 -0400

Changed in isc-dhcp (Ubuntu):
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

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

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

  * scripts/functions: make sure we can try to start all available and suitable
    interfaces if ip= isn't set when setting up the network, and exit as soon
    as we get an IP address. This retains the old behavior from ipconfig when
    ip= is unset, for really simple remote-root scenarios. (LP: #1628306)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 27 Sep 2016 18:25:50 -0400

Changed in initramfs-tools (Ubuntu):
status: In Progress → Fix Released
LaMont Jones (lamont) on 2016-10-03
Changed in open-iscsi (Ubuntu):
assignee: LaMont Jones (lamont) → nobody
LaMont Jones (lamont) on 2016-10-03
no longer affects: ifupdown (Ubuntu)
no longer affects: ifupdown (Ubuntu Xenial)
Mike Pontillo (mpontillo) wrote :

I have regression-tested MAAS images (supplied by LaMont) containing the proposed fixes on a set of amd64 virtual machines in an IPv4 environment, and LaMont has carried out testing in an IPv6 environment.

Everything seems to be working, so I'm setting this to verification-done.

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

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

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

  * scripts/functions: make sure we can try to start all available and suitable
    interfaces if ip= isn't set when setting up the network, and exit as soon
    as we get an IP address. This retains the old behavior from ipconfig when
    ip= is unset, for really simple remote-root scenarios. (LP: #1628306)
  * scripts/functions: retain bootp/rarp behavior using ipconfig.

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 27 Sep 2016 16:27:38 -0400

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

The verification of the Stable Release Update for open-iscsi 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 open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu3.1

---------------
open-iscsi (2.0.873+git0.3b4b4500-14ubuntu3.1) xenial; urgency=medium

  * add support for IPV6{DOMAINSEARCH,DNS0,DNS1} to net-interface-handler
    (LP: #1621507)

 -- LaMont Jones <email address hidden> Tue, 20 Sep 2016 08:05:41 -0600

Changed in open-iscsi (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu8

---------------
open-iscsi (2.0.873+git0.3b4b4500-14ubuntu8) yakkety; urgency=medium

  * debian/tests/xkvm: don't --enable-kvm.

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 05 Oct 2016 12:58:21 -0400

Changed in open-iscsi (Ubuntu):
status: Fix Committed → Fix Released
LaMont Jones (lamont) wrote :

This was resolved by switching away from klibc's ipconfig

Changed in klibc (Ubuntu):
status: Confirmed → Won't Fix
Changed in klibc (Ubuntu Xenial):
status: Confirmed → Won't Fix
Changed in maas:
status: Triaged → Fix Released
LaMont Jones (lamont) on 2016-10-11
tags: added: verification-pending
removed: verification-done
LaMont Jones (lamont) wrote :

After looking into this more (and working on Bug #1629972 some), there are couple of issues with the new configure_networking:

1. since it checks only for the existence of /run/net-${DEVICE}.conf, and the dhclient scripts ALWAYS (even on failure) create it, it will try to get a lease exactly once before bailing out. Ideally, if both ipv4 and ipv6 are present on the vlan, then both would be configured and (as is done) present in the net-$DEV.conf file.

2. Since router-advertisements are needed for the on-link indication (and routes), ipv6 configuration via dhcp should wait until such time as there is at least a (non-fe80) route for some ipv6 cidr on $DEVICE (which RA should create). This will eliminate the iscsi-timeout errors that we see when configure_networking() returns before RA configures routing. Note that a default route is not necessary. Note also that it should timeout on the RA if it doesn't show up in a reasonable time, complain that it got no RA, and then _not_ bring up ipv6 on the interface (RA is required, as per Bug #1609898)

tags: added: verification-failed
removed: verification-pending
LaMont Jones (lamont) wrote :

Filed the above 2 issues as (1) Bug #1632804 and (2) Bug #1632808 for yakkety. noting that here because those should be fixed as part of the xenial SRU of this bug.

Reopening, as we reverted the SRU (but will also fix things in Zesty and Yakkety with a better method than overriding ip=)

Steve Langasek (vorlon) wrote :

initramfs-tools has been reverted in xenial due to regression (bug #1631474). Resetting the bug state, we need to get support for ipv6 back into xenial-updates but in a regression-free way, which - per discussion on bug #1631474 and bug #1634176 - probably implies a separate 'ip6=' boot option, with corresponding changes to the components populating the boot commandline.

Changed in initramfs-tools (Ubuntu Xenial):
status: Fix Released → Triaged
Changed in initramfs-tools (Ubuntu):
status: Fix Released → In Progress
Scott Moser (smoser) wrote :

As I suggested in bug 1634176, I think that we can extend the 'ip=' parameter to work as it has a 'autoconf' parameter in it, which indicates the type of "auto" configuration to do:

klibc documents the previous ip= syntax at README.ipconfig [1].
  <client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>

My suggestion is to extend the 'autoconf' parameter. Previously the supported documented values were 'rarp', 'bootp', 'both', 'dhcp', 'all', 'off', 'static', 'none'. I suggest we add 'dhcp6' to the the list.

We could also support 'dhcp4,dhcp6' or 'dhcp+dhcp6' indicating both should be tried or possibly dhcp6 if and only if dhcp4 failed. I think though, for the immediate use case that just adding 'dhcp6' to the autoconf types would suffice.

Scott Moser (smoser) on 2016-10-24
description: updated
LaMont Jones (lamont) on 2016-10-27
Changed in maas:
assignee: nobody → LaMont Jones (lamont)
status: Fix Released → In Progress
Launchpad Janitor (janitor) wrote :

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

---------------
initramfs-tools (0.125ubuntu7) zesty; urgency=medium

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

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 17 Oct 2016 17:05:49 -0400

Changed in initramfs-tools (Ubuntu):
status: In Progress → Fix Released
LaMont Jones (lamont) wrote :

I'm attaching debdiffs for initramfs-tools, isc-dhcp, and open-iscsi. The combination (along with cloud-initramfs-tools and cloud-init -- see bug 1621615) seem to work with maas in IPv4, IPv6, and dual stack (booting IPv4 and IPv6), when added to yakkety-proposed.

LaMont Jones (lamont) wrote :
LaMont Jones (lamont) wrote :
LaMont Jones (lamont) wrote :

attached debdiff needs to roll forward into zesty.

Changed in initramfs-tools (Ubuntu):
status: Fix Released → In Progress
LaMont Jones (lamont) wrote :

All of the debdiffs need to be rolled into zesty, and backported to yakkety, xenial.

Changed in isc-dhcp (Ubuntu):
status: Fix Released → In Progress
Changed in isc-dhcp (Ubuntu Xenial):
status: Fix Released → In Progress
Changed in isc-dhcp (Ubuntu Yakkety):
status: Fix Released → In Progress
LaMont Jones (lamont) on 2016-11-02
Changed in open-iscsi (Ubuntu):
status: Fix Released → In Progress
Changed in open-iscsi (Ubuntu Xenial):
status: Fix Released → In Progress
LaMont Jones (lamont) on 2016-11-02
Changed in open-iscsi (Ubuntu Yakkety):
status: Fix Released → In Progress
LaMont Jones (lamont) wrote :

all 3 debdiffs need to land in zesty, and be backported to yakkety and xenial for SRU.

tags: added: patch
Changed in maas:
status: In Progress → Fix Committed
Scott Moser (smoser) wrote :

I've just took a read of the code that landed. Over all, the new code is much more suitable for SRU. I think it still has some issues though.

a.) we use 'grep' and 'cat' extensively in the new code. Most could be replaced with case statements or other shell builtin such as 'case' and 'read' and avoid subprocesses and their overhead. This is not broken, but slower boot as a result.

b.) ipconfig would set the 'hostname' in the dhcp request to the value in the 5th token of ip=. I do not believe that is being done now.

c.) at least 1 dhclient process will end up running after exiting the initramfs exits, and won't' have access to its open files. I'm not sure what the behavior will be, but its possible that this process could decide at re-lease time to take the interface down since it would not have its lease database around. I say at least due to bug 1633619. If we ever re-try, I suspect we'll have one for each loop.

Do we know what happens to this uprooted dhclient process?

d.) The ipconfig path that was left on will now have 'sleep's inserted and will as a result take much longer than necessary if it ever does not get a lease on the first try.

'b' is definitely a change in behavior. We really need to know what happens on 'c', and 'd' seems like it should be fixed as it negatively affects the 'ip=' path.

d) is "unavoidable" if we're do make use of ROUNDTTT, and to be frank, seems like a reasonable side-effect. There's only so much that can be done to handle both IPv4 and IPv6 in the initramfs, and I think we can live we a few extra seconds booting. Furthermore, systems that do not get their IP addresses in the first few seconds probably deserve a good revision -- it is likely happening due to suboptimal network configuration (you shouldn't have to wait multiple seconds for the DHCP server to respond). In the case where there is no IPv4 available, it won't change the end result -- the system will still fail to boot, it will just take longer doing so (and on IPv6-only, people should set ip=off explicitly, and that use case was not previously supported).

In the context of an SRU, it seems like a better deal to cause things to take a little longer in the less used, deprecated method of using ipconfig than to change ipconfig parameters in a way that might cause other issues (reducing the timeout generally, and using the sleep "alone" means systems that are genuinely slow might fail completely for no good reason. Making the timeout 2 seconds every time would yield to such an effect; whereas making the timeout 30 every time would lead to a substantial delay in bringing up the network if the first tries fail).

b) I haven't seen a proper use case where this was important. There isn't straightforward way to set the hostname request for dhclient; and properly configuring the DHCP server would get you the right hostname. Furthermore, the hostname in use when enlisting or deploying MAAS systems should not matter, as it's the kind of information that should be written out to the final system (and doesn't matter on ephemeral, "get how many disks this machine has" instances -- the hostname there is already known and set by MAAS).

a) A valid concern, but let's focus on making things work at all before optimizing. This should be verified in the devel release before a SRU.

c) I don't know what it will do; it will need to be properly watched in SRUs and the devel release. My initial testing shows absolutely no adverse effects.

Scott Moser (smoser) wrote :

Most definitely my comments above are with regard to SRU, because I know
that the point of this bug is to be SRU'd.

> d) is "unavoidable" if we're do make use of ROUNDTTT, and to be frank,
> seems like a reasonable side-effect. There's only so much that can be
> done to handle both IPv4 and IPv6 in the initramfs, and I think we can
> live we a few extra seconds booting. Furthermore, systems that do not
> get their IP addresses in the first few seconds probably deserve a good
> revision -- it is likely happening due to suboptimal network
> configuration (you shouldn't have to wait multiple seconds for the DHCP
> server to respond). In the case where there is no IPv4 available, it
> won't change the end result -- the system will still fail to boot, it
> will just take longer doing so (and on IPv6-only, people should set
> ip=off explicitly, and that use case was not previously supported).

How is not doing a 'sleep' unavoidable? The new code path only uses
dhclient in some cases for ipv4. In cases where it still allows the
ipconfig path (kernel command line of 'ip=dhcp') the initramfs will now
sleep in between re-tries when previously it would not.

It will take longer to boot, and that is a regression. It is definitely
fixable.

> In the context of an SRU, it seems like a better deal to cause things to
> take a little longer in the less used, deprecated method of using
> ipconfig than to change ipconfig parameters in a way that might cause

How are you "deprecate" ing this ? Can you show me where deprecating
behavior is allowed in an SRU?

> other issues (reducing the timeout generally, and using the sleep
> "alone" means systems that are genuinely slow might fail completely for
> no good reason. Making the timeout 2 seconds every time would yield to
> such an effect; whereas making the timeout 30 every time would lead to a
> substantial delay in bringing up the network if the first tries fail).

> b) I haven't seen a proper use case where this was important. There
> isn't straightforward way to set the hostname request for dhclient; and
> properly configuring the DHCP server would get you the right hostname.
> Furthermore, the hostname in use when enlisting or deploying MAAS
> systems should not matter, as it's the kind of information that should
> be written out to the final system (and doesn't matter on ephemeral,
> "get how many disks this machine has" instances -- the hostname there is
> already known and set by MAAS).

see bug 1069570 for a real world example (even affecting MAAS) of how a
hostname is important.
Something being "not straight forward" doesn't mean that you can just
regress behavior in an SRU. MAAS is not the only consumer of ipv4 dhcp
boot.

> a) A valid concern, but let's focus on making things work at all before
> optimizing. This should be verified in the devel release before a SRU.

> c) I don't know what it will do; it will need to be properly watched in
> SRUs and the devel release. My initial testing shows absolutely no
> adverse effects.

Did you ever boot a system and look? I suggest you need to account for
that and test and see what happens.

Scott Moser (smoser) wrote :

I just had the thought.. is there any reason that we are using dhclient for ipv4 rather than leaving the old path in place entirely for ip= ?

If we just change back to letting klibc's ipconfig take care of the ipv4 dhcp, then that resolves my 'b' and 'c' (for the ipv4 case).

We can then also go back to the original test for "done" of just checking for presense of /run/net-"$DEVICE".conf to idnicate ipv4 is done. All in all, the change to taking 'ip6=' on the command line makes it fairly easy to ensure we do not regress the ipv4 use case.

Scott Moser (smoser) wrote :

the suggested further changes here make the ipv4 path basically not touched.

Robie Basak (racb) wrote :

I'm here processing open-scsi in the Xenial and Yakkety SRU queues. However, I feel that this SRU is far from ready to be accepted into the proposed pockets and am inclined to reject the uploads to prevent further confusion.

1) Stakeholders don't appear to have consensus on how this problem should be fixed. Can you figure this out amongst yourselves before uploading? If you end up at an impasse, I'd appreciate a description and clarity on what the impasse is exactly to help the SRU team (or the TB if Zesty I guess) make a decision.

2) Given that the first attempt has regressed stable releases already and had to be backed out, I'd expect more effort to bake this in the development release first, rather than throwing it at stable releases at the same time.

3) I expect the "Test Case" and "Regression Potential" paperwork to make reference to the regression that has already hit the updates pocket, with a test plan to stop that sort of thing happening again, but these sections don't appear to have been touched.

4) open-iscsi, which is in the upload queue for Xenial and Yakkety, doesn't currently have its development task marked Fix Released and I see no explanation for this. I see that this is likely due to a dep8 failure blocking proposed migration. But given point 2, perhaps we shouldn't ignore that as it might be hiding a real failure?

5) It may be that the open-iscsi change itself is uncontroversial and that's why it is uploaded without the others. But if we did accept open-iscsi into proposed, then we'd end up with a verification-needed tag, which might soon turn into verification-done. If we then end up accepting initramfs-tools or isc-dhcp, then we may end up racing the tags, causing confusion and accidental release of an proposed update that has not been verified. I'd like to confirm with a more experienced SRU team member whether this could actually happen, but it seems to me that given the complexity of this SRU it would make more sense to first get consensus on all the changes intended to be landed to fix this issue, land everything into proposed at once, verify them both individually and functionally all together while they are all in proposed together, and then release them all together to the updates pocket. Doing them piecemeal doesn't make much sense to me, and I feel increases regression risk. Additionally one update could end up insufficient as you debate and change the approach, in which case we'd need an additional SRU (and risk another regression, etc) for no good reason.

Robie Basak (racb) wrote :

We discussed this on IRC in #ubuntu-release and agreed on the following plan of action:

0. cyphermox has uploaded open-iscsi to xenial and yakkety
1. rbasak will review open-iscsi (only) for acceptance into {xenial,yakkety}-proposed. Go back to step 0 for diff changes as needed, but there are no other blockers on the bug or on initramfs-tools or isc-dhcp
2. Nobody will upload isc-dhcp or initramfs-tools to the SRU queues in relation to this issue until open-iscsi finishes the SRU process in the usual way. Other unrelated SRUs to isc-dhcp and initramfs-tools are unaffected.
3. cyphermox will get consensus on the diffs for isc-dhcp and initramfs-tools
4. smoser will review and +1 the diffs (else go back to 3)
5. cypermox will upload isc-dhcp and initramfs-tools together to the xenial and yakkety queues for SRU processing in the usual way

This assumes that:
* Nobody has an objection to the current open-iscsi diff
* Nobody expects the open-iscsi diff to need to change based on the conclusion of the changes to be made to isc-dhcp and initramfs-tools

[rbasak] IMHO, the open-iscsi change seems straightforward enough to not be as concerned about regressions as I am with the previous initramfs-tools regression. So I think it's OK that open-iscsi dep8 is currently failing in Zesty. We can check to see that it passes in Xenial and Yakkety before releasing to -updates. I would still expect future initramfs-tools and isc-dhcp SRUs to be well tested in the development release, however.

There is a whitespace indetation inconsistency in the diff, but this went into zesty-proposed as well, and would create diff noise when comparing that. The mistake's been made, so I'll leave it as is.

Similarly, the whitespace change dropping an extra space in an if statement shouldn't really be part of the SRU, but I'll leave it as-is in order to make progress.

Changed in open-iscsi (Ubuntu Yakkety):
status: In Progress → Fix Committed
tags: removed: verification-failed
tags: added: verification-needed

Hello LaMont, or anyone else affected,

Accepted open-iscsi into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-iscsi/2.0.873+git0.3b4b4500-14ubuntu8.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 open-iscsi (Ubuntu Xenial):
status: In Progress → Fix Committed
Robie Basak (racb) wrote :

Hello LaMont, or anyone else affected,

Accepted open-iscsi into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-iscsi/2.0.873+git0.3b4b4500-14ubuntu3.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 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!

initramfs-tools fixed for ipv6 are already in zesty.

Changed in initramfs-tools (Ubuntu):
status: In Progress → Fix Released

ipv6 changes for isc-dhcp running in the initramfs are in zesty, too.

Changed in isc-dhcp (Ubuntu):
status: In Progress → Fix Released
LaMont Jones (lamont) wrote :

open-iscsi is verified for xenial and yakkety

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

This bug was fixed in the package open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu3.2

---------------
open-iscsi (2.0.873+git0.3b4b4500-14ubuntu3.2) xenial; urgency=medium

  [ LaMont Jones ]
  * Clean up net-interface-handler
  * Source /run/net6-*.conf when needed.

  [ Mathieu Trudel-Lapierre ]
  * debian/extra/initramfs.local-top: handle IPv6 configs being shipped in
    DEVICE6 or /run/net6-*.conf in the initramfs, so we can fill in
    /run/initramfs/open-iscsi.interface (LP: #1621507)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 08 Nov 2016 15:52:50 -0500

Changed in open-iscsi (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu8.1

---------------
open-iscsi (2.0.873+git0.3b4b4500-14ubuntu8.1) yakkety; urgency=medium

  [ LaMont Jones ]
  * Clean up net-interface-handler
  * Source /run/net6-*.conf when needed.

  [ Mathieu Trudel-Lapierre ]
  * debian/extra/initramfs.local-top: handle IPv6 configs being shipped in
    DEVICE6 or /run/net6-*.conf in the initramfs, so we can fill in
    /run/initramfs/open-iscsi.interface (LP: #1621507)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 08 Nov 2016 15:52:57 -0500

Changed in open-iscsi (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Scott Moser (smoser) wrote :

Hi,
I've reviewed the changes that Mathieu has suggested at https://launchpadlibrarian.net/295312215/isc-dhcp_4.3.3-5ubuntu15.2~mtrudel4_4.3.3-5ubuntu15.2~mtrudel5.diff.gz .

I'm fine to let what he has go in there. I suggest, however, that we drop the exposing of dhclient variables to the /run/net-* scripts. This can easily be accomplished by dropping the 'for prefix in' loop in debian/initramfs-tools/lib/etc/dhcp/dhclient-enter-hooks.d/config .

The gain in removing that is not exposing the implementation detail or as-yet-unused variable names to the user and thus needing to support them. Adding "may be used later" type things to an SRU should be done with great hesitation. To be clear, in the /run/net-eth0.conf file, we'll have things like:
   * reason
   * ip6_address
in addition to things like:
   * IPV6ADDR

The lower case variables are copied through from dhclient-script's environment, and are dhclient specific. Going forward these may be hard to support if Ubuntu ever moved off dhclient (such as to networkd).

I'm willing to leave that up to the SRU team to decide, but feel that it should be identified.

I'm OK with it going in as it is, I'll not fight this any more.

Chris Halse Rogers (raof) wrote :

Hello LaMont, or anyone else affected,

Accepted isc-dhcp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu12.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 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!

Changed in initramfs-tools (Ubuntu Xenial):
status: Triaged → Fix Committed
Changed in isc-dhcp (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: removed: verification-done
tags: added: verification-needed
Chris Halse Rogers (raof) wrote :

Hello LaMont, 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!

Changed in initramfs-tools (Ubuntu Yakkety):
status: In Progress → Fix Committed
Changed in isc-dhcp (Ubuntu Yakkety):
status: In Progress → Fix Committed
Chris Halse Rogers (raof) wrote :

Hello LaMont, or anyone else affected,

Accepted isc-dhcp into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu15.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) wrote :

Hello LaMont, 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-07
description: updated
Robie Basak (racb) on 2016-12-08
description: updated
Robie Basak (racb) on 2016-12-09
description: updated
Robie Basak (racb) wrote :

I've been working on reviewing this over the last few days. Thanks to
everyone for your help and patience, especially Mathieu, LaMont and
Scott for your in-person interactive responses.

We've had various review feedback loops and settled on using the MPs for
coordination. When everyone (including me, for ~ubuntu-sru) is happy, we
can upload and accept from the unapproved queue all at once.

From a code review perspective, I'm done, though am waiting for the
agreed fixes to come through (and be checked by everyone relevant).

From a QA review perspective, I would like a comprehensive test plan for
existing ip= use cases given the previous regressions that we've had.
There isn't currently anything on this in the bug description.

As we've been delayed enough already, I think it's OK to accept the
agreed changes into xenial-proposed now, provided that we agree on a
regression test plan and perform it before marking verification-done.

For everyone, here's the current status for Xenial.

Needed before accepting into xenial-proposed:

[cyphermox] initramfs-tools MP, and reviews from everyone
[smoser] isc-dhcp MP: Scott's review

[not rbasak] initramfs-tools upload from MP (blocked on MP and reviews)
[not rbasak] isc-dhcp upload from MP (blocked on MP review)
[rbasak] Check and accept from Xenial unapproved (blocked on above except for open-iscsi; might as well do all three together when ready)

Needed before accepting into xenial-updates:

Write a comprehensive test plan for existing ip= use cases given the previous regressions.
[rbasak or another ~ubuntu-sru] Agree on test plan.

All SRU review bugfixes incorporated into Zesty.

Standard test case verification for the problem we're fixing (ip6= function).

Mark verification-done (blocked on all of the above).

Robie Basak (racb) wrote :

Hello LaMont, or anyone else affected,

Accepted open-iscsi into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-iscsi/2.0.873+git0.3b4b4500-14ubuntu3.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!

Changed in open-iscsi (Ubuntu Xenial):
status: Fix Released → In Progress
status: In Progress → Fix Committed
status: Fix Committed → In Progress
status: In Progress → Fix Committed
Robie Basak (racb) wrote :

Hello LaMont, 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.7 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!

Robie Basak (racb) wrote :

Hello LaMont, or anyone else affected,

Accepted isc-dhcp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu12.6 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!

LaMont Jones (lamont) on 2016-12-13
description: updated
description: updated
LaMont Jones (lamont) on 2016-12-14
description: updated
LaMont Jones (lamont) wrote :

Today, I tested all of the MAAS cases with current -proposed from both xenial and yakkety. Behaves as expected.

description: updated
description: updated
LaMont Jones (lamont) wrote :

Marking the "normal boot, no remote root" as verified, since I did that about a dozen times today.

Robie Basak (racb) wrote :

11:11 <rbasak> cyphermox, lamont: in bug 1621507's test cases, we had previous reported regressions with ip="" and ip=:::::eth0:dhcp. Those should be in the test plan, IMHO.

11:13 <rbasak> cyphermox: lamont: what are "jderose's use cases"?

11:15 <rbasak> cyphermox: lamont: also, under "Non-MAAS test cases", will it matter what the network responds with? In the IPv4 cases, we need to make sure that behaviour doesn't change whether or not IPv6 DHCP and/or radvd are present, so the status of the network should be part of the test case.

11:16 <rbasak> For ip6= I'm not so bothered, since existing users won't be using that.

11:22 <rbasak> cyphermox, lamont: final two points. 1) are the review fixes we landed in proposed in Xenial in Zesty yet? If not, they should be, and I expect to block release of the SRUs on this. I gave a pass at accepting into proposed only because we were so delayed already; we have time now.

11:23 <rbasak> cyphermox, lamont: 2) who's actually going to do all the verifications here? It seems to be that nobody is nominated right now, so I'm expecting it to run past the seven days right now, and I know lamont is in a hurry, so you should probably resolve that now.

Robie Basak (racb) wrote :

Note that we also don't usually release SRUs on Fridays or over the weekend.

description: updated

jderose is a community contributor. I don't know how to reach him other than over IRC/Launchpad (which I did). I removed that entry for now, but we should have his input on that SRU as one more data point to validate that we're not breaking things that worked.

LaMont Jones (lamont) on 2016-12-15
description: updated
Brian Murray (brian-murray) wrote :

I've accepted a new version of open-iscsi in yakkety, but the SRU tools barfed on modifying the bug.

Changed in open-iscsi (Ubuntu Yakkety):
status: Fix Released → Fix Committed
description: updated

I've done all the non-MAAS test cases on xenial so far except for completing an installation with proposed enabled (it's a little more complicated); things are working as expected. I removed the "Booting an iSCSI remote root via IPv6 (no ip6=, d-i use case)" as it makes no sense -- d-i will not set up iscsi for IPv6 at this point.

description: updated

d-i install with proposed enable also passed. As far as I am concerned, this is verification-done for *Xenial*.

We may still want to wait for Jason DeRose's input on the SRU.

description: updated
LaMont Jones (lamont) wrote :

Final review feedback has been incorporated into initramfs-tools, isc-dhcp, and open-iscsi, and uploaded to zesty.

description: updated

All non-MAAS remote rootfs -based test cases have been verified for Yakkety now. Everything checks out. I will now do the last test case remaining which is to do a standard (non-remote root) install and upgrade to proposed packages to make sure standard installs aren't broken.

description: updated
Changed in isc-dhcp (Ubuntu Xenial):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in initramfs-tools (Ubuntu Xenial):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
milestone: none → xenial-updates

All the listed test cases appear to have been covered and successfully verified for both xenial and yakkety. We're just waiting for Jason to do his testing (he said "tomorrow" Friday December 16...). If that gets done then, the updates should be good to release on Monday (there aren't usually SRU promotions to -updates on Fridays).

description: updated
LaMont Jones (lamont) on 2016-12-16
description: updated
Jason Gerard DeRose (jderose) wrote :

Mathieu,

Okay, just finished testing with xenial-proposed, no issues found.

Things are working as expected for my use-case (with no adjustments on my end), so at least for the corners that my particular use-cases covers, this proposed package seems regression free.

I tested PXE booting into a "diskless" read-only Ubuntu server environment (using syslinux as the bootloader). Tested in both BIOS and UEFI mode.

Sorry it took me a bit to do this follow-up testing!

Thanks!

LaMont Jones (lamont) wrote :

Reconfirmed yakkety today.

Also tested "ip6= without ip=": which yakkety currently hates, but we've decided to handle separately after this SRU lands, partially because it's a trivial workaround ("for ipv6-only, specify "ip6=dhcp ip=off") and also not a case that anything needing the SRU actually does. (MAAS always specifies both, with one of them set to "off".)

Marking this verification-done.

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

This bug was fixed in the package open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu3.3

---------------
open-iscsi (2.0.873+git0.3b4b4500-14ubuntu3.3) xenial; urgency=medium

  * Fix syntax error in previous changes. LP: #1621507

 -- LaMont Jones <email address hidden> Fri, 09 Dec 2016 11:44:56 +0100

Changed in open-iscsi (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu12.6

---------------
isc-dhcp (4.3.3-5ubuntu12.6) xenial; urgency=medium

  * debian/initramfs/lib/etc/dhcp/dhclient-enter-hooks.d/config: clean up
    script to remove IPv4 bits that would never be called; since for this SRU
    we only do IPv6. (LP: #1621507)

isc-dhcp (4.3.3-5ubuntu12.5) xenial; urgency=medium

  * debian/initramfs/lib/etc/dhcp/dhclient-enter-hooks.d/config: fix script to
    not write to /run/net-$iface.conf when dealing with IPv6; which should only
    write to a /run/net6-$iface.conf file. (LP: #1621507)
  * debian/README.Debian: document what this config script is and why a hook is
    shipped for the initramfs.

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 08 Dec 2016 17:43:34 +0100

Changed in isc-dhcp (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

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

  * scripts/functions: clean up configure_networking and the function
    all_netbootable_interfaces to not have side-effects. (LP: #1621507)

initramfs-tools (0.122ubuntu8.6) xenial; 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.

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 08 Dec 2016 18:01:45 +0100

Changed in initramfs-tools (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu8.2

---------------
open-iscsi (2.0.873+git0.3b4b4500-14ubuntu8.2) yakkety; urgency=medium

  * Fix syntax error in previous changes. LP: #1621507

 -- LaMont Jones <email address hidden> Fri, 09 Dec 2016 11:59:02 +0100

Changed in open-iscsi (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu15.2

---------------
isc-dhcp (4.3.3-5ubuntu15.2) yakkety; urgency=medium

  * debian/initramfs/lib/etc/dhcp/dhclient-enter-hooks.d/config: fix script to
    not write to /run/net-$iface.conf when dealing with IPv6; which should only
    write to a /run/net6-$iface.conf file. (LP: #1621507)
  * debian/README.Debian: document what this config script is and why a hook is
    shipped for the initramfs.

isc-dhcp (4.3.3-5ubuntu15.1) yakkety; urgency=medium

  * ipv6: wait for duplicate address detection to finish (LP: #1633479).

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 21 Oct 2016 12:46:20 -0400

Changed in isc-dhcp (Ubuntu Yakkety):
status: Fix Committed → Fix Released
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
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu14

---------------
open-iscsi (2.0.873+git0.3b4b4500-14ubuntu14) zesty; urgency=medium

  * Make systemd job not run in containers (LP: #1576341)

 -- Serge Hallyn <email address hidden> Sun, 15 Jan 2017 23:08:29 -0600

Changed in open-iscsi (Ubuntu):
status: In Progress → Fix Released
Changed in maas:
status: Fix Committed → Fix Released
Changed in klibc (Debian):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.