networkd should allow configuring IPV6 MTU
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd |
Unknown
|
Unknown
|
|||
cloud-init (Ubuntu) |
Undecided
|
Unassigned | |||
Bionic |
Undecided
|
Unassigned | |||
Disco |
Undecided
|
Unassigned | |||
Eoan |
Undecided
|
Unassigned | |||
Focal |
Undecided
|
Unassigned | |||
netplan.io (Ubuntu) |
Undecided
|
Unassigned | |||
Bionic |
Undecided
|
Unassigned | |||
Disco |
Undecided
|
Unassigned | |||
Eoan |
Undecided
|
Unassigned | |||
Focal |
Undecided
|
Unassigned | |||
systemd (Ubuntu) |
Medium
|
Dan Streetman | |||
Bionic |
Undecided
|
Dan Streetman | |||
Disco |
Undecided
|
Dan Streetman | |||
Eoan |
Undecided
|
Dan Streetman | |||
Focal |
Medium
|
Dan Streetman |
Bug Description
= netplan.io =
[Impact]
* IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic.
[Test Case]
* Apply a netplan configuration that specifices ipv6-mtu:
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000
* Check that MTU bytes, is at least IPv6MTUBytes on the interface:
$ sysctl net.ipv6.
net.ipv6.
[Regression Potential]
* This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity.
[Other Info]
* Original bug report below
= end of netplan.io =
= systemd =
[Impact]
* IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic.
[Test Case]
* Use IPv6MTUBytes= setting in a .network unit
* Restart systemd-network
* Check that there no error messages / warnings about not-recognizing this option
* Check that MTU bytes, is at least IPv6MTUBytes on the interface
[Regression Potential]
* This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity.
[Other Info]
* Original bug report below
= end of systemd =
1) Zesty
2) systemd-232-19
3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section
4) networkd does not parse or read the value and does not apply this configuration to the interface.
Upstream has discussed this issue here:
https:/
But it's been closed in favor of only setting via RA.
However, we know of multiple use-case which are currently supported in
ifdupdown where we want to retain control over IPV6 MTU values outside
of PMTU Discovery configurations.
Some context from those discussions
>> Client systems that route their ipv6 packets to a 6in4 router also
>> have to have their ipv6 mtu lowered. They could lower their link mtu,
>> so their ipv6 packets are small enough, but that reduces performance
>> of their ipv4 network.
Yes. Anything that creates a PMTUD black hole can result in
situations where the higher header overhead of IPv6 will cause IPv4 to
pass but IPv6 traffic to be dropped.
One example here is egress from an ipsec tunnel wherein the next
hop MTU is too low for IPv6 datagrams to pass. Another is VM ->
whatever -> host bridge -> tunnel ingress. If the datagram cannot enter
the tunnel due to size, it is dropped, and an ICMP response uses the
tunnel address as a source, which may not be routable back to the
origin. This one is an issue with IPv4 as well, and is one case where
manually setting the IPv6 MTU lower than the (also manually set) device
MTU is of benefit.
In essence, any of these sort of cases that require an explicit
setting of the device MTU will likely require a setting of the IPv6 mtu
as well to account for its larger header overhead.
Related branches
- Server Team CI bot: Approve (continuous-integration) on 2017-10-05
- Scott Moser: Approve on 2017-10-05
- Chad Smith: Pending requested 2017-10-04
-
Diff: 544 lines (+128/-134)13 files modifiedcurtin/commands/curthooks.py (+19/-5)
examples/tests/network_alias.yaml (+0/-2)
examples/tests/network_static_routes.yaml (+10/-15)
tests/vmtests/__init__.py (+20/-1)
tests/vmtests/test_network.py (+15/-11)
tests/vmtests/test_network_bonding.py (+16/-17)
tests/vmtests/test_network_bridging.py (+15/-9)
tests/vmtests/test_network_enisource.py (+2/-4)
tests/vmtests/test_network_ipv6.py (+0/-11)
tests/vmtests/test_network_ipv6_enisource.py (+3/-17)
tests/vmtests/test_network_ipv6_vlan.py (+0/-6)
tests/vmtests/test_network_mtu.py (+26/-24)
tests/vmtests/test_network_vlan.py (+2/-12)
- Server Team CI bot: Approve (continuous-integration) on 2020-07-10
- Dan Watkins: Approve on 2020-07-10
-
Diff: 30 lines (+0/-9)1 file modifiedtests/vmtests/test_network_mtu.py (+0/-9)
CVE References
Ryan Harper (raharper) wrote : | #1 |
Ryan Harper (raharper) wrote : | #2 |
The attachment "ipv6_mtu.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]
tags: | added: patch |
tags: | added: zesty |
Changed in systemd (Ubuntu): | |
importance: | Undecided → Medium |
Dimitri John Ledkov (xnox) wrote : | #4 |
Please submit this as a pullrequest upstream.
Ryan Harper (raharper) wrote : | #5 |
This also needs some discussion w.r.t how to handle IPV6-only devices; namely if you want to set the IPV6 MTU to something higher than the underlying device's current setting then the device MTU would need to be raised as well. That needs to be implemented and added to the patch.
Dimitri John Ledkov (xnox) wrote : | #6 |
I'm very naive, so please bear with me if this is a silly question. As far as I can tell the existing MTU setting in networkd will apply to both ipv4 and ipv6 simultaniously. Are you arguing that you want specific control of MTU and use different values for ipv4 and ipv6? Would it not be sufficient to set the appropriatly-
On Wed, May 17, 2017 at 1:14 PM, Dimitri John Ledkov <<email address hidden>
> wrote:
> I'm very naive, so please bear with me if this is a silly question. As
> far as I can tell the existing MTU setting in networkd will apply to
> both ipv4 and ipv6 simultaniously. Are you arguing that you want
> specific control of MTU and use different values for ipv4 and ipv6?
>
Yes
AFAICT, the MTUBytes field which is a link property, applies to the device
itself.
IPv6 has a separate *protocol* level MTU where it is used to fragment IPv6
packets
so they can be tunneled (among other things) over IPv4. There's also a
specific
IPv6 MTU setting to prevent IPv6 packets from being to small (I think 1280
is the
minimum MTU allowable for IPv6 packets.
Subsequently, the kernel has *two* MTUs, Device (ethernet, ppp, etc) and
IPv6 protocal
device: /sys/class/
ipv6: /proc/sys/
Would it not be sufficient to set the appropriatly-
> denominator value for MTU?
>
It is not. In the case that you want to use 9000 MTU on an ipv6 address,
one
needs to ensure that the MTU of the underlying device is raised from the
default to 9000
otherwise the V6 MTU means nothing.
In some cases you want to raise the MTU of the underlying device, but *not*
raise the MTU of the IPV6
this is a tunneling case:
eth0 mtu 9000
ipv6 mtu 1480
So, yes, we want independent control over v4 and v6 MTU.
Note, the upstream discussions (IMHO) punt the problem to Router
Advertisements; however what
does remain is that we currently have this control with ifupdown (with some
help of pre/post scripts).
I had a start at getting this working in networkd, however I wasn't able to
achieve the independent control
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https:/
> 1671951/
>
Nish Aravamudan (nacc) wrote : | #8 |
Unsubscribing sponsors based upon IRC discussion with rharper:
10:57 < nacc> rharper: is LP: #1671951 actually ready to sponsor?
10:57 < ubottu> Launchpad bug 1671951 in systemd (Ubuntu) "networkd should
https:/
11:07 < rharper> nacc: it was, but not sure of the status now; the debdiff
11:08 < nacc> rharper: ok, can i unsub sponsors for now?
11:08 < rharper> sure
Changed in systemd (Ubuntu): | |
status: | New → Confirmed |
tags: | added: id-5a6a5c89cfbc4063786d54f6 |
Ryan Harper (raharper) wrote : | #9 |
I've just seen that upstream systemd v239 claims to support IPV6MtuBytes
https:/
* networkd's .network files now support a new IPv6MTUBytes= option for
setting the MTU used by IPv6 explicitly as well as a new MTUBytes=
option in the [Route] section to configure the MTU to use for
specific routes. It also gained support for configuration of the DHCP
"UserClass" option through the new UserClass= setting. It gained
three new options in the new [CAN] section for configuring CAN
networks. The MULTICAST and ALLMULTI interface flags may now be
controlled explicitly with the new Multicast= and AllMulticast=
settings.
Dimitri John Ledkov (xnox) wrote : | #10 |
The v239 merge for cosmic is in progress at the moment. There are a few regressions that need to be worked around.
tags: | added: id-5b74352f76a21f210334eafd |
Dimitri John Ledkov (xnox) wrote : | #11 |
This is now in cosmic.
Changed in systemd (Ubuntu): | |
status: | Confirmed → Fix Released |
Dimitri John Ledkov (xnox) wrote : | #12 |
Do we need this in bionic?
Ryan Harper (raharper) wrote : | #13 |
On Wed, Aug 29, 2018 at 8:41 AM Dimitri John Ledkov
<email address hidden> wrote:
>
> Do we need this in bionic?
Yes
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https:/
Scott Moser (smoser) wrote : | #14 |
Hm...
Our tests show that this is not fixed in cosmic or bionic.
https:/
shows curtin's vmtest failing. Partial output shows:
=======
ERROR: test_ipv6_
-------
Traceback (most recent call last):
File "/var/lib/
raise RuntimeError(msg)
RuntimeError: skip_by_
-------
iface=interface4 subnets=
subnet:{'address': '2001:4800:
mtu_data:{'device': 1500, 'ipv6': 1500}
subnet_mtu=1480 ipv6_mtu=1500
-------
Ryan Harper (raharper) wrote : | #15 |
This may now be a cloud-init bug if the support is there since this is
a network-config v1 -> cloud-init renders netplan.
On Fri, Sep 28, 2018 at 9:12 AM Scott Moser <email address hidden> wrote:
>
> Hm...
>
> Our tests show that this is not fixed in cosmic or bionic.
>
> https:/
> shows curtin's vmtest failing. Partial output shows:
>
> =======
> ERROR: test_ipv6_
> -------
> Traceback (most recent call last):
> File "/var/lib/
> raise RuntimeError(msg)
> RuntimeError: skip_by_
> -------
> iface=interface4 subnets=
> subnet:{'address': '2001:4800:
> mtu_data:{'device': 1500, 'ipv6': 1500}
> subnet_mtu=1480 ipv6_mtu=1500
>
> -------
>
>
> ** Attachment added: "console log of curtin vmtest amd64 533"
> https:/
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https:/
Ryan Harper (raharper) wrote : | #16 |
Actually there needs to be changes to netplan to emit the correct IPV6BytesMtu setting to networkd; and then cloud-init can emit the correct netplan yaml for that. This feature is on the netplan roadmap here:
https:/
Changed in cloud-init (Ubuntu): | |
status: | New → Confirmed |
Changed in cloud-init (Ubuntu Bionic): | |
status: | New → Confirmed |
Changed in systemd (Ubuntu Bionic): | |
status: | New → In Progress |
description: | updated |
Hello Ryan, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in systemd (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed verification-needed-bionic |
Łukasz Zemczak (sil2100) wrote : | #18 |
Hello Ryan, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Ryan Harper (raharper) wrote : | #19 |
It seems there are some limitations to what systemd will do with IPv6BytesMTU.
1) if LinkLocalAddressing is not disabled, it will clobber any IPv6BytesMTU value set.
[Network]
LinkLocalAddres
Address=
IPv6MTUBytes=1470
This results in: /proc/sys/
if I disable LinkLocalAddressing like so:
[Network]
LinkLocalAddres
Address=
IPv6MTUBytes=1470
Then I get 1470.
This seems like a bug; do we need an upstream issue to track this?
2) systemd-networkd will not raise the device MTU limit automatically. The default device MTU is 1500. If you set IPv6BytesMTU to 1520, then systemd-networkd emits this message:
Nov 26 19:13:59 rharper-b2 systemd-
which is the same message you get if you: echo "1520" > /proc/sys/
# echo 1520 > /proc/sys/
bash: echo: write error: Invalid argument
If this is considered "acceptable" behavior for systemd, then it will leave netplan with a decision when it is presented with a config which sets an ipv6-mtu bytes value that is bigger than the default device value (1500), or bigger than an specified device mtu. Will it report an error with the config?
Should we file an upstream issue to see if networkd is willing to raise the device limit (or possibly emit a more helpful message to indicate that networkd cannot set an IPv6 MTU greater than the underlying device MTU?
Jay Vosburgh (jvosburgh) wrote : | #20 |
Regarding #2 from comment #19:
As the defined range for the ipv6.mtu is from IPV6_MIN_MTU to the device's MTU, and the existing API returns an error if the ipv6.mtu is out of range, I think it's reasonable for a configuration with the ipv6.mtu > device MTU to fail.
On Mon, Nov 26, 2018 at 11:11 PM Jay Vosburgh
<email address hidden> wrote:
>
> Regarding #2 from comment #19:
>
> As the defined range for the ipv6.mtu is from IPV6_MIN_MTU to the
> device's MTU, and the existing API returns an error if the ipv6.mtu is
> out of range, I think it's reasonable for a configuration with the
> ipv6.mtu > device MTU to fail.
I think that's reasonable too. We'll need to file a separate bug with
MAAS to ensure that
it knows it should set device MTU >= to the ipv6 MTU configured. This
will ensure
the configuration that gets generated will include both a raised
device MTU and an IPV6 MTU.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https:/
Dimitri John Ledkov (xnox) wrote : | #22 |
Using systemd 237-3ubuntu10.10
Using:
[Match]
Name=ens3
[Network]
DHCP=ipv4
IPv6MTUBytes=1600
[Link]
MTUBytes=1800
[DHCP]
UseMTU=no
RouteMetric=100
I do get:
$ cat /sys/class/
1800
$ cat /proc/sys/
1600
Thus one can set a different from the device, ipv6-specific mtu.
tags: |
added: verification-done verification-done-bionic removed: verification-needed verification-needed-bionic |
Ryan Harper (raharper) wrote : | #23 |
On Tue, Dec 4, 2018 at 6:31 AM Dimitri John Ledkov <email address hidden>
wrote:
> Using systemd 237-3ubuntu10.10
>
> Using:
> [Match]
> Name=ens3
> [Network]
> DHCP=ipv4
> IPv6MTUBytes=1600
> [Link]
> MTUBytes=1800
> [DHCP]
> UseMTU=no
> RouteMetric=100
>
Do you put this in the same .network file or .link file?
Ryan Harper (raharper) wrote : | #24 |
On Tue, Dec 4, 2018 at 9:31 AM Ryan Harper <email address hidden>
wrote:
>
>
> On Tue, Dec 4, 2018 at 6:31 AM Dimitri John Ledkov <email address hidden>
> wrote:
>
>> Using systemd 237-3ubuntu10.10
>>
>> Using:
>> [Match]
>> Name=ens3
>> [Network]
>> DHCP=ipv4
>> IPv6MTUBytes=1600
>> [Link]
>> MTUBytes=1800
>> [DHCP]
>> UseMTU=no
>> RouteMetric=100
>>
>
> Do you put this in the same .network file or .link file?
>
FWIW, I'm not able to make this work inside a LXD container. Could you
provide more details on how you validated and in what environment?
Dimitri John Ledkov (xnox) wrote : | #25 |
This was done inside a VM.
This was all done in a single /etc/systemd/
I'm not quite sure how you can reproduce this inside a lxd container, since it's not using a physical link, but a .netdev devices. I expect that specifying similar things in .network should work, but it might not. That is because a veth pair is precreated outside of the container, and one may need to adjust the host-side of the veth pair which is a priviledged operation.
Note that e.g. one can set MTU on virtual devices created using .netdev units.
tags: | added: id-5cc72cfe22e00d7a830c4ce4 |
Changed in netplan.io (Ubuntu): | |
status: | New → In Progress |
Launchpad Janitor (janitor) wrote : | #26 |
This bug was fixed in the package netplan.io - 0.98-0ubuntu1
---------------
netplan.io (0.98-0ubuntu1) eoan; urgency=medium
* New upstream release: 0.98 (LP: #1840832)
- Added new "feature flags" to identify new features
- Added support for "use-domains" for DHCP overrides
- Added support for setting IPv6 MTU Bytes (LP: #1671951)
- Added a DBus interface to query and run 'netplan apply' via other apps
- Various build system fixes
- Improved validation for bonding modes
- Added support for "hash:" for hashed 802.1x passwords (LP: #1819831)
- Tolerate devices without a /sys path (LP: #1810043)
- Fix incorrect separator for networkd with ARP IP targets (LP: #1829264)
* debian/control: Add Build-Depends on libsystemd-dev for DBus feature, and
on dbus-x11 for dbus-launch used in tests.
-- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Aug 2019 14:49:16 -0400
Changed in netplan.io (Ubuntu): | |
status: | In Progress → Fix Released |
description: | updated |
Hello Ryan, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in netplan.io (Ubuntu Bionic): | |
status: | New → Fix Committed |
tags: |
added: verification-needed verification-needed-bionic removed: verification-done verification-done-bionic |
Ryan Harper (raharper) wrote : | #28 |
I launched a bionic image on serverstack, updated the netplan.io to proposed, modified the network config to set ipv6-mtu to 6000 and rebooted.
root@b-
netplan.io:
Installed: 0.98-0ubuntu1~
Candidate: 0.98-0ubuntu1~
Version table:
*** 0.98-0ubuntu1~
500 http://
100 /var/lib/
0.
500 http://
0.40.1~18.04.4 500
500 http://
0.36.1 500
500 http://
root@b-
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
root@b-
[Match]
MACAddress=
[Link]
Name=ens3
WakeOnLan=off
root@b-
[Match]
MACAddress=
Name=ens3
[Network]
DHCP=ipv4
LinkLocalAddres
IPv6MTUBytes=6000
[DHCP]
RouteMetric=100
UseMTU=true
~# cat /sys/class/
8958
~# sysctl net.ipv6.
net.ipv6.
Dimitri John Ledkov (xnox) wrote : | #29 |
Followup on my comments, are any changes required in networkd to support this in bionic?
Ryan Harper (raharper) wrote : | #30 |
I tested with your single-file approach and that also fails. Note that bionic now has systemd 237, so maybe something is missing (or regressed) ?
$ apt-cache policy systemd
systemd:
Installed: 237-3ubuntu10.26
Candidate: 237-3ubuntu10.26
Version table:
*** 237-3ubuntu10.26 500
500 http://
100 /var/lib/
237-
500 http://
237-
500 http://
237-3ubuntu10 500
500 http://
Dimitri John Ledkov (xnox) wrote : Re: [Bug 1671951] Re: networkd should allow configuring IPV6 MTU | #31 |
I thought custom ipv6 MTU may not be lower than ipv4 one.
Hence request for 6000 ipv6 is not valid, when link is on 8958.
Can you try 9000?
On Wed, 28 Aug 2019, 15:41 Ryan Harper, <email address hidden> wrote:
> I launched a bionic image on serverstack, updated the netplan.io to
> proposed, modified the network config to set ipv6-mtu to 6000 and
> rebooted.
>
> root@b-
> netplan.io:
> Installed: 0.98-0ubuntu1~
> Candidate: 0.98-0ubuntu1~
> Version table:
> *** 0.98-0ubuntu1~
> 500 http://
> bionic-
> 100 /var/lib/
> 0.97-0ubuntu1~
> 500 http://
> bionic-updates/main amd64 Packages
> 0.40.1~18.04.4 500
> 500 http://
> Packages
> 0.36.1 500
> 500 http://
> amd64 Packages
>
> root@b-
> network:
> version: 2
> ethernets:
> ens3:
> dhcp4: true
> match:
> macaddress: fa:16:3e:4d:3c:6a
> set-name: ens3
> ipv6-mtu: 6000
>
> root@b-
> [Match]
> MACAddress=
>
> [Link]
> Name=ens3
> WakeOnLan=off
> root@b-
> [Match]
> MACAddress=
> Name=ens3
>
> [Network]
> DHCP=ipv4
> LinkLocalAddres
> IPv6MTUBytes=6000
>
> [DHCP]
> RouteMetric=100
> UseMTU=true
>
>
> ~# cat /sys/class/
> 8958
> ~# sysctl net.ipv6.
> net.ipv6.
>
> --
> You received this bug notification because you are subscribed to systemd
> in Ubuntu.
> Matching subscriptions: systemd
> https:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
>
> https:/
>
Ryan Harper (raharper) wrote : | #32 |
See comment #20; ipv6 mtu is 1280 -> DEVICE_MTU.
I'm testing something in the middle now.
On Eoan with:
network:
version: 2
ethernets:
ens3:
dhcp4: false
match:
mtu: 8958
It works. Now on bionic-proposed, it does not.
Aug 28 16:59:56.659125 b-test-ipv6-mtu systemd-
So, looks like bionic systemd is missing something.
Ryan Harper (raharper) wrote : | #33 |
err, on Eoan, I used ipv6-mtu 6000.
tags: | added: id-5d67fe691c14484db556d212 |
Changed in systemd (Ubuntu Bionic): | |
status: | Fix Committed → In Progress |
assignee: | nobody → Balint Reczey (rbalint) |
Hello Ryan, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in systemd (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Steve Langasek (vorlon) wrote : | #35 |
Hello Ryan, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/237-3ubuntu10.31) | #36 |
All autopkgtests for the newly accepted systemd (237-3ubuntu10.31) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:
gvfs/1.
netplan.
apt/1.6.12 (arm64, ppc64el)
pulseaudio/unknown (armhf)
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
Verification-done on bionic:
ubuntu@
bionic
ubuntu@
ii netplan.io 0.98-0ubuntu1~
ubuntu@
ii systemd 237-3ubuntu10.31 amd64 system and service manager
ubuntu@
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
version: 2
ethernets:
eth0:
dhcp4: true
match:
mtu: 6666
dhcp6: true
ubuntu@
ubuntu@
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
2 links listed.
ubuntu@
net.ipv6.
ubuntu@
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,
link/ether 06:e0:25:2e:08:ef brd ff:ff:ff:ff:ff:ff
ubuntu@
tags: |
added: verification-done-bionic removed: verification-needed verification-needed-bionic zesty |
Verification-done on disco:
ubuntu@
disco
ubuntu@
ii netplan.io 0.98-0ubuntu1~
ii systemd 240-6ubuntu5.7 amd64 system and service manager
ubuntu@
ubuntu@
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,
link/ether 06:92:5b:c9:b5:3d brd ff:ff:ff:ff:ff:ff
ubuntu@
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
2 links listed.
ubuntu@
net.ipv6.
ubuntu@
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
version: 2
ethernets:
eth0:
dhcp4: true
match:
mtu: 6666
dhcp6: true
tags: | added: verification-done-disco |
Changed in netplan.io (Ubuntu Disco): | |
status: | New → Fix Committed |
Launchpad Janitor (janitor) wrote : | #39 |
This bug was fixed in the package netplan.io - 0.98-0ubuntu1~
---------------
netplan.io (0.98-0ubuntu1~
* Backport netplan.io 0.98 to 19.04. (LP: #1840832)
-- Mathieu Trudel-Lapierre <email address hidden> Mon, 26 Aug 2019 16:41:36 -0400
Changed in netplan.io (Ubuntu Disco): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #40 |
This bug was fixed in the package netplan.io - 0.98-0ubuntu1~
---------------
netplan.io (0.98-0ubuntu1~
* Backport netplan.io 0.98 to 18.04. (LP: #1840832)
* Keep patches specific to 18.04 support:
- disable-
tunnel types (ipip and gre) in the 18.04 version of systemd-networkd.
* Drop debian/
made upstream to better account for the changes in HashTable.
* debian/
netplan.io (0.98-0ubuntu1) eoan; urgency=medium
* New upstream release: 0.98 (LP: #1840832)
- Added new "feature flags" to identify new features
- Added support for "use-domains" for DHCP overrides
- Added support for setting IPv6 MTU Bytes (LP: #1671951)
- Added a DBus interface to query and run 'netplan apply' via other apps
- Various build system fixes
- Improved validation for bonding modes
- Added support for "hash:" for hashed 802.1x passwords (LP: #1819831)
- Tolerate devices without a /sys path (LP: #1810043)
- Fix incorrect separator for networkd with ARP IP targets (LP: #1829264)
* debian/control: Add Build-Depends on libsystemd-dev for DBus feature, and
on dbus-x11 for dbus-launch used in tests.
-- Mathieu Trudel-Lapierre <email address hidden> Mon, 26 Aug 2019 16:36:03 -0400
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
The verification of the Stable Release Update for netplan.io has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Launchpad Janitor (janitor) wrote : | #42 |
This bug was fixed in the package systemd - 237-3ubuntu10.31
---------------
systemd (237-3ubuntu10.31) bionic; urgency=medium
[ Dimitri John Ledkov ]
* Add conflicts with upstart and systemd-shim. (LP: #1773859)
* d/p/debian/
- units: Disable journald Watchdog (LP: #1773148)
* d/p/cryptsetup-
- cryptsetup: add support for sector-size= option (LP: #1776626)
* d/p/systemctl-
- systemctl: correctly proceed to immediate shutdown if scheduling fails
(LP: #1670291)
* d/p/networkd-
- networkd: add support to set IPv6MTUBytes (LP: #1671951)
-- Balint Reczey <email address hidden> Mon, 30 Sep 2019 17:23:17 +0200
Changed in systemd (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Ryan Harper (raharper) wrote : | #43 |
I cannot verify this is working on bionic with ipv6 static addresses.
root@ubuntu:~# lsb_release -rd
Description: Ubuntu 18.04.3 LTS
Release: 18.04
root@ubuntu:~# cat /etc/cloud/
build_name: server
serial: 20191021
root@ubuntu:~# uname -a
Linux ubuntu 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# apt-cache policy netplan.io
netplan.io:
Installed: 0.98-0ubuntu1~
Candidate: 0.98-0ubuntu1~
Version table:
*** 0.98-0ubuntu1~
500 http://
100 /var/lib/
0.40.1~18.04.4 500
500 http://
0.36.1 500
500 http://
root@ubuntu:~# apt-cache policy systemd
systemd:
Installed: 237-3ubuntu10.31
Candidate: 237-3ubuntu10.31
Version table:
*** 237-3ubuntu10.31 500
500 http://
100 /var/lib/
237-
500 http://
237-3ubuntu10 500
500 http://
root@ubuntu:~# cat /etc/netplan/
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
version: 2
ethernets:
interface0:
dhcp4: true
match:
interface1:
dhcp4: false
dhcp6: false
- 192.168.1.2/24
- 2001:4800:
match:
mtu: 6666
root@ubuntu:~# ip link show interface1
3: interface1: <BROADCAST,
link/ether 52:54:00:12:34:02 brd ff:ff:ff:ff:ff:ff
# sysctl net.ipv6.
net.ipv6.
root@ubuntu:~# cat /run/systemd/
[Match]
MACAddress=
[Link]
Name=interface1
WakeOnLan=off
MTUBytes=6666
root@ubuntu:~# cat /run/systemd/
[Match]
MACAddress=
Name=interface1
[Network]
LinkLocalAddres
Address=
Address=
IPv6AcceptRA=no
IPv6MTUBytes=5634
# journalctl -o short-precise -b 0 | egrep -i "(MTU|interface1)"
Oct 23 21:28:47.968910 ubuntu kernel: virtio_net virtio3 interface1: renamed from ens6
Oct 23 21:28:50.636014 ubuntu systemd-n...
Ryan Harper (raharper) wrote : | #44 |
The original netplan yaml I was testing was simpler, but also failed so I tried to see if additional settings would make a difference, but it did not.
network:
version: 2
ethernets:
interface0:
dhcp4: true
match:
interface1:
- 192.168.1.2/24
- 2001:4800:
match:
mtu: 6666
Ryan Harper (raharper) wrote : | #45 |
I did some more testing today. I upgraded systemd and netplan.io to disco level, rebooted and tested the MTU settings; disco packages fail as well. I then upgraded to eoan systemd/netplan.io rebooted and the MTU settings are correct.
Ryan Harper (raharper) wrote : | #46 |
In the Eoan version of systemd, I can see in the logs these messages:
Oct 24 18:52:32.753746 ubuntu systemd-
Oct 24 18:52:32.753848 ubuntu systemd-
Oct 24 18:52:32.753884 ubuntu systemd-
Oct 24 18:52:32.753962 ubuntu systemd-
These are not emitted in bionic or disco versions of systemd.
Thanks. Let's put both tasks as Triaged again then, since it's obviously not fixed in disco and bionic.
I don't think this qualifies as a regression though, since the feature was never available before. It's just not finished since the systemd side of this isn't complete.
Changed in systemd (Ubuntu Bionic): | |
status: | Fix Released → Triaged |
Changed in systemd (Ubuntu Disco): | |
status: | New → Triaged |
Dan Streetman (ddstreet) wrote : | #48 |
I looked at this for a few minutes, and it seems strange that it works at all (at boot) since networkd sets the ipv6 mtu before bringing the link up, but the kernel resets the ipv6 mtu to the device mtu on link up. I must be missing something.
On Fri, Oct 25, 2019 at 1:31 PM Dan Streetman <email address hidden>
wrote:
> I looked at this for a few minutes, and it seems strange that it works
> at all (at boot) since networkd sets the ipv6 mtu before bringing the
> link up, but the kernel resets the ipv6 mtu to the device mtu on link
> up. I must be missing something.
>
I'm glad you saw that. I'm seeing this as well on my curtin vmtest
(automated deployment and data collection during first boot).
I have to restart networkd for it to work on the first boot.
Subsequent boots it seems to work fine without a restart of networkd.
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
>
> https:/
>
Balint Reczey (rbalint) wrote : | #50 |
@raharper, do I understand correctly that this occurs only on first boot and is fixed when installing eoan's netplan.io on bionic?
Also a full Disco systemd works or not? (Disco system, Disco netplan.io, Disco systemd)
Ryan Harper (raharper) wrote : | #51 |
@Balint, after further testing, here's where things are:
-----------------
On LXD Containers
-----------------
On Bionic
1) First boot: neither interface mtu, nor ipv6 mtu is applied.
2) Restarting systemd-networkd: neither interface nor ipv6-mtu is applied
3) netplan apply: interface mtu is set correctly, ipv6 mtu is not.
On Disco
1) First boot: neither interface mtu, nor ipv6 mtu is applied.
2) Restarting systemd-networkd: neither interface nor ipv6-mtu is applied
3) netplan apply: both interface and ipv6 MTU are set correctly.
On Eoan
1) First boot: neither interface mtu, nor ipv6 mtu is applied
2) Restarting systemd-networkd: neither interface nor ipv6-mtu is applied
3) netplan apply: both interface and ipv6 MTU are set correctly.
------
On VMs
------
On Bionic
1) First boot: interface MTU is set, ipv6 MTU is not applied.
2) Restarting systemd-networkd: both interface and ipv6 MTU are set correctly
3) netplan apply not needed
4) After reboot, same as (1)
On Disco
1) First boot: interface MTU is set, ipv6 MTU is not applied.
2) Restarting systemd-networkd: both interface and ipv6 MTU are set correctly
3) netplan apply not needed
4) After reboot, same as (1)
On Eoan
1) First boot: interface MTU is set, ipv6 MTU is not applied.
2) Restarting systemd-networkd: both interface and ipv6 MTU are set correctly
3) netplan apply not needed
4) After reboot, same as (1)
Dan Streetman (ddstreet) wrote : | #52 |
@raharper could you give the systemd in this ppa a test:
https:/
also, you're setting the MTUBytes via .link file, but that won't work inside an lxd container as that setting only has any effect during udev processing of interface 'add' uevent, which doesn't happen inside an lxd container because 1) the interface already exists when the container boots up and 2) systemd-
Ryan Harper (raharper) wrote : | #53 |
@Dan,
Ill try the ppa and report back.
cloud-init is not doing anything special here, we render the config and call netplan generate.
If we take cloud-init out of the picture, and just have a file in /etc/netplan it will still fail due to the udev issue you specify. Shouldn't netplan itself handle container-based rendering if [Link] sections when running inside a container?
Dan Streetman (ddstreet) wrote : | #54 |
> cloud-init is not doing anything special here, we render the config and call netplan generate
Sorry, yes I meant that netplan should be putting the MTUBytes inside the .network and not using a .link file.
Balint Reczey (rbalint) wrote : | #55 |
In my test I modified a multipass launched VM's netplan config to:
multipass@
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
ethernets:
ens3:
dhcp4: true
mtu: 1496
match:
version: 2
Also disabled cloud-init overwriting it:
multipass@
network: {config: disabled}
IPv6 MTU is properly set on Eoan after reboot:
multipass@
net.ipv6.
... but not on Disco or Bionic. To be continued...
Balint Reczey (rbalint) wrote : | #56 |
@ddstreet You systemd builds in the PPA fix the issue for me on Bionic and Disco, IPv6 MTU is applied after reboot with the configuration.
Balint Reczey (rbalint) wrote : | #57 |
I have not tested first boot, @raharper could you please test that?
Ryan Harper (raharper) wrote : | #58 |
Testing with @ddstreet's systemd ppa, I can confirm that bionic, disco and eoan correctly set MTU on first boot, no systemd-restart needed.
Dan Streetman (ddstreet) wrote : | #59 |
I opened this upstream
https:/
Changed in systemd (Ubuntu Focal): | |
assignee: | nobody → Dan Streetman (ddstreet) |
status: | Fix Released → In Progress |
Changed in systemd (Ubuntu Eoan): | |
assignee: | nobody → Dan Streetman (ddstreet) |
status: | New → In Progress |
Changed in systemd (Ubuntu Disco): | |
assignee: | nobody → Dan Streetman (ddstreet) |
status: | Triaged → In Progress |
Changed in systemd (Ubuntu Bionic): | |
assignee: | Balint Reczey (rbalint) → Dan Streetman (ddstreet) |
status: | Triaged → In Progress |
Changed in netplan.io (Ubuntu Eoan): | |
status: | New → Fix Released |
tags: | added: bionic ddstreet disco eoan focal systemd |
Dan Streetman (ddstreet) wrote : | #60 |
as disco is EOL next week, marking this won't fix for disco.
Changed in systemd (Ubuntu Disco): | |
status: | In Progress → Won't Fix |
Launchpad Janitor (janitor) wrote : | #61 |
This bug was fixed in the package systemd - 244.1-0ubuntu2
---------------
systemd (244.1-0ubuntu2) focal; urgency=medium
[ Dimitri John Ledkov ]
* shutdown: do not detach autoclear loopback devices
Author: Dimitri John Ledkov
File: debian/
https:/
[ Balint Reczey ]
* Revert upstream commit breaking IPv4 DHCP in LXC containers in 244.1
(LP: #1857123)
File: debian/
https:/
systemd (244.1-0ubuntu1) focal; urgency=medium
* New upstream version 244.1
- network: set ipv6 mtu after link-up or device mtu change (LP: #1671951)
- & other changes
* Refresh patches.
- Dropped changes:
* d/p/lp-1853852-*: fix issues with muliplexed shmat calls (LP: #1853852)
Files:
- debian/
- debian/
https:/
* d/p/lp1671951-
set ipv6 mtu at correct time
* pstore: Don't start systemd-
Usually it is not useful and can also fail making
boot-
File: debian/
https:/
* Revert: network: do not drop foreign config if interface is in initialized state.
This fixes FTBFS with the other network-related reverts.
File: debian/
https:/
systemd (244-3ubuntu5) focal; urgency=medium
[ Dariusz Gadomski ]
* d/p/lp1762391/
d/p/
d/p/
d/p/
d/p/
d/p/
- Restore call to pam_setcred (LP: #1762391)
[ Dan Streetman ]
* d/t/storage: without scsi_debug, skip test (LP: #1847816)
systemd (244-3ubuntu4) focal; urgency=medium
* d/p/lp1671951-
set ipv6 mtu at correct time (LP: #1671951)
* d/p/0001-
d/p/
Changed in systemd (Ubuntu Focal): | |
status: | In Progress → Fix Released |
Hello Ryan, or anyone else affected,
Accepted systemd into eoan-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in systemd (Ubuntu Eoan): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed verification-needed-eoan |
Steve Langasek (vorlon) wrote : | #63 |
Hello Ryan, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in systemd (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
tags: |
added: verification-needed-bionic removed: verification-done-bionic |
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/237-3ubuntu10.34) | #64 |
All autopkgtests for the newly accepted systemd (237-3ubuntu10.34) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:
php7.2/
openssh/
dovecot/
gvfs/1.
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
All autopkgtests for the newly accepted systemd (242-7ubuntu3.3) for eoan have finished running.
The following regressions have been reported in tests triggered by the package:
samba/2:
netplan.
gnome-desktop3/
systemd/
munin/2.
bolt/0.8-4 (armhf)
umockdev/0.13.2-1 (armhf)
openssh/
linux-oem-
multipath-
knot-resolver/
lxc/3.0.4-0ubuntu1 (amd64, ppc64el, i386)
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
Ryan Harper (raharper) wrote : | #66 |
Ryan Harper (raharper) wrote : | #67 |
Curtin vmtest verification for bionic using systemd from -proposed has run successfully.
(neipa) ipv6_mtu % egrep "237-3ubuntu10.34" output/
[ 126.923480] cloud-init[1176]: Get:10 http://
[ 126.999639] cloud-init[1176]: Get:11 http://
[ 127.012854] cloud-init[1176]: Get:12 http://
[ 127.018126] cloud-init[1176]: Get:13 http://
[ 127.112992] cloud-init[1176]: Get:14 http://
[ 127.230646] cloud-init[1176]: Get:15 http://
[ 127.237607] cloud-init[1176]: Get:16 http://
[ 130.615970] cloud-init[1176]: Preparing to unpack .../libsystemd0
[ 130.619809] cloud-init[1176]: Unpacking libsystemd0:amd64 (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 130.671345] cloud-init[1176]: Setting up libsystemd0:amd64 (237-3ubuntu10.34) ...
[ 130.734901] cloud-init[1176]: Preparing to unpack .../libnss-
[ 130.738718] cloud-init[1176]: Unpacking libnss-
[ 130.775590] cloud-init[1176]: Preparing to unpack .../libpam-
[ 130.780829] cloud-init[1176]: Unpacking libpam-
[ 130.817036] cloud-init[1176]: Preparing to unpack .../systemd_
[ 130.938621] cloud-init[1176]: Unpacking systemd (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 131.534337] cloud-init[1176]: Preparing to unpack .../udev_
[ 131.631496] cloud-init[1176]: Unpacking udev (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 131.877032] cloud-init[1176]: Preparing to unpack .../libudev1_
[ 131.880841] cloud-init[1176]: Unpacking libudev1:amd64 (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 131.921311] cloud-init[1176]: Setting up libudev1:amd64 (237-3ubuntu10.34) ...
[ 131.923955] cloud-init[1176]: Setting up systemd (237-3ubuntu10.34) ...
[ 132.376367] cloud-init[1176]: Preparing to unpack .../systemd-
[ 132.379899] cloud-init[1176]: Unpacking systemd-sysv (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 135.341098] cloud-init[1176]: Setting up libnss-
[ 135.355290] cloud-init[1176]: Setting up systemd-sysv (237-3ubuntu10.34) ...
[ 135.897825] cloud-init[1176]: Setting up udev (237-3ubuntu10.34) ...
[ 136.901473] cloud-init[1176]: Setting up libpam-
[ 141.343998]...
Ryan Harper (raharper) wrote : | #68 |
Curtin vmtest verification for eoan using systemd from -proposed has run successfully.
(neipa) ipv6_mtu % egrep "242-7ubuntu3.3" output/
[ 136.520219] cloud-init[765]: Get:12 http://
[ 136.527400] cloud-init[765]: Get:13 http://
[ 136.693312] cloud-init[765]: Get:14 http://
[ 136.701002] cloud-init[765]: Get:15 http://
[ 136.722467] cloud-init[765]: Get:17 http://
[ 136.743657] cloud-init[765]: Get:19 http://
[ 137.138458] cloud-init[765]: Get:20 http://
[ 142.884502] cloud-init[765]: Preparing to unpack .../libnss-
[ 142.887869] cloud-init[765]: Unpacking libnss-
[ 142.924747] cloud-init[765]: Preparing to unpack .../udev_
[ 142.962745] cloud-init[765]: Unpacking udev (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 143.165029] cloud-init[765]: Preparing to unpack .../libudev1_
[ 143.168604] cloud-init[765]: Unpacking libudev1:amd64 (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 143.206268] cloud-init[765]: Setting up libudev1:amd64 (242-7ubuntu3.3) ...
[ 143.272647] cloud-init[765]: Preparing to unpack .../systemd-
[ 143.275554] cloud-init[765]: Unpacking systemd-sysv (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 143.594537] cloud-init[765]: Preparing to unpack .../libpam-
[ 143.599803] cloud-init[765]: Unpacking libpam-
[ 143.680250] cloud-init[765]: Preparing to unpack .../systemd_
[ 143.785319] cloud-init[765]: Unpacking systemd (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 144.362457] cloud-init[765]: Preparing to unpack .../libsystemd0
[ 144.366022] cloud-init[765]: Unpacking libsystemd0:amd64 (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 144.423950] cloud-init[765]: Setting up libsystemd0:amd64 (242-7ubuntu3.3) ...
[ 149.340746] cloud-init[765]: Setting up udev (242-7ubuntu3.3) ...
[ 152.700118] cloud-init[765]: Setting up systemd (242-7ubuntu3.3) ...
[ 154.478301] cloud-init[765]: Setting up systemd-sysv (242-7ubuntu3.3) ...
[ 154.481899] cloud-init[765]: Setting up libnss-
[ 154.485400] cloud-init[765]: Setting up libpam-
[ 198.012728] cloud-init[765]: systemd is already the newest version (242-7ubuntu3.3).
(neipa) ipv6_mtu % cat output/
tags: |
added: verification-done-eoan removed: verification-needed-eoan |
tags: |
added: verification-needed-eoan removed: verification-done-eoan |
Launchpad Janitor (janitor) wrote : | #69 |
This bug was fixed in the package systemd - 237-3ubuntu10.38
---------------
systemd (237-3ubuntu10.38) bionic-security; urgency=medium
* SECURITY UPDATE: local privilege escalation via DynamicUser
- debian/
seccomp_
in src/shared/
- debian/
restrict_
- debian/
new unit setting RestrictSUIDSGID= in src/core/
src/
src/
- debian/
RestrictS
- debian/
most of our long-running daemons in units/systemd-
- debian/
restriction for DynamicUser=yes service in man/systemd.
src/
- debian/
src/
- CVE-2019-3843
- CVE-2019-3844
* SECURITY UPDATE: memory leak in button_open
- debian/
src/
- CVE-2019-20386
* SECURITY UPDATE: heap use-after-free with async polkit queries
- debian/
re-validate action/details in src/shared/
- debian/
incoming messages in src/libsystemd/
src/
- debian/
re-resolve callback/userdata instead of caching it in
src/
- debian/
src/
src/
- debian/
- CVE-2020-1712
* This package does _not_ contain the changes from 237-3ubuntu10.34 in
bionic-
-- Marc Deslauriers <email address hidden> Tue, 04 Feb 2020 20:07:56 -0500
Changed in systemd (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Dimitri John Ledkov (xnox) wrote : | #70 |
This SRU needs to be reuploaded, due to security update that trumped this in progress SRU.
Changed in systemd (Ubuntu Eoan): | |
status: | Fix Committed → In Progress |
Hello Ryan, or anyone else affected,
Accepted systemd into eoan-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in systemd (Ubuntu Eoan): | |
status: | In Progress → Fix Committed |
Changed in systemd (Ubuntu Bionic): | |
status: | Fix Released → Fix Committed |
Steve Langasek (vorlon) wrote : | #73 |
Hello Ryan, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/237-3ubuntu10.39) | #74 |
All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:
php7.2/
gvfs/1.
lxc/3.0.
systemd/
netplan.
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
All autopkgtests for the newly accepted systemd (242-7ubuntu3.7) for eoan have finished running.
The following regressions have been reported in tests triggered by the package:
remctl/3.15-1build2 (armhf)
systemd-
netplan.
systemd/
sks/unknown (armhf)
munin/2.
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
Ryan Harper (raharper) wrote : | #76 |
Verified Eoan systemd 242-7ubuntu3.7 correctly sets IPv6 MTU
Verified Bionic systemd 237-3ubuntu10.39 correctly sets IPv6 MTU
tags: |
added: verification-done verification-done-bionic verification-done-eoan removed: verification-needed verification-needed-bionic verification-needed-eoan |
Launchpad Janitor (janitor) wrote : | #77 |
This bug was fixed in the package systemd - 242-7ubuntu3.7
---------------
systemd (242-7ubuntu3.7) eoan; urgency=medium
[ Dariusz Gadomski ]
* d/p/lp1762391/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
- Restore call to pam_setcred (LP: #1762391)
* d/p/lp1846232/
d/p/
- do not always bump MTU with additional 4bytes (LP: #1846232)
* d/p/lp1671951-
- set ipv6 mtu at correct time (LP: #1671951)
* d/p/lp1845909/
d/p/
d/p/
d/p/
d/p/
- drop foreign config and raise interface after setting genmode
(LP: #1845909)
* d/t/storage: without scsi_debug, skip test (LP: #1847816)
-- Dan Streetman <email address hidden> Thu, 06 Feb 2020 09:45:57 -0500
Changed in systemd (Ubuntu Eoan): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #78 |
This bug was fixed in the package systemd - 237-3ubuntu10.39
---------------
systemd (237-3ubuntu10.39) bionic; urgency=medium
[ Dariusz Gadomski ]
* d/p/lp1762391/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
- Restore call to pam_setcred (LP: #1762391)
[ Ioanna Alifieraki ]
* d/p/lp1860548/
d/p/
- use snprintf instead of xsprintf (LP: #1860548)
[ Dan Streetman ]
* d/p/lp1833193-
- Update lft when static addr was cfg by dhcp (LP: #1833193)
* d/p/lp1849261/
d/p/
- Only trigger OnFailure= if Restart= is not in effect (LP: #1849261)
* d/p/lp1671951-
- set ipv6 mtu at correct time (LP: #1671951)
* d/p/lp1845909/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
- if LinkLocalAddres
* d/p/lp1859862-
- enable ipv6 when needed (LP: #1859862)
* d/p/lp1836695-
- (re)add static routes after getting dhcp4 addr (LP: #1836695)
* d/t/storage:
- fix buggy test (LP: #1831459)
- without scsi_debug, skip test (LP: #1847816)
-- Dan Streetman <email address hidden> Thu, 06 Feb 2020 10:00:49 -0500
Changed in systemd (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Changed in cloud-init (Ubuntu Disco): | |
status: | New → Won't Fix |
Dan Watkins (oddbloke) wrote : | #79 |
I'm trying to understand if there is any work still required on this bug for cloud-init. I've tested two network configurations (in lxd containers). The first:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 1337
As this is just a passthrough to netplan, this works as expected: /proc/sys/
The second:
version: 1
config:
- type: physical
name: eth0
mtu: 1337
subnets:
- type: dhcp
- type: dhcp6
Given that we don't have a separate setting for the IPv6-specific MTU, this seems to work as I expect: both /proc/sys/
Thoughts, anyone?
I've a build of this fix here:
https:/ /launchpad. net/~raharper/ +archive/ ubuntu/ cloud-init- dev (systemd= 232-19ubuntu3~ fixbuild1)
I've tested this minimally in a Zesty VM and it's successfully applies an IPV6MTU in addition to the device mtu (if that's also included).