Created attachment 660390 [details] ifcfg file Description of problem: Sometime in the end of November the "network" service stopped activating my Wifi interface during boot. It brings up the two wired interfaces correctly, but not the wireless one. I have to run "ifup wifi" manually to get it up. Version-Release number of selected component (if applicable): initscripts-9.37.2-1.fc17.x86_64 kernel-3.6.9-2.fc17.x86_64 Initscripts 9.37.2 seemed to work fine when I installed it, but shortly after that it stopped bringing up the Wifi interface. How reproducible: Ever since I first noticed the problem it has happened every time I've had a reason to reboot. Steps to Reproduce: 1. Boot. 2. Log in. 3. Check the state of the network interfaces with ifconfig and iwconfig. Actual results: [root@hactar ~]# ifconfig wifi wifi: flags=4098<BROADCAST,MULTICAST> mtu 1500 ether 00:16:6f:a9:95:34 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@hactar ~]# iwconfig wifi wifi IEEE 802.11bg ESSID:off/any Mode:Managed Channel:0 Access Point: Not-Associated Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0 Retry limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Expected results: [root@hactar ~]# ifconfig wifi wifi: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.96.1 netmask 255.255.255.0 broadcast 192.168.96.255 inet6 2002:57e3:175f:96::1 prefixlen 64 scopeid 0x0<global> inet6 fe80::216:6fff:fea9:9534 prefixlen 64 scopeid 0x20<link> ether 00:16:6f:a9:95:34 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 25 bytes 4370 (4.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@hactar ~]# iwconfig wifi wifi IEEE 802.11bg ESSID:"Rombo" Nickname:"hactar.xn--rombobjrn-67a.se" Mode:Ad-Hoc Frequency:2.442 GHz Cell: 02:16:6F:18:E7:49 Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0 Retry limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=67/100 Signal level=-60 dBm Noise level=-85 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Additional info: The log contains messages from /etc/sysconfig/network-scripts/ifup-eth saying approximately "The device wifi doesn't seem to exist, delaying initialization." Systemctl reports a failed status: [beorn@hactar ~]$ systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed (Result: exit-code) since Sun, 09 Dec 2012 00:18:23 +0100; 18h ago Process: 680 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/network.service └ 1073 /sbin/dhclient -H hactar -q -lf /var/lib/dhclient/dhclient--world.lease -pf /var/run/dhclient-world.pid world lspci identifies the Wifi card as "Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)".
Created attachment 660391 [details] system log
What happens if you apply http://git.fedorahosted.org/cgit/initscripts.git/commit/?id=f386b81c2fa48fe9f66bdb446cde99f99ae44912 ? (The issue appears to be that the interface isn't getting renamed properly.)
I made that change to /usr/lib/udev/rules.d/60-net.rules and rebooted six times. The Wifi interface came up every second time. It might seem like the chance of success increased to 50%, but that's probably just chance. I wouldn't expect that rule to have any effect, because based on my limited understanding of Udev rules I think these rules in /etc/udev/rules.d/01-network-interface-naming.rules take precedence: SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:d0:bc", NAME:="world" SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:cd:e5", NAME:="gigabit" SUBSYSTEM=="net", ATTR{address}=="00:16:6f:a9:95:34", NAME:="wifi" I wrote that file because the interface names were changing on every reboot, making it impossible to configure pretty much anything network-related. That problem began when I installed Fedora 17. I pieced together those rules based on hints I found on various blogs. Since then the interface names are always right when the boot is finished, so it seems to me that the interfaces do get renamed properly now, but I suppose it might happen too late. Is there anything I should change to ensure that the renaming happens before the network scripts run?
You really want ACTION=="add" there, I think.
OK. That didn't solve the problem though. I had three failures in ten reboots, so there is still a race.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.