Bug 424321 - udev is starting ca. 30 seconds on booting
udev is starting ca. 30 seconds on booting
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
8
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-13 16:32 EST by Milos Jakubicek
Modified: 2008-03-13 17:01 EDT (History)
1 user (show)

See Also:
Fixed In Version: udev-118-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-13 17:01:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Bootchart output (215.27 KB, image/png)
2007-12-13 16:32 EST, Milos Jakubicek
no flags Details
/var/log/messages (with udev_log="debug") (257.37 KB, text/plain)
2007-12-13 16:34 EST, Milos Jakubicek
no flags Details
Diff between the correct and corrupted udev rule. (954 bytes, text/plain)
2008-03-07 13:04 EST, Milos Jakubicek
no flags Details

  None (edit)
Description Milos Jakubicek 2007-12-13 16:32:01 EST
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).
Comment 1 Milos Jakubicek 2007-12-13 16:32:01 EST
Created attachment 288011 [details]
Bootchart output
Comment 2 Milos Jakubicek 2007-12-13 16:34:23 EST
Created attachment 288021 [details]
/var/log/messages (with udev_log="debug")
Comment 3 Harald Hoyer 2007-12-14 05:56:15 EST
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
Comment 4 Milos Jakubicek 2007-12-14 17:03:50 EST
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?
Comment 5 Harald Hoyer 2008-01-10 10:53:05 EST
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..
Comment 6 Milos Jakubicek 2008-01-10 13:06:36 EST
I have just tried also the current firmware from http://intellinuxwireless.org
(version 2.14.4) with no change:(
Comment 7 Milos Jakubicek 2008-01-12 05:51:30 EST
A workaround for this issue is to blacklist iwl3945 and modprobe it in rc.local.
Comment 8 Matthias Saou 2008-02-03 07:05:21 EST
Reassigning to the kernel, since this doesn't seem firmware or udev related...
Comment 9 Milos Jakubicek 2008-03-07 13:01:15 EST
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.

Comment 10 Milos Jakubicek 2008-03-07 13:04:05 EST
Created attachment 297230 [details]
Diff between the correct and corrupted udev rule.
Comment 11 Harald Hoyer 2008-03-13 12:09:41 EDT
ATTR{type}=="1" was missing in some udev versions in the development cycle...
maybe it is a leftover from these times?
Comment 12 Milos Jakubicek 2008-03-13 16:22:37 EDT
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:)
Comment 13 Harald Hoyer 2008-03-13 17:01:19 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.