[Mageia-dev] Drakx-net or NetworkManager for Mageia 2

Frank Griffin ftg at roadrunner.com
Tue Nov 22 03:15:57 CET 2011


On 11/21/2011 06:01 PM, Balcaen John wrote:
> Le lundi 21 novembre 2011 16:50:35 Frank Griffin a écrit :
> [...]
>> Sorry, I transposed - should have been 865.
> So here the problems here seems to happend when using the *specific* mdv plugin
> on mageia 1&  not with the native plugin (keyfile).

Well, it uses whatever the Mageia install puts there.  I didn't change 
anything from the defaults, much less anything specific to NM, about 
which I know next to nothing.

And all of this goes to Cauldron, not 1.  I have never done an install 
of 1, but always Cauldron with daily updates and periodic (~ every three 
weeks or so ) fresh installs.

>
> The bug was reported the 2011-07-15 while nm was updated to the beta 0.9 the
> 2011-06-14 by dmorgan.
> The support for ifcfg files  (aka respect the  NM_CONTROLLED=no and what i was
> wrongly calling support in sysvinit) was added by blino on 2011-07-31 by
> patching the redhat plugin.
> > From the log you did past in comment #1 we can see that NM&  sysvinit are
> trying to put on the same interface.
> You never explicity wrote that you have in your nm to control your wifi
> interface from what you write&  since i can see ifplug running i can expect
> that you were using by default sysvinit script&  not nm.
> So we 're still in the situation « nm is not reading correctly the ifcfg file&
> do not respect the NM_CONTROLLED=no solution.
> Your solution was to removed nm from your system to ensure that only ifcfg are
> used&  that nm does not try to bring up your interface.
> Regarding your comment #9 it seems their is a bug in the rhplugin&  it should
> be reported&  assigned to blino (since he's the one to code this
> functionnality).
> Please note that i don't deny there's a problem eventually but if indeed it's
> not working correctly with nm explicity with ifcfg- disable (aka only a lo
> interface&  no etho/wan/whatelse)  using the native keyfile plugin (&  not the
> rh-plugin) we should report it upstream.

Just to clarify, none of these errors is specific to system startup.  
All of them and all of the doc I included in my bugreports was taken 
from attempts to activate the interface *after* bootup.  So I still 
don't see what sysvinit would have to do with it.

> You never explicity wrote that you have in your nm to control your wifi
> interface from what you write&  since i can see ifplug running i can expect
> that you were using by default sysvinit script&  not nm

I'm not sure what you mean by this.  "in your nm" would imply that I 
modified some NM-specific config file, which I assure you I did not.  I  
have never done anything NM-specific to control NM.  The only things not 
done indirectly by NM itself or net-applet were my settings of 
NM_CONTROLLED and NEEDHOSTNAME in the ifcfg.

If there's an NM config option here that's out-of-line, it's Mageia 
that's putting it there, not me.

>
> Then if nm does not respect the NM_CONTROLLED=no (using the rhkeyfile plugin)
> then it should be reported&  assigned to blino.

I agree but realize that if I have to use this to begin with, there's an 
NM bug that is potentially severe enough to prevent distro deployment.

Really, guys, I sympathize with the desire to move to something newer 
supported by others.  But you have to be ready to deal with the issue of 
back-breakage.

We already went through this in Mandriva with system-config-printer, 
which on day one screwed up most of printerdrake's existing function.  
"It's new" is not an excuse for breaking 50% of what the replaced 
component did and then pointing fingers at "upstream" for the 
shortfall.  If it isn't ready, then it isn't ready, period.  Work with 
upstream until it is, and *then* dump it into Cauldron.  It doesn't have 
to be perfect, but it has to be good enough that it leaves systems 
functional enough to do meaningful testing with it to provide feedback, 
which is the whole point of Cauldron.

Blowing away the wireless capability of a significant portion of the 
community and then sitting back and saying stuff like "well it was a 
beta" or "we have to wait for upstream to fix that" doesn't cut it.   
This isn't just a blind rebuild of some stable package that doesn't 
warrant preliminary testing.  It's a major piece of the distro 
infrastructure, and you shouldn't be doing changes like that unless

a) you're able and prepared to dedicate the resource to attack the 
problems as they occur
    or
b) you're prepared to back the packages out if you can't do (a).





More information about the Mageia-dev mailing list