Install WITHOUT allowing Wicked to be part of the system

Is it possible to bypass completely the installation of “wicked” and instead use purely and only Network Manager during the initial installation?

I have run into nothing but problems with “wicked” and I would rather it never even be part of the installation. This service has caused me considerable headache and is the only thing that is pushing me to move far away from my over 15 years of using SuSe on my servers.

Thank you.

First: wicked is working fine for me, on multiple versions of openSUSE, mutiple machines.
Second: What’s the problem ? “Nothing but problems” doesn’t provide any info anybody could deal with
Third: Threatening to walk away doesn’t help.

I doubt that Wicked can be removed from your system, Wicked is an enhanced shell over the fundamental ifup/ifdown network commands which are core to basic network functionality.

Network Manager is also always installed by default in all modern openSUSE, it’s just disabled.
I suppose that it should be possible to script switching from Wicked to NM, but I’ve personally never felt that opening up YaST immediately after install to do this was that big a deal (Once upon a time, it didn’t work as reliably so maybe perspective is different).

TSU

In short; no. In length; no. If you uninstall Wicked, you will also uninstall YAST and NetworkManager.

It’s the replacement for the ifup system and has several benefits, the only issues I’ve seen with it are when paired with poorly configured DHCP systems which should not be an issue if you are dealing with servers anyway.

This is what has happened, twice.

I setup my server, as I would be operating it live, with the only difference being the final/live Static IP Address.

I ran it for two weeks, rebooting, testing and ensuring that it would work fine. Put it into production, it worked fine for roughly one week.

Then Wicked stopped working altogether. I wracked my head on it for a bit, before going back to the old server.

I then reinstalled the whole server, same settings, then ran all the updates and a test reboot, Wicked went down, exactly the same way. There had to be some update, that changed some setting, causing wicked to fail. This happened to the host server and it happened to the Virtual Machines running virtual NICs.

At that point, I tossed my hands up and started looking at other Distros. I can’t put into production a server that will lose network connectivity, for no grossly apparent reason, such as not even booting or full hardware failure.

To me, Wicked simply cannot be trusted.

I guess, for now, my option will be to install, switch from Wicked to Network Manager and then create a number of test guests that use Wicked and figure out why Wicked fails and if there is a way to automate checking and then automatically fixing itself. While doing this testing, I’ll be sure to take better notes and update this or create a new thread.

It is a complete riddle to me what you mean with “wicked stopped working”. Taking into account that wicked only runs at boot (and shutdown) to do some network statements (like ifup/down, route or there more recent friends) using parameters from files inside etc/sysconfig/network/, I can only assume that you mean that your network was not properly started at boot after there were changes to one or more of those configuration files.

Most people change those configuration files by using YaST > Networking > Network Devices.

We can only try to help you in earnest with this when you tell us exactly what you see (using statements to check the status of your network cards, routing) and the contents of those configuration files.

Using wicked (and earlier ifup) for static computers like desktop and computer room systems (often called “servers”) is a stable way to do since ages. New fangled inventions like Network Manager (to help end-users of movable sytems like laptops and notebooks connecting to different networks) are not needed for a fixed network connections.

And of course, when you prefer Network Manager above Wicked, simply do so. You can only run one of both at the same time and YaST gives you the method to switch.

Wicked should not be unreliable, although I haven’t looked at the codebase to inspect updates I doubt that the functionality would be touched much if at all for long periods of time.

Only thing I might suggest is that you may not be updating your machines immediately after install or your network may not be that reliable and may experience drops. SOP for every install should be to run a “zypper up” immediately, and at certain important times like after installing major applications. Personally, I always favor updating over patching and do it frequently since I consider the alternative more risky than keeping machines fully updated.

TSU

On 06/23/2017 11:06 AM, tsu2 wrote:
>
> Wicked should not be unreliable, although I haven’t looked at the
> codebase to inspect updates I doubt that the functionality would be
> touched much if at all for long periods of time.
>
> Only thing I might suggest is that you may not be updating your machines
> immediately after install or your network may not be that reliable and
> may experience drops. SOP for every install should be to run a “zypper
> up” immediately, and at certain important times like after installing
> major applications. Personally, I always favor updating over patching
> and do it frequently since I consider the alternative more risky than
> keeping machines fully updated.
>
> TSU
>
>

This whole thing sounds like network address collision, two machines
trying to use the same ip address. Are you using ipV4 or ipV6? If you
are using a fixed address is it outside of the DHCP provided address
range? Never use a fixed address on a server that is also part of a DHCP
address range.


Ken
linux since 1994
S.u.S.E./openSUSE since 1996

I’m only using IPv4.

I have no other machines sharing any IP Address. My DCHP server only provides a small range of numbers and I used a completely free IP Address that I have reserved for the purpose of setting up and testing servers. In fact, the primary host server had it’s permanent static IP Address in place, the Virtual Guest, that launched at boot, also had it’s own static IP address, from my list of known to be free IP Addresses.

I also had both of the virtual NICs that are needed for the guest and host to talk for the NFS share for the /home from the host to the guest OS using static IP addresses on their own completely separate addressing scheme from the main production network.

The second time this issue arose, the guest machine wasn’t even setup and I had not even configured the virtual interface on the host server.

It’s possible this is related to the addition of using KVM causing wicked to fail at boot. (?)

The error message that I recall is “Network Unreachable”, I couldn’t ping anything, no IP Addresses showed up and it wasn’t until I switched from Wicked to Network Manager that I could even connect to the network.

I apologize that, at this time, I have less than useful information available to track down the problem.

Examning the journal logs for wicked would be helpful in such an instance

sudo journalctl -u wicked.service

Also, if you believe wicked itself has failed, check the messages regarding its reported status…

sudo systemctl status wicked

Solid diagnostic information is required here, otherwise we’re left to speculate…

You’re describing a lot of things that don’t necessarily fit together which suggests to me that you aren’t setting up your networking correctly.

First, you should know that “network unreachable” means that your network configuration is not consistent with the network it’s connected to. This error is generally nearly impossible if you use DHCP and if you’re configuring a static address is normally a clear indication you’re making a fundamental configuration error.

As for your use and description of “virtual interfaces” and the like,
How are you configuring your virtual networking?
Are you using vm manager to configure virtual networks or are you doing something else?

So,
For starters I’d suggest you post the following

Host Machine

ip addr
ip route
brctl show

Then the following command for each bridge device listed by “brctl show” eg.

ip addr show br0

Guest Machine

ip addr
ip route

Your interface file contents, If the network interface you’re using is eth0, then the following command will display its contents

cat /etc/sysconfig/network/ifcfg-eth0

TSU