This bug was fixed in the package nplan - 0.32~17.04.1
---
nplan (0.32~17.04.1) zesty; urgency=medium
* Backport 0.32 to 17.04. (LP: #1713142)
nplan (0.32) bionic; urgency=medium
* src/nm.c: better handle the UUID generation; the order of iterating
through interaces may
This bug was fixed in the package nplan - 0.32~16.04.3
---
nplan (0.32~16.04.3) xenial; urgency=medium
* tests/integration.py: Really fix skipping test_routes_v6 for the NM
backend.
nplan (0.32~16.04.2) xenial; urgency=medium
* tests/integration.py: Fix test_routes_v6 that
verification-done for xenial 0.32~16.04.3, and zesty 0.32~17.04.1:
IPv6 addresses are handled correctly through the lxd bridge; AcceptRA is
not longer set by default but the option is available to users.
** Tags removed: verification-needed verification-needed-xenial
verification-needed-zesty
Hello Stéphane, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.3 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Hello Stéphane, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.2 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
Hello Stéphane, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.1 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
Hello Stéphane, or anyone else affected,
Accepted nplan into zesty-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~17.04.1 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
That's because you're using stateful DHCP which the kernel doesn't do.
My comment was about a stock setup which comes with stateless DHCP, in
which case all Linux distros do get a configured IPv6 address regardless
of what their userspace does, so long (and that was the problem with
nplan) as the
I am confused by Stephane's orginal opening statement that
| Prior to the switch to nplan, systems (in my case containers) would
| DHCP for IPv4 and let the kernel do IPv6 auto-configuration whenever a
| router advertisement comes in.
I opened bug 1732002 with information to the contrary.
On my
Verification-done for zesty with nplan 0.29~17.04.1:
As for xenial, this is a fix for a regression introduced in a package
that never actually made it to zesty. The regression does not appear in
netplan 0.29~17.04.1 at all, I verified that the container with nplan
upgraded properly gets both IPv4
Verification-done for xenial with nplan 0.29~16.04.1:
The bug this is fixing is a regression in 0.26~16.04.1, which is a
version that only landed in -proposed. 0.23~16.04.1 (the previous
released nplan) does not show this bug, and 0.29~16.04.1 does not show
IPv6 issues.
I set up a container with
Hello Stéphane, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.29~16.04.1 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
Hello Stéphane, or anyone else affected,
Accepted nplan into zesty-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.29~17.04.1 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
** Also affects: nplan (Ubuntu Xenial)
Importance: Undecided
Status: New
** Description changed:
+ [Impact]
+ This is a bug tracking a regression in netplan 0.25 and later, fixed directly
in the development release as of netplan 0.28. This does not affect stable
releases in any way;
This bug was fixed in the package nplan - 0.29
---
nplan (0.29) artful; urgency=medium
* Fix autopkgtests in a world where /run/NetworkManager/conf.d already
exists. nplan is enabled by default, so it might well have the directory
already created on the filesystem.
--
With the current YAML, despite the disabled processing of RAs, you could
add a dummy IPv6 address and thus let RAs be processed; but I'm going to
revert that and instead provide a way to toggle RA processing.
** Changed in: nplan (Ubuntu)
Importance: High => Critical
** Changed in: nplan
This is caused by the fix for
https://bugs.launchpad.net/maas/+bug/1655440. I guess netplan needs some
way of spelling all of "do dhcp6", "use kernel default for RA", "do not
configure ipv6 at all". My inclination is that we should add syntax for
the last one, which would break 1655440 again but
What we're expecting for LXC at least is:
- IPv4 -> DHCP (and block until you get something)
- IPv6 -> passive kernel SLAAC (don't block on lack of IPv6)
Is that something the current yaml can do?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Just looked at what netplan generates in networkd:
[Match]
Name=eth0
[Network]
DHCP=ipv4
IPv6AcceptRA=no
[DHCP]
RouteMetric=100
So that shows it's explicitly disabling IPv6 RA handling on the interface,
causing the regression.
--
You received this bug notification because you are a member
The nplan.yaml which is included in our containers is:
root@artful:~# cat /etc/netplan/10-lxc.yaml
network:
ethernets:
eth0: {dhcp4: true}
version: 2
/etc/network/interfaces used to be:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
Right now this seems to only
22 matches
Mail list logo
