Hi Bernd,

Thanks for reporting. We would need the YaST logs to properly debug the problem. Could you please attach them?

If you are not sure how to do it, please have a look to this guide: https://en.opensuse.org/openSUSE:Report_a_YaST_bug

Basically, you have to use save_y2logs.

Created attachment 810733 [details]
Requested YaST Logs

It is simple to get this behavior. Install openSUSE 15.1 to a 
RasPi and open YaST lan. There you found that Wicked is enabled and you get no hint that NetworkManager is running, too.

Now configure the NIC with a fixed IP you get two IPs in the system.

After this you shut have your own log files.

Thanks for the logs.

Well, not so easy (at least for me) because I have no RasPi here to test. Anyway, I hope we can address it with you logs.

(In reply to Bernd Nachtigall from comment #2)
> Created attachment 810733 [details]
> Requested YaST Logs
> 
> It is simple to get this behavior. Install openSUSE 15.1 to a 
> RasPi and open YaST lan. There you found that Wicked is enabled and you get
> no hint that NetworkManager is running, too.
> 
> Now configure the NIC with a fixed IP you get two IPs in the system.
> 
> After this you shut have your own log files.

Basically the code checks to which backend is the network.service linked to.

 In case of Network manager it shows the warning. In this case both service seems to be running and network.service to be linked to wicked service, it would be nice to know the reasons of that, in the past we found it was because some third party dependencies which started NM.

See https://bugzilla.suse.com/show_bug.cgi?id=1117636#c5

I will try to check it in a RasPI installation and of course, we probably should inform the user when both service are running.

Bernd, I assume you booted some JeOS-raspberrypi3 image or graphical variant and not the .iso based Installer?

(In reply to Andreas Färber from comment #5)
> Bernd, I assume you booted some JeOS-raspberrypi3 image or graphical variant
> and not the .iso based Installer?

From opensuse-arm mailing list:

openSUSE-Leap-15.1-ARM-XFCE-raspberrypi3.aarch64-2019.05.17-Snapshot1.18.raw.xz

Sources:
https://build.opensuse.org/package/show/openSUSE:Leap:15.1:ARM:Images/JeOS

(In reply to Knut Alejandro Anderssen González from comment #4)
> (In reply to Bernd Nachtigall from comment #2)
> > Created attachment 810733 [details]
> > Requested YaST Logs
> > 
> > It is simple to get this behavior. Install openSUSE 15.1 to a 
> > RasPi and open YaST lan. There you found that Wicked is enabled and you get
> > no hint that NetworkManager is running, too.
> > 
> > Now configure the NIC with a fixed IP you get two IPs in the system.
> > 
> > After this you shut have your own log files.
> 
> Basically the code checks to which backend is the network.service linked to.
> 
>  In case of Network manager it shows the warning. In this case both service
> seems to be running and network.service to be linked to wicked service, it
> would be nice to know the reasons of that, in the past we found it was
> because some third party dependencies which started NM.
> 
> See https://bugzilla.suse.com/show_bug.cgi?id=1117636#c5
> 
> I will try to check it in a RasPI installation and of course, we probably
> should inform the user when both service are running.

What info do you need?

Basically what asked at #c5

I used the openSUSE-Leap-15.1-ARM-XFCE-raspberrypi3.aarch64-2019.05.17-Snapshot1.18.raw.xz image no ISO-based install.

(In reply to Bernd Nachtigall from comment #9)
> I used the
> openSUSE-Leap-15.1-ARM-XFCE-raspberrypi3.aarch64-2019.05.17-Snapshot1.18.raw.
> xz image no ISO-based install.

Thnx Bernd, confirmed the issue. Both service are enabled and network.service is linked to wicked.service


So, thre is a bug in the image and also something to improve in yast2-network.

Andreas, according to my understanding, the image has both NM and Wicked
services enabled. This confuses YaST, but the image needs to be fixed EVEN
if we enhance YaST to report the problem. This reassigning.

We'll track the enhancement in Trello. Please reassign back if you disagree.

I don't quite see what I (or rather Guillaume) could do here?

This is where NetworkManager is included into the Kiwi template for XFCE:
https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM:Live/JeOS/packagelist.inc?expand=1

It sounds like if we have both NetworkManager and wicked packages installed into an image, the outcome is somehow undetermined?
So are you suggesting that installation of wicked should be suppressed in case NM gets installed? Or are you asking for a Kiwi post-install script to perform some manual action after packages are installed? How does the Installer handle this?

No idea what should Kiwi or any particular image config do, but I see the
(resulting) problem in the image only.

The Installer configures the network, so it probably ALSO handles services.

If you believe the problem is elsewhere, please reassign to whatever component
you feel is responsible. It definitely is NOT YaST AFAIS.

Andreas, Lukas,

So? How do you think we could move forward? Do you know who can help here looking for the right component? Is there any workflow for this kind of situations? Someone else who could decide how to proceed?

Thanks in advance.

From my POV, the system is "broken" even before someone starts YaST.
It's built using Kiwi, not installed by YaST so YaST is not responsible
for the problem. If this is the expected state, we can adjust YaST to
handle that situation in a better way, but I doubt it's the case here.
Anyway, YaST itself will not fix the problem unless someone runs it.

Of course, we already have an enhancement request for YaST Network, but
it's currently rather low-priority.

Adding Wicked Team: Guys, PLS see at least comment #2 and comment #10
What do you think of that?

Wicked team, this bug is waiting for input from you since 2 months.
Please answer and then reassign back.

(In reply to Lukas Ocilka from comment #15)
> From my POV, the system is "broken" even before someone starts YaST.

Yes, the images are buggy and enable both, NetworkManager + wicked.

No idea who wrote the kiwi scripts to configure such conflict.

(In reply to Knut Alejandro Anderssen González from comment #10)
> So, thre is a bug in the image and also something to improve in
> yast2-network.

Exactly. Probably makes sense to split the issue into two.

Just to make sure: This is still valid for 15.2.

Not sure why I'm assigned - reassigning to an ARM JeOS maintainer.

The issue here is that config.sh calls suseInsertService NetworkManager without a preceding systemctl disable wicked.

As the image configures wicked in config.sh though, this might be intentional though. So maybe just keep NetworkManager.service disabled?

(In reply to Fabian Vogt from comment #20)
> The issue here is that config.sh calls suseInsertService NetworkManager
> without a preceding systemctl disable wicked.
> 
> As the image configures wicked in config.sh though, this might be
> intentional though. So maybe just keep NetworkManager.service disabled?

I assume the wicked configuration is for the minimal "JeOS" flavor, whereas disabling wicked would probably be preferable for (some of) the desktop flavors?

With regards to comment #14 I think the easiest to try would be to exclude wicked from the package list when NetworkManager is pulled in. If that doesn't help, shell scripts can still be considered.

(In reply to Andreas Färber from comment #21)
> (In reply to Fabian Vogt from comment #20)
> > The issue here is that config.sh calls suseInsertService NetworkManager
> > without a preceding systemctl disable wicked.
> > 
> > As the image configures wicked in config.sh though, this might be
> > intentional though. So maybe just keep NetworkManager.service disabled?
> 
> I assume the wicked configuration is for the minimal "JeOS" flavor, whereas
> disabling wicked would probably be preferable for (some of) the desktop
> flavors?

Yes, the attempt to use NetworkManager in the desktop flavors is probably
the source.

Generally, a switch of the network service should check what was enabled
before: "systemctl enable" does not implicate a "disable" call.

That is at least:
   systemctl disable network.service
   systemctl enable  wicked.service
or
   systemctl disable network.service
   systemctl enable  NetworkManager.service

When needed, a call to:

   current=`systemctl show -p Id network.service`
   current=${current#Id=}
   echo "current network.service: $current"

shows the currently enabled one. Probably better in kiwi is:
   
   current=`readlink /etc/systemd/system/network.service 2>/dev/null`
   current=${current##*/}
   echo "current network.service: $current"

Note also that
   systemctl disable network.service
using the network.service link works only when the state is correct, that
is when not both are already enabled.

(In reply to Andreas Färber from comment #21)
> With regards to comment #14 I think the easiest to try would be to exclude
> wicked from the package list when NetworkManager is pulled in. If that
> doesn't help, shell scripts can still be considered.

It would be better to keep both packages, but only enable one. That way people can switch from one to the other, if needed.

(In reply to Guillaume GARDET from comment #24)
> (In reply to Andreas Färber from comment #21)
> > With regards to comment #14 I think the easiest to try would be to exclude
> > wicked from the package list when NetworkManager is pulled in. If that
> > doesn't help, shell scripts can still be considered.
> 
> It would be better to keep both packages, but only enable one. That way
> people can switch from one to the other, if needed.

Yes, it would be, but traditionally, they can be both installed (already on
SLES-11). [One of the drawbacks with a package conflict is: you need working
network connection / access to install media before you can switch, what is
sometimes not the case, e.g. when you have trouble with one of them].

*** Bug 1173111 has been marked as a duplicate of this bug. ***

This is an autogenerated message for OBS integration:
This bug (1141433) was mentioned in
https://build.opensuse.org/request/show/823173 Factory:ARM:Live / JeOS

Leap 15.1 is EOL. 
This should be fixed in Tumbleweed and Leap 15.3 since:
https://build.opensuse.org/request/show/859627

We would need to backport this fix to Leap 15.2.

This is an autogenerated message for OBS integration:
This bug (1141433) was mentioned in
https://build.opensuse.org/request/show/888681 Factory:ARM / JeOS

This is an autogenerated message for OBS integration:
This bug (1141433) was mentioned in
https://build.opensuse.org/request/show/924915 Factory:ARM / JeOS

This is an autogenerated message for OBS integration:
This bug (1141433) was mentioned in
https://build.opensuse.org/request/show/924923 Factory:ARM / JeOS