Bug 1199098
| Summary: | Wired networking does not work on Lenovo T540p | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stephen Gallagher <sgallagh> |
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | dcbw, jreznik, psimerda, robatino, satellitgo, sgallagh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | AcceptedBlocker | ||
| Fixed In Version: | NetworkManager-1.0.0-7.fc22 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-07 00:08:36 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1193127 | ||
| Bug Blocks: | 1043121 | ||
|
Description
Stephen Gallagher
2015-03-05 13:16:45 UTC
Proposed as a Blocker for 22-alpha by Fedora user sgallagh using the blocker tracking app because: Violates criterion: "The installed system must be able to download and install updates with the default console package manager." Thus far, this appears to be limited to certain hardware and can be worked around by only using the wireless connection, which is non-ideal but may be acceptable for *Alpha*. Stephen, can you check these things for me when you get into this situation? ls -al /etc/resolv.conf cat /etc/resolv.conf ip addr ip route THanks! "The machine has no IP address and /etc/resolv.conf is a broken symlink to /var/run/NetworkManager/resolv.conf" was in the original message :) /var/run/NetworkManager/resolv.conf is nonexistent, so cat /etc/resolv.conf returns nothing. I'll get you 'ip addr' and 'ip route' momentarily. It turns out I was incorrect about the original degree of reproducibility. It happened consistently on two boots, but when I just booted for this information, it didn't happen until I pulled the cable and replaced it (with about a 1-2s pause between pulling and replacing). So it seems like there may be an easy-to-hit race somewhere. Anyway, here's the info you requested, plus a systemctl status NetworkManager showing the hung dhclient call.
[sgallagh@sgallagh540:~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 54:ee:75:10:2a:8e brd ff:ff:ff:ff:ff:ff
inet6 2620:52:0:1218:56ee:75ff:fe10:2a8e/64 scope global noprefixroute dynamic
valid_lft 2591997sec preferred_lft 604797sec
inet6 fe80::56ee:75ff:fe10:2a8e/64 scope link
valid_lft forever preferred_lft forever
3: wlp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether e8:2a:ea:08:3e:c8 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 52:54:00:b2:62:5c brd ff:ff:ff:ff:ff:ff
inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 500
link/ether 52:54:00:b2:62:5c brd ff:ff:ff:ff:ff:ff
[sgallagh@sgallagh540:~]$ ip route
192.168.124.0/24 dev virbr0 proto kernel scope link src 192.168.124.1
[sgallagh@sgallagh540:~]$ systemctl status NetworkManager
● NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2015-03-05 08:51:17 EST; 2min 40s ago
Main PID: 1083 (NetworkManager)
CGroup: /system.slice/NetworkManager.service
├─1083 /usr/sbin/NetworkManager --no-daemon
└─3386 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-enp0s25.pid -lf /var/lib/NetworkManager/dhclient-0077bd39-0b06-4536-a07c-0f60d709a1a5-enp0s25.lease -cf /var/lib/NetworkManager/dhclient-enp0s25.conf enp0s25
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> NetworkManager state is now CONNECTING
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Error resolving 'fedoraproject.org': No address associated with hostname'.
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> NetworkManager state is now CONNECTED_SITE
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> NetworkManager state is now CONNECTING
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Error resolving 'fedoraproject.org': No address associated with hostname'.
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> NetworkManager state is now CONNECTED_SITE
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> NetworkManager state is now CONNECTING
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Error resolving 'fedoraproject.org': No address associated with hostname'.
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> NetworkManager state is now CONNECTED_SITE
Mar 05 08:53:58 sgallagh540.sgallagh.rht NetworkManager[1083]: <info> NetworkManager state is now CONNECTING
I'm building http://koji.fedoraproject.org/koji/taskinfo?taskID=9142905 with a backport to fix the connectivity loop thing, which might help reduce the noise. Stephen, so what's going on here (and why NM says you are connected) is because you have IPv6 connectivity. So in reality, you do have internet connectivity because you have a global IPv6 address. You just don't have IPv4 connectivity yet, because DHCP is still happening... the original logs had too much connectivity checking spew to show the continuing DHCPv4 requests and any replies. I think the connectivity loop thing is getting in the way a bit, so lets get that update posted and then get some clean logs if you have a bit of time? NetworkManager-1.0.0-7.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/NetworkManager-1.0.0-7.fc22 Package NetworkManager-1.0.0-7.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-1.0.0-7.fc22' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-3298/NetworkManager-1.0.0-7.fc22 then log in and leave karma (feedback). Discussed at yesterday's Go/No-Go meeting. This bug was accepted as Alpha Blocker - This bug is a clear violation of the alpha criterion: "The installed system must be able to download and install updates with the default console package manager." NetworkManager-1.0.0-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. |