Description of problem: After an upgrade from F7 to F8 (using yum), udev is delaying the boot of my notebook by approx. 30 s. After that it accomplishes with [OK] and the booting process continues further without any problems. However, starting udev on the running machine takes only a few seconds to finish successfully. Version-Release number of selected component (if applicable): udev-116-3.fc8 How reproducible: Start the machine in a normal way:) Actual results: It takes 1 minute and 39 seconds to display the login screen. Expected results: To start as fast as F7 before (i. e. without the 30s delay caused by udev) Additional info: My smolt profile: http://www.smolts.org/show?UUID=55a52104-7e4f-429d-a078-8399bea27530 I've also attached the output of bootchart and of /var/log/message (obtained by setting udev_log="debug" in /etc/udev/udev.conf).
Created attachment 288011 [details] Bootchart output
Created attachment 288021 [details] /var/log/messages (with udev_log="debug")
Dec 4 17:50:34 localhost kernel: iwl3945: iwlwifi-3945-1.ucode firmware file req failed: Reason -2 you better install the firmware.. # yum install iwl3945-firmware after that the boot process should be back to normal
That's strange because this package has been already installed: >yum list iwl3945-firmware --noplugins Installed Packages iwl3945-firmware.noarch 2.14.1.5-2 installed If I remove the file /lib/firmware/iwlwifi-3945-1.ucode, it starts normally (udev succeeds within 3 seconds), however the wifi doesn't work of course. I also tried to reinstall the package (i. e. uninstall and install again -- using yum) which resulted in the same trouble. Is that an iwl3945 issue? Shall I file a bug against that package?
hmm, yes I would file a bug against the kernel or iwl3945. worksforme > Dec 4 17:50:34 localhost kernel: iwl3945: iwlwifi-3945-1.ucode firmware file > req failed: Reason -2 Don't know what "Reason -2" is..
I have just tried also the current firmware from http://intellinuxwireless.org (version 2.14.4) with no change:(
A workaround for this issue is to blacklist iwl3945 and modprobe it in rc.local.
Reassigning to the kernel, since this doesn't seem firmware or udev related...
I just had time to setup a small clean install on another partition and everything worked fine. After some diffing I found out that the problem was in the udev rule in 70-persistent-net.rules: >cat /etc/udev/rules.d/70-persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit Ethernet Controller SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:e4:bb:66:b9", ATTR{type}=="1", NAME="eth0" # PCI device 0x8086:0x4222 (iwl3945) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:de:36:fd:cc", ATTR{type}=="1", NAME="wlan0" On the previous installation (upgraded via yum as mentioned above) the ATTR{type} section was missing. After adding it udev starts within a few seconds during boot. I've attached also the precise diff between the two rule files. I don't know what has caused this (udev, anaconda, kernel?), anyway if nobody will care about I'll close this bug in one week as CANTFIX.
Created attachment 297230 [details] Diff between the correct and corrupted udev rule.
ATTR{type}=="1" was missing in some udev versions in the development cycle... maybe it is a leftover from these times?
What kind of development cycle do you mean? I've never used F8-rawhide, but I use the updates-testing repo...but I don't think this could cause the problem, newer package would install the correct version (I know that the rules are config(noreplace) files, but I regularly search the drive for .rpmsave/.rpmnew files). Does NetworkManager or system-config-network edit these files? Anyway, as I'm as far the only one reporting this issue, I wouldn't waste time by that now. I think, it is important that you know that missing ATTR{type}=="1" can lead to such problems, so if anybody else would complain, you know where to look:)
(In reply to comment #12) > What kind of development cycle do you mean? I've never used F8-rawhide, but I > use the updates-testing repo...but I don't think this could cause the problem, > newer package would install the correct version (I know that the rules are > config(noreplace) files, but I regularly search the drive for .rpmsave/.rpmnew > files). Well, they were generated on the fly by udev. So, yes, updates-testing could have been the problem. > > Does NetworkManager or system-config-network edit these files? no, generated by udev > > Anyway, as I'm as far the only one reporting this issue, I wouldn't waste time > by that now. I think, it is important that you know that missing ATTR{type}=="1" > can lead to such problems, so if anybody else would complain, you know where to > look:) There have been similar bugzillas with the same problem in the development/testing cycle. Maybe, I should have posted a mail with a warning on fedora-testing.