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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1621507 Title: initramfs-tools configure_networking() fails to dhcp ipv6 addresses To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1621507/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
