Which files do you have in /etc/netplan/ and which is their content?
after an reboot the
00-default-nm-renderer.yaml
Content:
network:
renderer: NetworkManager
is deleted but the old
00-systemd-networkd-eth.yaml
Content:
network:
version: 2
ethernets:
eth0:
addresses: [192.168.99.171/24]
gateway4: 192.168.99.1
wifis:
wlan0:
access-points:
myspot:
password: secretpass
dhcp4: true
is still there and NetworkManager configs in current_config_file ethernet is set to be true,
but in
/var/snap/network-manager/current/conf.d/
the file
disable-ethernet.conf
is still there
when i now reboot all settings are gone and netplan have taken ownership of the connections
Wifi will be taken ownership of network-manager and connections will be added but eth0 will not be managed.
@tokurz try by setting ethernet.enable with
snap set network-manager ethernet.enable=true
then reboot.
this setting is already be set in the file:
/var/snap/network-manager/current/current_opts_file
we have reverted to the working version 253, maybe some migration steps are not correct working.
I saw on syslog that the file:
00-default-nm-renderer.yaml
is beeing deleted in the by network-manager in
/etc/netplan
That is not strictly the snap setting. What does
snap get network-manager ethernet.enable
show?
@abeato
this command I cannot run yet, because its not a local device where I have access, this device is by an customer and he needs to work with that. So we reverted for a couple of hours, maybe after next auto refresh period I can check when the network-manager is installed in the newest revision.
Hey @abeato
snap get network-manager ethernet.enable
shows false when it installed the new version
Also the plug will not be autoconnected:
network-manager:network-setup-control
I have set in my scripts now that these should be done.
But it should checked why is not autoconnected.
yeah I have modified my script and this do it know. The problem, old devices with old network-manager version can be have this problem that no dhcp is in any kind of stuff working.
That should not really happen in /etc/netplan/00-default-nm-renderer.yaml is in place before upgrading the snap. If you see this happening again, please paste content of all files in /etc/netplan/ before doing any change.
the problem after the snap refresh the
00-default-nm-renderer.yaml
is gone in the /etc/netplan
I have saw in the journalctl:
network-manager.service : rm -rf /etc/netplan/00-default-nm-renderer.yaml
but the default eth yaml is not be touched.
I have create a couple of times the /etc/netplan/00-default-nm-renderer.yaml
and the /etc/netplan directory was empty after each reboot.
@tokurz please open a bug in https://bugs.launchpad.net/snappy-hwe-snaps and upload there the journal. Note that is it normal the the file is removed if “ethernet.enable” is set to false, what would be interesting to know is the value of that setting before the upgrade happened for the first time
is this step:
snap set network-manager ethernet.enable=true
now an normal behavior ?
Because we had inspect now an device where are an fresh installed v265 Network-Manager installed,
ls /etc/netplan
00-default-nm-renderer.yaml
00-snapd-config.yaml
I will create a bug in launchpad with the journalctl.
But as Information the file:
00-default-nm-renderer.yaml
we always create by during running our scripts. in 253 was before no problems.
Yes, it has been there for a while, see https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/reference/configuration/ethernet_support
Thanks for opening the bug.
This page I didn’t know before, I just used these allways:
https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/enable-ethernet-support
That docs needs updating, I will make sure that happens. Re-reading the thread, I notice now that this is probably not happening when upgrading the NM snaps
(case that should be handled fine), but when installing it from scratch and then running your script. Creating the file does not work anymore with the latest snap, you need now to use “snap set”.
How is it will be handle with the autoconnect plug?
ubuntupicore@localhost:~$ snap connect network-manager:network-setup-control
I have this run also manual…
@tokurz you actually do not need that interface, as access to /etc/netplan is provided by the network-manager slot too. I’ve opened an autoconnect request anyway: Request: autoconnect of `network-setup-control` for network-manager snap
@tokurz nevermind I said in the previous comment, that connection might be actually needed by the configure hook.