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