[Mageia-dev] Drakx-net or NetworkManager for Mageia 2
mikala at mageia.org
Tue Nov 22 00:01:50 CET 2011
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).
> > Bug 2416 was submitted when nm 0.9 (well beta) was not patched to
> > support our sysvinit script, we'll still waiting for an answer of the
> > initial report.
> If you look at comment #6 in this bug, you'll see that this is another
> case of the same bug reported with NM in several other distros
> ("disconnected for local ... (reason=3)). I'm not sure what that would
> have to do with sysvinit script support.
This bug report is against nm not respecting the NM_CONTROLLED=no cf comment
We can expect problem when 2 system are trying to interfere with the same
> > So 2160 is the only bug remaining here but i think it's probably the
> > same bug aka it was reported when nm was not supporting sysvinit
> Please explain about nm not supporting sysvinit, or point me to the
> relevant bug report. 2160 documented a case where the kernel reports a
> "no link beat detected" a second or so before reporting "link beat
> detected", and apparently NM sees the first and aborts trying to bring
> up the interface. In the bug, I called this aggressive timeout, but it
> may just be that NM is misinterpreting the events it sees.
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
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.
> I'll be doing a fresh install on the laptop experiencing the problem in
> the next couple of days, and I'll check to see whether the problem(s)
> still occur(s). Since no one ever posted to the bug report that it
> might be fixed, I've simply been removing the package whenever it gets
> reinstalled or on fresh installs.
> I'll wait to do the test to say this for sure, but IIRC I would
> occasionally not notice that some urpmi --auto-update had reinstalled NM
> until the wireless stopped coming up, and this was well after seeing
> your posts about blino's patch.
Then if nm does not respect the NM_CONTROLLED=no (using the rhkeyfile plugin)
then it should be reported & assigned to blino.
> > Well there's a lot of packages without maintainer ...
> Well, if we're considering doing something that has the potential of
> breaking peoples' systems, it would make sense (at least to me) to tread
> carefully unless we have someone on hand that can deal with the
> problems, no ?
Here our bug triager team looks directly @ the commits to find someone which
might be able to help on that
(because if we're looking @ http://pkgsubmit.mageia.org/data/unmaintained.txt
there's a lot of problematic packages without maintainer like at least grub :p
Jabber-id: mikala at jabber.littleboboy.net
More information about the Mageia-dev