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 #1 We can expect problem when 2 system are trying to interfere with the same hardware. > > > 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 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. [...] > > 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 ) Regards, -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net