Bug 1141433 - Get no hint that network connection is made by NetworkManager when start YaST Networkmanagement
Get no hint that network connection is made by NetworkManager when start YaST...
Status: IN_PROGRESS
: 1173111 (view as bug list)
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Live Medium
Leap 15.1
aarch64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: Guillaume GARDET
E-mail List
https://trello.com/c/sHkqLN4q
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-07-15 08:37 UTC by Bernd Nachtigall
Modified: 2021-10-12 18:40 UTC (History)
14 users (show)

See Also:
Found By: Community User
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Requested YaST Logs (459.78 KB, text/plain)
2019-07-17 12:42 UTC, Bernd Nachtigall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Nachtigall 2019-07-15 08:37:14 UTC
Start YaST module LAN. Then I miss a hint (like in openSUSE for x86_64) that the network connections are managed by NetworkManager.

This leads to an improper network configuration with a IP from DHCP (via NetworkManager) and a secondary IP address which is inserted via YaST lan.
Comment 1 José Iván López González 2019-07-17 11:45:03 UTC
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.
Comment 2 Bernd Nachtigall 2019-07-17 12:42:08 UTC
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.
Comment 3 José Iván López González 2019-07-17 13:53:10 UTC
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.
Comment 4 Knut Alejandro Anderssen González 2019-07-17 14:28:55 UTC
(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.
Comment 5 Andreas Färber 2019-07-17 14:38:57 UTC
Bernd, I assume you booted some JeOS-raspberrypi3 image or graphical variant and not the .iso based Installer?
Comment 6 Andreas Färber 2019-07-17 15:50:40 UTC
(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
Comment 7 Bernd Nachtigall 2019-07-18 10:08:33 UTC
(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?
Comment 8 Knut Alejandro Anderssen González 2019-07-18 11:19:31 UTC
Basically what asked at #c5
Comment 9 Bernd Nachtigall 2019-07-18 12:04:28 UTC
I used the openSUSE-Leap-15.1-ARM-XFCE-raspberrypi3.aarch64-2019.05.17-Snapshot1.18.raw.xz image no ISO-based install.
Comment 10 Knut Alejandro Anderssen González 2019-07-18 17:07:30 UTC
(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.
Comment 11 Lukas Ocilka 2019-08-30 08:00:21 UTC
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.
Comment 12 Andreas Färber 2019-08-30 10:45:38 UTC
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?
Comment 13 Lukas Ocilka 2019-09-05 10:25:21 UTC
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.
Comment 14 David Diaz 2019-09-15 20:56:52 UTC
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.
Comment 15 Lukas Ocilka 2019-09-16 10:11:28 UTC
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?
Comment 16 Stefan Hundhammer 2019-11-25 11:32:45 UTC
Wicked team, this bug is waiting for input from you since 2 months.
Please answer and then reassign back.
Comment 17 Marius Tomaschewski 2020-03-25 14:24:51 UTC
(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.
Comment 18 Marius Tomaschewski 2020-03-25 14:27:45 UTC
(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.
Comment 19 Stefan Fent 2020-03-25 15:15:25 UTC
Just to make sure: This is still valid for 15.2.
Comment 20 Fabian Vogt 2020-03-27 09:36:51 UTC
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?
Comment 21 Andreas Färber 2020-03-27 09:51:24 UTC
(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.
Comment 22 Marius Tomaschewski 2020-03-27 11:33:25 UTC
(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"
Comment 23 Marius Tomaschewski 2020-03-27 11:36:05 UTC
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.
Comment 24 Guillaume GARDET 2020-03-30 08:10:52 UTC
(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.
Comment 25 Marius Tomaschewski 2020-03-30 12:39:45 UTC
(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].
Comment 26 Guillaume GARDET 2020-07-07 13:25:25 UTC
*** Bug 1173111 has been marked as a duplicate of this bug. ***
Comment 27 OBSbugzilla Bot 2020-07-28 14:30:07 UTC
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
Comment 28 Guillaume GARDET 2021-03-02 14:55:39 UTC
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.
Comment 29 OBSbugzilla Bot 2021-04-27 07:40:16 UTC
This is an autogenerated message for OBS integration:
This bug (1141433) was mentioned in
https://build.opensuse.org/request/show/888681 Factory:ARM / JeOS
Comment 30 OBSbugzilla Bot 2021-10-12 16:40:44 UTC
This is an autogenerated message for OBS integration:
This bug (1141433) was mentioned in
https://build.opensuse.org/request/show/924915 Factory:ARM / JeOS
Comment 31 OBSbugzilla Bot 2021-10-12 18:40:42 UTC
This is an autogenerated message for OBS integration:
This bug (1141433) was mentioned in
https://build.opensuse.org/request/show/924923 Factory:ARM / JeOS