From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-November/009710.html | 170 +++++++++++++++++++++++++++ 1 file changed, 170 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-November/009710.html (limited to 'zarb-ml/mageia-dev/2011-November/009710.html') diff --git a/zarb-ml/mageia-dev/2011-November/009710.html b/zarb-ml/mageia-dev/2011-November/009710.html new file mode 100644 index 000000000..fbbdc3b63 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-November/009710.html @@ -0,0 +1,170 @@ + + + + [Mageia-dev] Drakx-net or NetworkManager for Mageia 2 + + + + + + + + + +

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

+ Balcaen John + 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 
+#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: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1