Alfonso, do you have any debug-logs for sytemd-networkd and udev to see
what happens when the interface enters the "failed" state?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/b
I think I can reporudce this on classic...
lxc launch --vm ubuntu-daily:jammy nd-reload
lxc shell nd-reload
root@nd-reload:~# netplan get
network:
version: 2
ethernets:
enp5s0:
dhcp4: true
root@nd-reload:~# networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback ca
Here I produced some networkd debug logs on a UC22 system.
** Attachment added: "networkd-debug.log"
https://bugs.launchpad.net/netplan/+bug/2058976/+attachment/5762821/+files/networkd-debug.log
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, w
To be clear, that carrier is set to "failed" when retriggering uevents
is not the main problem. The main problem is that after 5-10 minutes,
networkd silently takes control again of the ethernet interface. The
retriggering of uevents and the reaction on the networkd side is just an
indication that
I have found another case where reloading networkd will not be enough to
apply the configuration. I'm not sure if it's the same root cause but it
looks similar so I'll use this ticket to document it.
The scenario looks like this (it's all done in a LXD VM running
Oracular):
1) Start with the defa
5 matches
Mail list logo
