Open mgedmin opened 5 years ago
Yes, the Debian/Ubuntu installers, (and possibly older apt versions) wouldn't work if the IPv6 stack is enabled. The only builds which require IPv6 to remain disabled after setup are the Lineage/Magma variants, which is why I haven't added a blanket removal to the cleanup.sh
module.
I think the reason it's tricky is because the network.sh
module makes the change, immediately before rebooting, otherwise I wouldn't need to persist the setting for every variant.
If enough people think it should be enabled by default, we could add something to the cleanup.sh
modules which removes it for the generic builds.
The boxes should be left in a state that is as close to the OS release as 'generically' possible.. If packages from the OS stream are failing to install that doesn't give people much confidence in using it as a generic base... IMO anyway.
Once I get the new servers setup, it will be easier to enable IPv6 and then quickly test what it breaks.
The problem was that enabling it broke the install process for some of the distro/provider combinations. As I recall Debian/Ubuntu on Hyper-V was the most problematic. Since configs tend to get carried forward without change, I haven't tested whether the newer releases fix the installer issues.
Can't we just use /etc/gai.conf instead to prefer IPv4 over IPv6?
I want to let you know this caused a lot confusion for me yesterday. This issue is still relevant. Having IPv6 disabled while thinking you have just started a fresh test environment got me off-guard. The fact that VMs still get IPv6 addresses and they don't work is easy to overlook and not intuitive.
I had a fun fifteen minutes trying to figure out why
sudo apt install redis-server
fails in a generic/ubuntu1804 VM. Turns out it wants to listen on::1
, but you ship a /etc/sysctl.conf that hasThe comments in your build scripts imply that you intended to disable IPv6 only temporarily, during the build process, or am I confused?