Bugzilla – Bug 1161536
[y2-network] after installing leap 15.1 both wicked and network manager were running causing issues with resolv.conf
Last modified: 2020-01-28 14:54:17 UTC
Created attachment 828009 [details]
I just did an fresh install of leap 15.1 and when connecting to a wifi network the resolve conf is empty. I also had this issue on the same laptop with an old 15.0 install. With help from lnussel we realized both wicked and network manager are running at the same time. For desktop stuff network manager should be the default. I also picked kvm_server during the install, that would be my guess of the issue.
But I made 0 changes in the install for that. But if I remember I might have seen something about networkmanager and wicked.
I've attached the y2.log
Some similar problems we have had in the past:
- Network manager was starting in a wicked-managed system due to a wrong
dependency in teamviewerd service file:
- NetworkManager running when it shouldn't
This is not an exact duplicate of any of them, but the problem is the same - wicked and NetworkManager end up both running.
The attached YaST logs does not correspond to the installation, but to an execution of the YaST Network module performed in the resulting system.
According to them, YaST considered wicked to be the backend at the beginning:
2020-01-22 11:40:47 yast2/systemctl.rb:34 systemctl show network.service --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath --property=CanReload
2020-01-22 11:40:47 modules/NetworkService.rb:204 Current backend: wicked
But that was switched to Network Manager, so at the end of the execution you can read:
2020-01-22 11:41:48 modules/Lan.rb:1015 Attempting to reload network service, normal stage true, ssh: false
2020-01-22 11:41:48 ShellCommand.cc:78 Removed /etc/systemd/system/multi-user.target.wants/wicked.service.
2020-01-22 11:41:48 ShellCommand.cc:78 Removed /etc/systemd/system/dbus-org.opensuse.Network.DHCP6.service.
2020-01-22 11:41:48 ShellCommand.cc:78 Removed /etc/systemd/system/dbus-org.opensuse.Network.AUTO4.service.
2020-01-22 11:41:48 ShellCommand.cc:78 Removed /etc/systemd/system/dbus-org.opensuse.Network.DHCP4.service.
2020-01-22 11:41:48 ShellCommand.cc:78 Removed /etc/systemd/system/network-online.target.wants/wicked.service.
2020-01-22 11:41:48 ShellCommand.cc:78 Removed /etc/systemd/system/network.service.
2020-01-22 11:41:48 ShellCommand.cc:78 Removed /etc/systemd/system/dbus-org.opensuse.Network.Nanny.service.
2020-01-22 11:41:49 ShellCommand.cc:78 Created symlink /etc/systemd/system/network.service → /usr/lib/systemd/system/NetworkManager.service.
2020-01-22 11:41:49 yast2/systemctl.rb:34 systemctl show network.service --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath --property=CanReload
2020-01-22 11:41:49 modules/NetworkService.rb:204 Current backend: network_manager
Did that execution of YaST Network fix the problem or is wicked still running after that?
On the other hand, we would need the logs of the installation process in order to try to guess why the installation resulted in an inconsistent system. Please use save_y2logs as explained at https://en.opensuse.org/openSUSE:Report_a_YaST_bug
I was trying to reproduce the issue and was not able to.
I used a laptop with a wireless network during the installation and then have selected different roles (desktop with KDE, Gnome, Generic) and also the Server role. I tried to switch between wicked and NM as default, and also adding the kvm_host_server package.
In all the cases the network.service was linked to the selected service during the installation and the other service was disabled or not running in the running system.
BTW, we have already a bug and a Trello Card for at least report the situation to the user when YaST is running, and it was found in the RPI image.
I will associate this bug to the same Trello card as it is not exactly the same architecture and you said it happened after installation.
It should be possible to determine if there is something pulling NetworkManager systemd unit as a dependency with:
$ systemctl list-dependencies --reverse NetworkManager-wait-online.service
could you try it and paste the output?
The output of the list-dependencies was just network-online.target
After using yast to switch to network manager I haven't had any other issues.