| Summary: | Segfaults with NetworkManager-0.9.3-0.1.git20120215.fc17.x86_64 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> | ||||
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 17 | CC: | dcbw, orion | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | NetworkManager-0.9.3-0.2.git20120215.fc17 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-02-21 02:23:20 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
NetworkManager-0.9.3-0.2.git20120215.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/NetworkManager-0.9.3-0.2.git20120215.fc17 Segfault is due to mismatch between libnl and libnl3 in the WiMAX code; NM uses libnl3 but we haven't rebuilt the wimax stack or wpa_supplicant for libnl3 in F17 yet, and NM was including the wimax plugin in the main package instead of where it should have been, in the -wimax subpackage which isn't installed by default. Update fixes the location of the wimax plugin. Oh, and the reason that NM tries to start p2p1 all the time is that it's a really really old ne2kpci card which doesn't support carrier detection, and so NM has to assume the carrier is always on for that card, and thus start it up. There are two ways to fix that; either create a new Ethernet connection that's locked to the ne2kpci device's MAC address, and set it to not "connect automatically", or blacklist that device from NM's control. Unless the kernel drivers changed this should have always been how NM worked for this device; if there's no carrier detection support in the driver then the carrier is always on. Package NetworkManager-0.9.3-0.2.git20120215.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.3-0.2.git20120215.fc17' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-1909/NetworkManager-0.9.3-0.2.git20120215.fc17 then log in and leave karma (feedback). NetworkManager-0.9.3-0.2.git20120215.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 563924 [details] output of grep "Netw" /var/log/messages [ The following background may be unrelated, but I'd like to point out that the NetworkManager included with F-17 Alpha TC2 x86_64 has not worked flawlessly here compared with F-16. The DVD image based install of default GNOME Desktop resulted in NM refusing to fire up my p37p1 Ethernet connection and being stuck in a loop trying to start a secondary connection to a LAN that's offline. No option to tell it to stop doing that, and for the desired connection only "ifup p37p1" worked. I've mentioned that on test list.] Then this morning there has been a test update: # grep Net yum.log Feb 17 11:20:43 Updated: 1:NetworkManager-glib-0.9.3-0.1.git20120215.fc17.x86_64 Feb 17 11:20:44 Updated: 1:NetworkManager-gtk-0.9.3-0.1.git20120215.fc17.x86_64 Feb 17 11:20:49 Updated: 1:NetworkManager-0.9.3-0.1.git20120215.fc17.x86_64 Feb 17 11:20:59 Updated: 1:NetworkManager-gnome-0.9.3-0.1.git20120215.fc17.x86_64 Rebooting the machine now kills NM as it segfaults. Even its icon at the top right panel of GNOME Shell vanishes. ABRT claims that it stored the backtrace, but abrt-gui doesn't list any NetworkManager issue.