networkd should allow configuring IPV6 MTU

[Ryan Harper]

= 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.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 6000

[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://github.com/systemd/systemd/pull/1533

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.

[Ryan Harper (raharper)]

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

[Ubuntu Foundations Team Bug Bot (crichton)]

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

[Dimitri John Ledkov (xnox)]

Please submit this as a pullrequest upstream.

[Ryan Harper (raharper)]

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

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-lowest/highest common denominator value for MTU?

[Ryan Harper (raharper)]

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/net/<interface>/mtu
ipv6: /proc/sys/net/ipv6/conf/<interface>/mtu

Would it not be sufficient to set the appropriatly-lowest/highest common
> 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://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/
> 1671951/+subscriptions
>

[Nish Aravamudan (nacc)]

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
                allow configuring IPV6 MTU" [Medium,New]
                https://launchpad.net/bugs/1671951
11:07 < rharper> nacc: it was, but not sure of the status now; the debdiff
                 likely needs refreshed against systemd in artful; I'm not
                 sure of xnox or anyone else attempted to re-work the issue
                 upstream;
11:08 < nacc> rharper: ok, can i unsub sponsors for now?
11:08 < rharper> sure

[Ryan Harper (raharper)]

I've just seen that upstream systemd v239 claims to support IPV6MtuBytes

https://lwn.net/Articles/758128/

* 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)]

The v239 merge for cosmic is in progress at the moment. There are a few regressions that need to be worked around.

[Dimitri John Ledkov (xnox)]

This is now in cosmic.

[Dimitri John Ledkov (xnox)]

Do we need this in bionic?

[Ryan Harper (raharper)]

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://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+subscriptions

[Scott Moser (smoser)]

Hm...

Our tests show that this is not fixed in cosmic or bionic.

https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel-amd64/533/console
shows curtin's vmtest failing. Partial output shows:

======================================================================
ERROR: test_ipv6_mtu_smaller_than_ipv4_v6_iface_first (vmtests.test_network_mtu.CosmicTestNetworkMtu)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/jenkins/slaves/torkoal/workspace/curtin-vmtest-devel-amd64/curtin-533/tests/vmtests/__init__.py", line 468, in wrapper
    raise RuntimeError(msg)
RuntimeError: skip_by_date(CosmicTestNetworkMtu.test_ipv6_mtu_smaller_than_ipv4_v6_iface_first) LP: #1671951 fixby=2018-09-26 removeby=2018-10-17: (PAST_FIXBY) Failed: 1480 != 1500
-------------------- >> begin captured stdout << ---------------------
iface=interface4 subnets=[{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static', 'mtu': 1480}, {'address': '192.168.5.2/24', 'type': 'static', 'mtu': 1501}]
subnet:{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static', 'mtu': 1480}
mtu_data:{'device': 1500, 'ipv6': 1500}
subnet_mtu=1480 ipv6_mtu=1500

--------------------- >> end captured stdout << ----------------------

[Ryan Harper (raharper)]

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://jenkins.ubuntu.com/server/job/curtin-vmtest-devel-amd64/533/console
> shows curtin's vmtest failing. Partial output shows:
>
> ======================================================================
> ERROR: test_ipv6_mtu_smaller_than_ipv4_v6_iface_first (vmtests.test_network_mtu.CosmicTestNetworkMtu)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/var/lib/jenkins/slaves/torkoal/workspace/curtin-vmtest-devel-amd64/curtin-533/tests/vmtests/__init__.py", line 468, in wrapper
> raise RuntimeError(msg)
> RuntimeError: skip_by_date(CosmicTestNetworkMtu.test_ipv6_mtu_smaller_than_ipv4_v6_iface_first) LP: #1671951 fixby=2018-09-26 removeby=2018-10-17: (PAST_FIXBY) Failed: 1480 != 1500
> -------------------- >> begin captured stdout << ---------------------
> iface=interface4 subnets=[{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static', 'mtu': 1480}, {'address': '192.168.5.2/24', 'type': 'static', 'mtu': 1501}]
> subnet:{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static', 'mtu': 1480}
> mtu_data:{'device': 1500, 'ipv6': 1500}
> subnet_mtu=1480 ipv6_mtu=1500
>
> --------------------- >> end captured stdout << ----------------------
>
>
> ** Attachment added: "console log of curtin vmtest amd64 533"
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+attachment/5194078/+files/curtin-vmtest-devel-amd64-533-console.log
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+subscriptions

[Ryan Harper (raharper)]

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://trello.com/c/nIjLIRSG/6-support-ipv6-mtu-bytes-configuration

[Łukasz Zemczak (sil2100)]

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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.

[Łukasz Zemczak (sil2100)]

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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

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]
LinkLocalAddressing=ipv6
Address=10.10.10.10/24
IPv6MTUBytes=1470

This results in: /proc/sys/net/ipv6/conf/<iface>/mtu having a value of 1500

if I disable LinkLocalAddressing like so:

[Network]
LinkLocalAddressing=no
Address=10.10.10.10/24
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-networkd[593]: eth2: Cannot set IPv6 MTU for interface: Invalid argument

which is the same message you get if you: echo "1520" > /proc/sys/net/ipv6/conf/<iface>/mtu:

# echo 1520 > /proc/sys/net/ipv6/conf/eth2/mtu
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)]

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.

[Ryan Harper (raharper)]

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://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions

[Dimitri John Ledkov (xnox)]

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/net/ens3/mtu
1800
$ cat /proc/sys/net/ipv6/conf/ens3/mtu
1600

Thus one can set a different from the device, ipv6-specific mtu.

[Ryan Harper (raharper)]

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

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

This was done inside a VM.
This was all done in a single /etc/systemd/network/10-netplan-ens3.network file. Note that [Link] is a valid section in a .network file. Note that i took netplan generated .network file as a base, and then modified it with above shown options. Disabled netplan. Rebooted.

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.

[Launchpad Janitor (janitor)]

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

[Brian Murray (brian-murray)]

Hello Ryan, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.98-0ubuntu1~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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

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-test-ipv6-mtu:~# apt-cache policy netplan.io
netplan.io:
  Installed: 0.98-0ubuntu1~18.04.1
  Candidate: 0.98-0ubuntu1~18.04.1
  Version table:
 *** 0.98-0ubuntu1~18.04.1 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.97-0ubuntu1~18.04.1 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
     0.40.1~18.04.4 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     0.36.1 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

root@b-test-ipv6-mtu:~# cat /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        ens3:
            dhcp4: true
            match:
                macaddress: fa:16:3e:4d:3c:6a
            set-name: ens3
            ipv6-mtu: 6000

root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.link
[Match]
MACAddress=fa:16:3e:4d:3c:6a

[Link]
Name=ens3
WakeOnLan=off
root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.network
[Match]
MACAddress=fa:16:3e:4d:3c:6a
Name=ens3

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6
IPv6MTUBytes=6000

[DHCP]
RouteMetric=100
UseMTU=true

~# cat /sys/class/net/ens3/mtu
8958
~# sysctl net.ipv6.conf.ens3.mtu
net.ipv6.conf.ens3.mtu = 8958

[Dimitri John Ledkov (xnox)]

Followup on my comments, are any changes required in networkd to support this in bionic?

[Ryan Harper (raharper)]

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://nova.clouds.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     237-3ubuntu10.25 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
     237-3ubuntu10.19 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     237-3ubuntu10 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

[Dimitri John Ledkov (xnox)]

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-test-ipv6-mtu:~# apt-cache policy netplan.io
> netplan.io:
> Installed: 0.98-0ubuntu1~18.04.1
> Candidate: 0.98-0ubuntu1~18.04.1
> Version table:
> *** 0.98-0ubuntu1~18.04.1 500
> 500 http://nova.clouds.archive.ubuntu.com/ubuntu
> bionic-proposed/main amd64 Packages
> 100 /var/lib/dpkg/status
> 0.97-0ubuntu1~18.04.1 500
> 500 http://nova.clouds.archive.ubuntu.com/ubuntu
> bionic-updates/main amd64 Packages
> 0.40.1~18.04.4 500
> 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
> Packages
> 0.36.1 500
> 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main
> amd64 Packages
>
> root@b-test-ipv6-mtu:~# cat /etc/netplan/50-cloud-init.yaml
> network:
> version: 2
> ethernets:
> ens3:
> dhcp4: true
> match:
> macaddress: fa:16:3e:4d:3c:6a
> set-name: ens3
> ipv6-mtu: 6000
>
> root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.link
> [Match]
> MACAddress=fa:16:3e:4d:3c:6a
>
> [Link]
> Name=ens3
> WakeOnLan=off
> root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.network
> [Match]
> MACAddress=fa:16:3e:4d:3c:6a
> Name=ens3
>
> [Network]
> DHCP=ipv4
> LinkLocalAddressing=ipv6
> IPv6MTUBytes=6000
>
> [DHCP]
> RouteMetric=100
> UseMTU=true
>
>
> ~# cat /sys/class/net/ens3/mtu
> 8958
> ~# sysctl net.ipv6.conf.ens3.mtu
> net.ipv6.conf.ens3.mtu = 8958
>
> --
> You received this bug notification because you are subscribed to systemd
> in Ubuntu.
> Matching subscriptions: systemd
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions
>

[Ryan Harper (raharper)]

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:
            addresses: [10.5.0.16/16]
            gateway4: 10.5.0.1
            dhcp4: false
            match:
                macaddress: fa:16:3e:c9:1e:fb
            mtu: 8958
            ipv6-mtu: 8960
            set-name: ens3
            nameservers:
                addresses: [10.5.0.2]
                search: [project.serverstack]

It works. Now on bionic-proposed, it does not.

Aug 28 16:59:56.659125 b-test-ipv6-mtu systemd-networkd[1149]: /run/systemd/network/10-netplan-ens3.network:11: Unknown lvalue 'IPv6MTUBytes' in section 'Network'

So, looks like bionic systemd is missing something.

[Ryan Harper (raharper)]

err, on Eoan, I used ipv6-mtu 6000.

[Steve Langasek (vorlon)]

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.30 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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.

[Steve Langasek (vorlon)]

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.31 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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

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.36.1-0ubuntu1.3.3 (ppc64el, amd64)
netplan.io/0.97-0ubuntu1~18.04.1 (amd64)
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 StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Mathieu Trudel-Lapierre (cyphermox)]

Verification-done on bionic:

ubuntu@ip-172-30-0-140:/run/systemd/network$ lsb_release -cs
bionic
ubuntu@ip-172-30-0-140:/run/systemd/network$ dpkg -l netplan.io | grep ii
ii netplan.io 0.98-0ubuntu1~18.04.1 amd64 YAML network configuration abstraction for various backends
ubuntu@ip-172-30-0-140:/run/systemd/network$ dpkg -l systemd | grep ii
ii systemd 237-3ubuntu10.31 amd64 system and service manager
ubuntu@ip-172-30-0-140:/run/systemd/network$ cat /etc/netplan/50-cloud-init.yaml
# 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/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: true
            match:
                macaddress: 06:e0:25:2e:08:ef
            set-name: eth0
            ipv6-mtu: 5634
            mtu: 6666
            dhcp6: true
            dhcp4-overrides:
                use-mtu: false
            dhcp6-overrides:
                use-mtu: false
ubuntu@ip-172-30-0-140:/run/systemd/network$ sudo netplan apply
ubuntu@ip-172-30-0-140:/run/systemd/network$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 eth0 ether routable configured

2 links listed.
ubuntu@ip-172-30-0-140:/run/systemd/network$ sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 5634
ubuntu@ip-172-30-0-140:/run/systemd/network$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6666 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 06:e0:25:2e:08:ef brd ff:ff:ff:ff:ff:ff
ubuntu@ip-172-30-0-140:/run/systemd/network$

[Mathieu Trudel-Lapierre (cyphermox)]

Verification-done on disco:

ubuntu@ip-172-30-0-243:~$ lsb_release -cs
disco
ubuntu@ip-172-30-0-243:~$ dpkg -l netplan.io systemd | grep ii
ii netplan.io 0.98-0ubuntu1~19.04.1 amd64 YAML network configuration abstraction for various backends
ii systemd 240-6ubuntu5.7 amd64 system and service manager
ubuntu@ip-172-30-0-243:~$ sudo netplan apply
ubuntu@ip-172-30-0-243:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6666 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 06:92:5b:c9:b5:3d brd ff:ff:ff:ff:ff:ff
ubuntu@ip-172-30-0-243:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 eth0 ether routable configured

2 links listed.
ubuntu@ip-172-30-0-243:~$ sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 5634
ubuntu@ip-172-30-0-243:~$ cat /etc/netplan/50-cloud-init.yaml
# 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/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: true
            match:
                macaddress: 06:92:5b:c9:b5:3d
            set-name: eth0
            ipv6-mtu: 5634
            mtu: 6666
            dhcp6: true
            dhcp4-overrides:
                use-mtu: false
            dhcp6-overrides:
                use-mtu: false

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.98-0ubuntu1~19.04.1

---------------
netplan.io (0.98-0ubuntu1~19.04.1) disco; urgency=medium

  * Backport netplan.io 0.98 to 19.04. (LP: #1840832)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 26 Aug 2019 16:41:36 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.98-0ubuntu1~18.04.1

---------------
netplan.io (0.98-0ubuntu1~18.04.1) bionic; urgency=medium

  * Backport netplan.io 0.98 to 18.04. (LP: #1840832)
  * Keep patches specific to 18.04 support:
    - disable-networkd-tunnels-ipip-gre.patch: disable tests for unsupported
      tunnel types (ipip and gre) in the 18.04 version of systemd-networkd.
  * Drop debian/patches/glib_changes.patch: No longer necessary, changes were
    made upstream to better account for the changes in HashTable.
  * debian/netplan.io.install: add /usr/share/dbus-1

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

[Brian Murray (brian-murray)]

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

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/UBUNTU-units-disable-journald-watchdog.patch
    - units: Disable journald Watchdog (LP: #1773148)
  * d/p/cryptsetup-add-support-for-sector-size-option-8881.patch
    - cryptsetup: add support for sector-size= option (LP: #1776626)
  * d/p/systemctl-correctly-proceed-to-immediate-shutdown-if-sche.patch
    - systemctl: correctly proceed to immediate shutdown if scheduling fails
      (LP: #1670291)
  * d/p/networkd-add-support-to-configure-IPv6-MTU-8664.patch
    - networkd: add support to set IPv6MTUBytes (LP: #1671951)

 -- Balint Reczey <email address hidden> Mon, 30 Sep 2019 17:23:17 +0200

[Ryan Harper (raharper)]

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.info
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~18.04.1
  Candidate: 0.98-0ubuntu1~18.04.1
  Version table:
 *** 0.98-0ubuntu1~18.04.1 500
        500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.40.1~18.04.4 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     0.36.1 500
        500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
root@ubuntu:~# apt-cache policy systemd
systemd:
  Installed: 237-3ubuntu10.31
  Candidate: 237-3ubuntu10.31
  Version table:
 *** 237-3ubuntu10.31 500
        500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     237-3ubuntu10.29 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     237-3ubuntu10 500
        500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

root@ubuntu:~# cat /etc/netplan/50-cloud-init.yaml
# 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/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        interface0:
            dhcp4: true
            match:
                macaddress: '52:54:00:12:34:00'
            set-name: interface0
        interface1:
            dhcp4: false
            dhcp6: false
            addresses:
            - 192.168.1.2/24
            - 2001:4800:78ff:1b:be76:4eff:fe06:1000/64
            match:
                macaddress: '52:54:00:12:34:02'
            mtu: 6666
            ipv6-mtu: 5634
            set-name: interface1
            accept-ra: false
            dhcp6-overrides:
               use-mtu: false
            link-local: [ ]

root@ubuntu:~# ip link show interface1
3: interface1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6666 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:02 brd ff:ff:ff:ff:ff:ff
# sysctl net.ipv6.conf.interface1.mtu
net.ipv6.conf.interface1.mtu = 6666

root@ubuntu:~# cat /run/systemd/network/10-netplan-interface1.link
[Match]
MACAddress=52:54:00:12:34:02

[Link]
Name=interface1
WakeOnLan=off
MTUBytes=6666
root@ubuntu:~# cat /run/systemd/network/10-netplan-interface1.network
[Match]
MACAddress=52:54:00:12:34:02
Name=interface1

[Network]
LinkLocalAddressing=no
Address=192.168.1.2/24
Address=2001:4800:78ff:1b:be76:4eff:fe06:1000/64
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)]

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:
                macaddress: '52:54:00:12:34:00'
            set-name: interface0
        interface1:
            addresses:
            - 192.168.1.2/24
            - 2001:4800:78ff:1b:be76:4eff:fe06:1000/64
            match:
                macaddress: '52:54:00:12:34:02'
            mtu: 6666
            ipv6-mtu: 5634
            set-name: interface1

[Ryan Harper (raharper)]

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

In the Eoan version of systemd, I can see in the logs these messages:

Oct 24 18:52:32.753746 ubuntu systemd-networkd[1167]: Setting '/proc/sys/net/ipv6/conf/interface1/proxy_ndp' to '0'
Oct 24 18:52:32.753848 ubuntu systemd-networkd[1167]: Setting '/proc/sys/net/ipv6/conf/interface1/use_tempaddr' to '0'
Oct 24 18:52:32.753884 ubuntu systemd-networkd[1167]: Setting '/proc/sys/net/ipv6/conf/interface1/accept_ra' to '0'
Oct 24 18:52:32.753962 ubuntu systemd-networkd[1167]: Setting '/proc/sys/net/ipv6/conf/interface1/mtu' to '5634'

These are not emitted in bionic or disco versions of systemd.

[Mathieu Trudel-Lapierre (cyphermox)]

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.

[Dan Streetman (ddstreet)]

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.

[Ryan Harper (raharper)]

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://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions
>

[Balint Reczey (rbalint)]

@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)]

@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)]

@raharper could you give the systemd in this ppa a test:
https://launchpad.net/~ddstreet/+archive/ubuntu/systemd

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-udev-trigger.service has no effect (unlike bare metal systems or vms) because unprivileged containers can't force uevent generation by writing to sysfs uevent nodes. Instead try adding a [Link] section to the .network file with the MTUBytes; that will get applied every time networkd starts.

[Ryan Harper (raharper)]

@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)]

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

In my test I modified a multipass launched VM's netplan config to:

multipass@safe-hornet:~$ cat /etc/netplan/50-cloud-init.yaml
# 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/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        ens3:
            dhcp4: true
            mtu: 1496
            match:
                macaddress: 52:54:00:4c:5b:ac
            set-name: ens3
            dhcp4-overrides:
                    use-mtu: false
            dhcp6-overrides:
                    use-mtu: false
            ipv6-mtu: 1284
    version: 2

Also disabled cloud-init overwriting it:

multipass@safe-hornet:~$ cat /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
network: {config: disabled}

IPv6 MTU is properly set on Eoan after reboot:

multipass@safe-hornet:~$ sysctl net.ipv6.conf.ens3.mtu
net.ipv6.conf.ens3.mtu = 1284

... but not on Disco or Bionic. To be continued...

[Balint Reczey (rbalint)]

@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)]

I have not tested first boot, @raharper could you please test that?

[Ryan Harper (raharper)]

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

I opened this upstream
https://github.com/systemd/systemd/pull/13915

[Dan Streetman (ddstreet)]

as disco is EOL next week, marking this won't fix for disco.

[Launchpad Janitor (janitor)]

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/patches/shutdown-do-not-detach-autoclear-loopback-devices.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=3978d34b59e98cdd01836c41a10442967636b8fc

  [ Balint Reczey ]
  * Revert upstream commit breaking IPv4 DHCP in LXC containers in 244.1
    (LP: #1857123)
    File: debian/patches/Revert-network-if-sys-is-rw-then-udev-should-be-around.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=39c12f8e736afd1b7bdeb13ff6bccaea85020873

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/patches/lp-1853852-seccomp-fix-multiplexed-system-calls.patch
        - debian/patches/lp-1853852-seccomp-mmap-test-results-depend-on-kernel-libseccom.patch
        https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=382271662c60c339b0a404c7a1772fe5670516ef
      * d/p/lp1671951-network-set-ipv6-mtu-after-link-up-or-device-mtu-cha.patch:
        set ipv6 mtu at correct time
  * pstore: Don't start systemd-pstore.service in containers.
    Usually it is not useful and can also fail making
    boot-and-services autopkgtest fail. (LP: #1856729)
    File: debian/patches/pstore-Don-t-start-systemd-pstore.service-in-containers.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=28b5a03769cbed9d3170ebac38508b867530a2d6
  * Revert: network: do not drop foreign config if interface is in initialized state.
    This fixes FTBFS with the other network-related reverts.
    File: debian/patches/Revert-network-do-not-drop-foreign-config-if-interface-is.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=22a9fa3bb03ba2a629926af39ea7df81fe33c9b8

systemd (244-3ubuntu5) focal; urgency=medium

  [ Dariusz Gadomski ]
  * d/p/lp1762391/0001-user-util-Add-helper-functions-for-gid-lists-operati.patch,
    d/p/lp1762391/0002-execute-Restore-call-to-pam_setcred.patch,
    d/p/lp1762391/0003-execute-Detect-groups-added-by-PAM-and-merge-them-wi.patch,
    d/p/lp1762391/0004-test-Add-tests-for-gid-list-ops.patch,
    d/p/lp1762391/0005-execute-add-const-to-array-parameters-where-possible.patch,
    d/p/lp1762391/0006-execute-allow-pam_setcred-to-fail-ignore-errors.patch:
    - 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-network-set-ipv6-mtu-after-link-up-or-device-mtu-cha.patch:
    set ipv6 mtu at correct time (LP: #1671951)
  * d/p/0001-network-rename-linux_configure_after_setting_mtu-to-linux.patch,
    d/p/0002-network-add-link-setting_genmode-flag.patc...

[Steve Langasek (vorlon)]

Hello Ryan, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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.

[Steve Langasek (vorlon)]

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.34 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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

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/7.2.24-0ubuntu0.18.04.2 (armhf)
openssh/1:7.6p1-4ubuntu0.3 (arm64, armhf, ppc64el, amd64, s390x, i386)
dovecot/1:2.2.33.2-1ubuntu4.5 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

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:4.10.7+dfsg-0ubuntu2.4 (armhf)
netplan.io/0.98-0ubuntu1 (amd64, ppc64el)
gnome-desktop3/3.34.2-2ubuntu1~19.10.1 (armhf)
systemd/242-7ubuntu3.3 (ppc64el, arm64)
munin/2.0.49-3ubuntu1 (armhf)
bolt/0.8-4 (armhf)
umockdev/0.13.2-1 (armhf)
openssh/1:8.0p1-6build1 (amd64, ppc64el, i386, s390x, arm64, armhf)
linux-oem-osp1/5.0.0-1037.42 (amd64)
multipath-tools/unknown (armhf)
knot-resolver/3.2.1-3 (amd64, ppc64el)
lxc/3.0.4-0ubuntu1 (amd64, ppc64el, i386)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ryan Harper (raharper)]

Curtin vmtest verification for bionic using systemd from -proposed has run successfully.

(neipa) ipv6_mtu % egrep "237-3ubuntu10.34" output/BionicTestNetworkMtu/logs/install-serial.log
[ 126.923480] cloud-init[1176]: Get:10 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 libsystemd0 amd64 237-3ubuntu10.34 [206 kB]
[ 126.999639] cloud-init[1176]: Get:11 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 libnss-systemd amd64 237-3ubuntu10.34 [104 kB]
[ 127.012854] cloud-init[1176]: Get:12 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 libpam-systemd amd64 237-3ubuntu10.34 [107 kB]
[ 127.018126] cloud-init[1176]: Get:13 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 systemd amd64 237-3ubuntu10.34 [2910 kB]
[ 127.112992] cloud-init[1176]: Get:14 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 udev amd64 237-3ubuntu10.34 [1101 kB]
[ 127.230646] cloud-init[1176]: Get:15 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 libudev1 amd64 237-3ubuntu10.34 [55.4 kB]
[ 127.237607] cloud-init[1176]: Get:16 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 systemd-sysv amd64 237-3ubuntu10.34 [13.2 kB]
[ 130.615970] cloud-init[1176]: Preparing to unpack .../libsystemd0_237-3ubuntu10.34_amd64.deb ...
[ 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-systemd_237-3ubuntu10.34_amd64.deb ...
[ 130.738718] cloud-init[1176]: Unpacking libnss-systemd:amd64 (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 130.775590] cloud-init[1176]: Preparing to unpack .../libpam-systemd_237-3ubuntu10.34_amd64.deb ...
[ 130.780829] cloud-init[1176]: Unpacking libpam-systemd:amd64 (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 130.817036] cloud-init[1176]: Preparing to unpack .../systemd_237-3ubuntu10.34_amd64.deb ...
[ 130.938621] cloud-init[1176]: Unpacking systemd (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 131.534337] cloud-init[1176]: Preparing to unpack .../udev_237-3ubuntu10.34_amd64.deb ...
[ 131.631496] cloud-init[1176]: Unpacking udev (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 131.877032] cloud-init[1176]: Preparing to unpack .../libudev1_237-3ubuntu10.34_amd64.deb ...
[ 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-sysv_237-3ubuntu10.34_amd64.deb ...
[ 132.379899] cloud-init[1176]: Unpacking systemd-sysv (237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 135.341098] cloud-init[1176]: Setting up libnss-systemd:amd64 (237-3ubuntu10.34) ...
[ 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-systemd:amd64 (237-3ubuntu10.34) ...
[ 141.343998]...

[Ryan Harper (raharper)]

Curtin vmtest verification for eoan using systemd from -proposed has run successfully.

(neipa) ipv6_mtu % egrep "242-7ubuntu3.3" output/EoanTestNetworkMtu/logs/install-serial.log
[ 136.520219] cloud-init[765]: Get:12 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libnss-systemd amd64 242-7ubuntu3.3 [126 kB]
[ 136.527400] cloud-init[765]: Get:13 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 udev amd64 242-7ubuntu3.3 [1202 kB]
[ 136.693312] cloud-init[765]: Get:14 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libudev1 amd64 242-7ubuntu3.3 [76.9 kB]
[ 136.701002] cloud-init[765]: Get:15 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 systemd-sysv amd64 242-7ubuntu3.3 [9360 B]
[ 136.722467] cloud-init[765]: Get:17 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libpam-systemd amd64 242-7ubuntu3.3 [130 kB]
[ 136.743657] cloud-init[765]: Get:19 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 systemd amd64 242-7ubuntu3.3 [3440 kB]
[ 137.138458] cloud-init[765]: Get:20 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libsystemd0 amd64 242-7ubuntu3.3 [262 kB]
[ 142.884502] cloud-init[765]: Preparing to unpack .../libnss-systemd_242-7ubuntu3.3_amd64.deb ...
[ 142.887869] cloud-init[765]: Unpacking libnss-systemd:amd64 (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 142.924747] cloud-init[765]: Preparing to unpack .../udev_242-7ubuntu3.3_amd64.deb ...
[ 142.962745] cloud-init[765]: Unpacking udev (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 143.165029] cloud-init[765]: Preparing to unpack .../libudev1_242-7ubuntu3.3_amd64.deb ...
[ 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-sysv_242-7ubuntu3.3_amd64.deb ...
[ 143.275554] cloud-init[765]: Unpacking systemd-sysv (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 143.594537] cloud-init[765]: Preparing to unpack .../libpam-systemd_242-7ubuntu3.3_amd64.deb ...
[ 143.599803] cloud-init[765]: Unpacking libpam-systemd:amd64 (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 143.680250] cloud-init[765]: Preparing to unpack .../systemd_242-7ubuntu3.3_amd64.deb ...
[ 143.785319] cloud-init[765]: Unpacking systemd (242-7ubuntu3.3) over (242-7ubuntu3.2) ...
[ 144.362457] cloud-init[765]: Preparing to unpack .../libsystemd0_242-7ubuntu3.3_amd64.deb ...
[ 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-systemd:amd64 (242-7ubuntu3.3) ...
[ 154.485400] cloud-init[765]: Setting up libpam-systemd:amd64 (242-7ubuntu3.3) ...
[ 198.012728] cloud-init[765]: systemd is already the newest version (242-7ubuntu3.3).
(neipa) ipv6_mtu % cat output/EoanTestNetworkM...

[Launchpad Janitor (janitor)]

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/patches/CVE-2019-384x-1.patch: introduce
      seccomp_restrict_suid_sgid() for blocking chmod() for suid/sgid files
      in src/shared/seccomp-util.c, src/shared/seccomp-util.h.
    - debian/patches/CVE-2019-384x-2.patch: add test case for
      restrict_suid_sgid() in src/test/test-seccomp.c.
    - debian/patches/CVE-2019-384x-3.patch: expose SUID/SGID restriction as
      new unit setting RestrictSUIDSGID= in src/core/dbus-execute.c,
      src/core/execute.c, src/core/execute.h,
      src/core/load-fragment-gperf.gperf.m4, src/shared/bus-unit-util.c.
    - debian/patches/CVE-2019-384x-4.patch: document the new
      RestrictSUIDSGID= setting in man/systemd.exec.xml.
    - debian/patches/CVE-2019-384x-5.patch: turn on RestrictSUIDSGID= in
      most of our long-running daemons in units/systemd-*.service.in.
    - debian/patches/CVE-2019-384x-6.patch: imply NNP and SUID/SGID
      restriction for DynamicUser=yes service in man/systemd.exec.xml,
      src/core/unit.c.
    - debian/patches/CVE-2019-384x-7.patch: fix compilation on arm64 in
      src/test/test-seccomp.c.
    - CVE-2019-3843
    - CVE-2019-3844
  * SECURITY UPDATE: memory leak in button_open
    - debian/patches/CVE-2019-20386.patch: fix event in
      src/login/logind-button.c.
    - CVE-2019-20386
  * SECURITY UPDATE: heap use-after-free with async polkit queries
    - debian/patches/CVE-2020-1712-1.patch: on async pk requests,
      re-validate action/details in src/shared/bus-util.c.
    - debian/patches/CVE-2020-1712-2.patch: introduce API for re-enqueuing
      incoming messages in src/libsystemd/libsystemd.sym,
      src/libsystemd/sd-bus/sd-bus.c, src/systemd/sd-bus.h.
    - debian/patches/CVE-2020-1712-3.patch: when authorizing via PK
      re-resolve callback/userdata instead of caching it in
      src/shared/bus-util.c.
    - debian/patches/CVE-2020-1712-4.patch: fix typo in function name in
      src/libsystemd/libsystemd.sym, src/libsystemd/sd-bus/sd-bus.c,
      src/systemd/sd-bus.h, src/shared/bus-util.c.
    - debian/libsystemd0.symbols: added new symbols.
    - CVE-2020-1712
  * This package does _not_ contain the changes from 237-3ubuntu10.34 in
    bionic-proposed.

 -- Marc Deslauriers <email address hidden> Tue, 04 Feb 2020 20:07:56 -0500

[Dimitri John Ledkov (xnox)]

This SRU needs to be reuploaded, due to security update that trumped this in progress SRU.

[Steve Langasek (vorlon)]

Hello Ryan, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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.

[Steve Langasek (vorlon)]

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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

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/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

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-bootchart/unknown (armhf)
netplan.io/0.98-0ubuntu1 (amd64)
systemd/242-7ubuntu3.7 (ppc64el, s390x)
sks/unknown (armhf)
munin/2.0.49-3ubuntu1 (i386)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ryan Harper (raharper)]

Verified Eoan systemd 242-7ubuntu3.7 correctly sets IPv6 MTU
Verified Bionic systemd 237-3ubuntu10.39 correctly sets IPv6 MTU

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 242-7ubuntu3.7

---------------
systemd (242-7ubuntu3.7) eoan; urgency=medium

  [ Dariusz Gadomski ]
  * d/p/lp1762391/0001-Call-getgroups-to-know-size-of-supplementary-groups-.patch,
    d/p/lp1762391/0002-user-util-tweak-to-in_gid.patch,
    d/p/lp1762391/0003-user-util-Add-helper-functions-for-gid-lists-operati.patch,
    d/p/lp1762391/0004-execute-Restore-call-to-pam_setcred.patch,
    d/p/lp1762391/0005-execute-Detect-groups-added-by-PAM-and-merge-them-wi.patch,
    d/p/lp1762391/0006-test-Add-tests-for-gid-list-ops.patch,
    d/p/lp1762391/0007-execute-add-const-to-array-parameters-where-possible.patch,
    d/p/lp1762391/0008-execute-allow-pam_setcred-to-fail-ignore-errors.patch:
    - Restore call to pam_setcred (LP: #1762391)

  * d/p/lp1846232/0001-network-honor-MTUBytes-setting.patch,
    d/p/lp1846232/0002-network-bump-MTU-bytes-only-when-MTUByte-is-not-set.patch:
    - do not always bump MTU with additional 4bytes (LP: #1846232)
  * d/p/lp1671951-network-set-ipv6-mtu-after-link-up-or-device-mtu-cha.patch:
    - set ipv6 mtu at correct time (LP: #1671951)
  * d/p/lp1845909/0001-network-rename-linux_configure_after_setting_mtu-to-linux.patch,
    d/p/lp1845909/0002-network-add-link-setting_genmode-flag.patch,
    d/p/lp1845909/0003-network-if-ipv6ll-is-disabled-enumerate-tentative-ipv6-ad.patch,
    d/p/lp1845909/0004-network-drop-foreign-config-after-addr_gen_mode-has-been-.patch,
    d/p/lp1845909/0005-network-drop-IPv6LL-address-when-LinkLocalAddressing.patch:
    - 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

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 237-3ubuntu10.39

---------------
systemd (237-3ubuntu10.39) bionic; urgency=medium

  [ Dariusz Gadomski ]
  * d/p/lp1762391/0001-Call-getgroups-to-know-size-of-supplementary-groups-.patch,
    d/p/lp1762391/0002-user-util-tweak-to-in_gid.patch,
    d/p/lp1762391/0003-user-util-Add-helper-functions-for-gid-lists-operati.patch,
    d/p/lp1762391/0004-execute-Restore-call-to-pam_setcred.patch,
    d/p/lp1762391/0005-execute-Detect-groups-added-by-PAM-and-merge-them-wi.patch,
    d/p/lp1762391/0006-test-Add-tests-for-gid-list-ops.patch,
    d/p/lp1762391/0007-execute-add-const-to-array-parameters-where-possible.patch,
    d/p/lp1762391/0008-execute-allow-pam_setcred-to-fail-ignore-errors.patch:
    - Restore call to pam_setcred (LP: #1762391)

  [ Ioanna Alifieraki ]
  * d/p/lp1860548/0001-Revert-Replace-use-of-snprintf-with-xsprintf.patch,
    d/p/lp1860548/0002-job-truncate-unit-description.patch:
    - use snprintf instead of xsprintf (LP: #1860548)

  [ Dan Streetman ]
  * d/p/lp1833193-network-update-address-when-static-address-was-alrea.patch:
    - Update lft when static addr was cfg by dhcp (LP: #1833193)
  * d/p/lp1849261/0001-core-when-we-can-t-enqueue-OnFailure-job-show-full-e.patch,
    d/p/lp1849261/0002-core-don-t-trigger-OnFailure-deps-when-a-unit-is-goi.patch:
    - Only trigger OnFailure= if Restart= is not in effect (LP: #1849261)
  * d/p/lp1671951-network-set-ipv6-mtu-after-link-up-or-device-mtu-cha.patch:
    - set ipv6 mtu at correct time (LP: #1671951)
  * d/p/lp1845909/0001-networkd-honour-LinkLocalAddressing.patch,
    d/p/lp1845909/0002-networkd-fix-link_up-12505.patch,
    d/p/lp1845909/0003-network-do-not-send-ipv6-token-to-kernel.patch,
    d/p/lp1845909/0004-network-rename-linux_configure_after_setting_mtu-to-linux.patch,
    d/p/lp1845909/0005-network-add-link-setting_genmode-flag.patch,
    d/p/lp1845909/0006-network-if-ipv6ll-is-disabled-enumerate-tentative-ipv6-ad.patch,
    d/p/lp1845909/0007-network-drop-foreign-config-after-addr_gen_mode-has-been-.patch,
    d/p/lp1845909/0008-network-drop-IPv6LL-address-when-LinkLocalAddressing.patch:
    - if LinkLocalAddressing=no prevent creation of ipv6ll (LP: #1845909)
  * d/p/lp1859862-network-Do-not-disable-IPv6-by-writing-to-sysctl.patch:
    - enable ipv6 when needed (LP: #1859862)
  * d/p/lp1836695-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch:
    - (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

[Dan Watkins (oddbloke)]

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/net/ipv6/conf/eth0/mtu is 1337, /sys/class/net/eth0/mtu is 1500.

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/net/ipv6/conf/eth0/mtu and /sys/class/net/eth0/mtu are set to 1337. I'm not sure, however, that this is a sufficient test, or if my expectations are correct.

Thoughts, anyone?