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).
