It looks like installation of this update may have resolved the issue on
our systems:
ethtool/jammy-updates 1:5.16-1ubuntu0.1
I believe that release was put together as a result of this bug report,
which may or may not be a duplicate:
https://bugs.launchpad.net/ubuntu/+source/ethtool/+bug/204398
I just went back to another machine that doesn't have "ethtool/jammy-
updates 1:5.16-1ubuntu0.1" installed yet. It also produces correct
output when I run "sudo ethtool --module-info eno3" now.
I think it's likely that this issue was fixed by some previous release
and I just didn't notice it until
We have an ubuntu server running a set of eight Samsung 980 Pro PCIe 4.0
NVMe SSDs (model MZ-V8P1T0BW) on Ubuntu 20.04.3 LTS (GNU/Linux
5.4.0-88-generic x86_64). We've seen this happen at least 5 times over
the past month, and not always on the same SSD. We first saw it happen
on 5.4.0-81. Some sam
It turns out the fix for this issue was backported to systemd v240:
https://github.com/systemd/systemd-stable/pull/37
I performed a release upgrade on one of our affected servers, bringing
it up from ubuntu 18.04 to ubuntu 19.04 (which uses systemd v240), and I
can confirm that the peers are bein
As near as I can tell the fix for this was never backported from systemd
v241 to bionic. I recently filed a related a bug report here:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853956
My symptoms are a little different (misconfiguration instead of an
infinite loop), but I have a str
I think the underlying problem is improper fragmentation of netlink
messages sent to the WireGuard device by systemd v237 in the
set_wireguard_interface function:
https://github.com/systemd/systemd/blob/v237/src/network/netdev/wireguard.c#L107
Appending netlink message data can fail if the messag
I now believe the dmesg complaint in my last comment to be a separate
issue. A fix for it was backported to systemd v238 in this commit:
https://github.com/systemd/systemd-
stable/commit/7db3fe08c5eb83584f3a3d356876b4acaa797585#diff-
f29d1bfc98e548dc0eb497c3d17cbefa
It was not backported to syste
On two systems with 33 peers I noticed that this shows up in dmesg after
a reboot:
netlink: 'systemd-network': attribute type 5 has an invalid length.
These lines also show up whenever I run `sudo systemctl restart systemd-
networkd` now. They didn't show up before the reboot.
This suggests that
Public bug reported:
ubuntu server 18.04.3 LTS
systemd 237-3ubuntu10.31
wireguard 0.0.20191012-wg1~bionic from PPA.
We're using systemd-networkd to configure wireguard via wireguard.netdev
and wireguard.network files in /etc/systemd/network/. All endpoints have
IPv4 addresses.
When we include 34
