I configured wifi during install, after the reboot. It was unable to connect. After logging in it was still unable to connect. I noticed that networkmanager had taken control of two wired interfaces, leaving control of wifi to draknet. After using the network center to configure each wired interface, checking NM controlled is unticked, which they both were anyway, and restarting the network it fails to start. After another reboot it is able to connect and NM shows all interfaces unmanaged. It seems to be NM grabbing the two wired interfaces despite being set not to which causes the wifi to fail. Reproducible: Steps to Reproduce:
Whiteboard: (none) => 3beta3
This was using gnome livedvd
Seems similar to bug 1138
also related to bug 7317
Priority: Normal => release_blocker
yes they are all related so why open another one ?
Related doesn't mean it's a duplicate, that's why.
i assume RC doesn't fix this either...
CC: (none) => alien
For mga4 I think we'll have to use perl-Glib-Object-Introspection to hook in NM...
CC: (none) => thierry.vignaud
is there a way to (quick&dirty) prevent the grabbing or will we put this in the errata?
the "NM_CONTROLLED=no" option in /etc/sysconfig/network-scripts/ifcfg-* (or the check box in drakconnect)
the initial bug is fixed now, no ?
Created attachment 4878 [details] Don't set NM_CONTROLLED unless we know it's value. So for this issue, I've actually done the opposite in the attached patch. I've modifed the drakx-net code to only write the NM_CONTROLLED value to the config when it KNOWS the user has made a choice, otherwise it's left out. Previously it would default to no and thus NM would be relagated to the side lines and thus a combination of NM+initscripts will be used which is generally a bit confusing. This means that everything else defaults to NM. This means the live CDs with NM installed in them will use NM. And after installation NM will grab the interfaces too. Simply removing NM or disabling/masking it should be enough for things to flip over to initscripts handling without any explicit tweaks of the config file. This is maybe too intrusive for this late stage tho'. This is an old bug about MGA3 so I don't think it should prevent us from releasing MGA4 even if things are in the same state. This patch can perhaps come after release.
CC: (none) => mageia
commit 360f3b5937e1fb1ff173240ec5c3ee9f8e9f9491 Author: Colin Guthrie <colin@...> Date: Fri Jan 24 09:57:13 2014 +0000 ifcfg: Do not write the NM_CONTROLLED flag unless we know it's value. If it's not read from the config, it will be read as undef, but written back as 'no'. This changes the behaviour where no setting means 'automatic' - i.e. if NM is installed, use it, otherwise don't. If the user wants to be specific, then they make the consious choice to tick the box in drakx-net. mga#6675 mga#9261 --- Commit Link: http://gitweb.mageia.org/software/drakx-net/commit/?id=360f3b5937e1fb1ff173240ec5c3ee9f8e9f9491 Bug links: Mageia https://bugs.mageia.org/show_bug.cgi?id=6675 https://bugs.mageia.org/show_bug.cgi?id=9261
I have added a patch in addition to Colin's, so the UI tools from drakx-net does not force NM_CONTROLLED to "no" if unset in the ifcfg file. That way, the tools will not change the interface configuration without an explicit modification from the administrator. Pushed both commits to master.
Any conclusion on that bug? did it fix the problem?
CC: (none) => ennael1
I *think* this is now fixed. I'll double check later today and close it of it's ok.
Closing as fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED