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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
