Description of problem: Install from classical iso dated 29/11, proceed to summary. From experience I know networkmanager does not (did not) work with my hardware and wpa_supplicant works, so in Summary --> Services I select wpa_supplicant and make sure networkmanager service is not enabled (flag removed). But after reboot I see: "systemctl status" ....."vendor preset: enabled" which I would imagine is not correct: I think it overrides my choice... Reproducible: Steps to Reproduce:
Whiteboard: (none) => 6dev1
It may be that the service scripts have been updated. My understanding is that NetworkManager will start wpa_supplicant when required. However I am not sure if the wpa_supplicant service has a script requirement for NetworkManager, the easiest way to check would be to open the service file and are if it refers to it. I'm not near a computer at the moment so am unable to check for you.
CC: (none) => luke.nukem.jones
It seems to me that you are looking at the setup working as intended. Fine. But I was looking at the behaviour of the whole setup if the user decides it should be otherwise: user overrules default setup. This should also work, because the options are allowing it... To me it looks like that is not the case now so I signal it and let the experts judge it.
I just went through this with something else. I'm not sure what "vendor preset: enabled" means, but it's not the same as "enabled". You should see "enabled" or "disabled" right before this on the output line. My experience is that NM is *not* enabled by default in new systems (I usually have to do it myself), so for what you want, the better course would be to ignore NM entirely. In Summary, select Network and configure your wireless but when you get to the panel that asks whether NM should control the interface, choose "No". Let the regular MGA network stuff worry about wpa_supplicant. The way this is *supposed* to work is that drakconnect creates an ifcfg file for the interface and specifies NM=NO in it. Whether NM is running or not in the new system, it looks for the ifcfg file and keeps its hands off of the interface if NM=NO is specified. This didn't always work as intended. In the early days of NM, you pretty much had to uninstall it to get it not to interfere. Hopefully, it's feeling much better now.
CC: (none) => ftg
CC: (none) => mageiaAssignee: bugsquad => thierry.vignaudSource RPM: classical iso dated 29/11 => installer or drakconnect?
@Frank: The NM_CONTROLLED= parameter does work correctly now, so if you specify NM_CONTROLLED=no, NetworkManager will ignore the interface.
CC: (none) => ngompa13
Thanks, Neal. I couldn't be sure, since I've long since disabled ifcfg-rh in /etc/NetworkManager/NetworkManager.conf and let NM handle everything.
Is this bug still valid for the released 6dev1 iso(s)?
Keywords: (none) => 6dev1, NEEDINFOCC: (none) => marja11Whiteboard: 6dev1 => (none)
AFAICT from the journalctl records of the 6dev1 install, nm is not activated, so it appears to be fixed.
Status: NEW => RESOLVEDResolution: (none) => FIXED