[Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[Scott Moser]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1621507

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  Fix Committed
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Xenial:
  Triaged
Status in isc-dhcp source package in Xenial:
  In Progress
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  In Progress
Status in initramfs-tools source package in Yakkety:
  In Progress
Status in isc-dhcp source package in Yakkety:
  In Progress
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  In Progress
Status in klibc package in Debian:
  New

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) 

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

  These uploads address this by replacing the one-off klibc dhcp client
  (IPv4-only) with the defacto standard isc-dhcp-client, and thereby
  provide both ipv6 and ipv4 DHCP configuration.

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1621507/+subscriptions