Bug 141774

Summary: udev does not FAIL SAFE (on older kernels lacking initio)
Product: [Fedora] Fedora Reporter: Stig Hackvan <stig-redhat-bugzilla>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-27 06:17:45 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Stig Hackvan 2004-12-03 13:13:30 EST
Description of problem:

The last known-to-work with my usb-attached dvd+rw drive was
kernel-2.6.6-1.435....  but udev can't live with that kernel.  Udev
should be able to work in a failsafe mode when a system with udev is
booted on an older kernel.  OR perhaps the init script for udev should
be able to see that initio isn't present and create the dev tree with

-- stig
Comment 1 Harald Hoyer 2004-12-03 13:22:01 EST
what is initio???
Comment 2 Stig Hackvan 2004-12-03 14:11:58 EST
Ummmmmmmmmmm, okay...it seems i was half-confused:  initio is the
kernel module for the pci scsi card that i occasionally use for my
scanner and has nothing to do with udev...

but udev is where the boot process gets stuck with an older kernel...
  instead, it should do something "safe" when a kernel doesn't have
the hooks udev needs to operate.

-- stig
Comment 3 Harald Hoyer 2004-12-03 15:21:05 EST
Well, all 2.6 kernels do have what udev needs, except you compiled
your own kernel and did not include sysfs support...
Another possibility is that do you do not use an initrd. In this case
Which version of udev do you have? Try updating udev, if you have the
original udev version.
Comment 4 Stig Hackvan 2004-12-04 22:53:24 EST
the system having difficulties is fc3+some_freshrpms.  because of
gnome problems, i meticulously purged most older fc2 packages.

the fc2 package for kernel-2.6.6-1.435 was rebuilt (on fc3) from the
fc2 src.rpm and does include an initrd image...which includes udev...

when the kernel was installed, i recall a complaint about kernel
module initio missing (the initrd image was created by a post-install
script, right?)...  as it happens, initio is the driver for an unused
pci scsi card in that system, so it's moot...but that's what led me to
assume the cause of udev hanging the boot process...  i'll try to play
with it a bit more tomorrow, but for the meantime, here's the contents
of initrd...

would i have better luck with a pre-compiled binary fc2 rpm of the
kernel in question?   perhaps a compiler-related glitch could be biting?

total 4
drwxrwxr-x  2 root root 160 Dec  4 19:38 bin/
drwxrwxr-x  2 root root 200 Dec  4 19:38 dev/
drwxrwxr-x  3 root root  60 Dec  4 19:38 etc/
-rwxrwxr-x  1 root root 839 Dec  4 19:38 init*
drwxrwxr-x  2 root root 120 Dec  4 19:38 lib/
drwxrwxr-x  2 root root  40 Dec  4 19:38 loopfs/
drwxrwxr-x  2 root root  40 Dec  4 19:38 proc/
lrwxrwxrwx  1 root root   3 Dec  4 19:38 sbin -> bin/
drwxrwxr-x  2 root root  40 Dec  4 19:38 sys/
drwxrwxr-x  2 root root  40 Dec  4 19:38 sysroot/

total 596
lrwxrwxrwx  1 root root     10 Dec  4 19:38 hotplug -> /sbin/nash*
-rwxr-xr-x  1 root root  12920 Dec  4 19:38 insmod*
lrwxrwxrwx  1 root root     10 Dec  4 19:38 modprobe -> /sbin/nash*
-rwxr-xr-x  1 root root  37704 Dec  4 19:38 nash*
-rwxr-xr-x  1 root root 541716 Dec  4 19:38 udev*
lrwxrwxrwx  1 root root      4 Dec  4 19:38 udevstart -> udev*

total 0
crw-rw-r--  1 root root 5, 1 Dec  4 19:38 console
crw-rw-r--  1 root root 1, 3 Dec  4 19:38 null
brw-rw-r--  1 root root 1, 1 Dec  4 19:38 ram
crw-rw-r--  1 root root 4, 0 Dec  4 19:38 systty
crw-rw-r--  1 root root 4, 1 Dec  4 19:38 tty1
crw-rw-r--  1 root root 4, 2 Dec  4 19:38 tty2
crw-rw-r--  1 root root 4, 3 Dec  4 19:38 tty3
crw-rw-r--  1 root root 4, 4 Dec  4 19:38 tty4

total 0
drwxrwxr-x  2 root root 60 Dec  4 19:38 udev/

total 4
-rw-r--r--  1 root root 1128 Dec  4 19:38 udev.conf

total 320
-rw-rw-r--  1 root root 119284 Dec  4 19:38 ext3.ko
-rw-rw-r--  1 root root  52532 Dec  4 19:38 jbd.ko
-rw-rw-r--  1 root root 118096 Dec  4 19:38 scsi_mod.ko
-rw-rw-r--  1 root root  16328 Dec  4 19:38 sd_mod.ko

total 0

total 0

total 0

total 0

Comment 5 Stig Hackvan 2004-12-06 17:58:26 EST
harald, i have more information on this hang in /sbin/udev_start ...

Using the precompiled FC2 update-channel-binary-rpm from my apt-cache,
i rebooted and got the same hang.  i rebooted again single user...and
got the same hang...pressing ^C, however, got me to the shell prompt
where i ran 'sh -x /sbin/udev_start' and found that output stopped
when the function kill_udevd was called...  I pressed ^Z and put that
job in the background, then tried 'pstree -paul | egrep -A9 $$' to see
what processes were associated with udev_start and that command hung...

so it's seeming like /sbin/pidof and/or pstools might be the problem.
 please verify and reassign this bug if you have a better diagnostic
hack...  but i didn't find that pstools were hosed for sure and the
basic appearance of this boot-time-lockup is still that FC3 boot hangs
in udev_start when running with an older kernel....specifically this

-- ...ar-cache-apt-FC2+/archives > rpm -qip
Name        : kernel                       Relocations: (not relocatable)
Version     : 2.6.6                             Vendor: Red Hat, Inc.
Release     : 1.435.2.3                     Build Date: Thu 01 Jul
2004 05:49:45 AM PDT
Install Date: (not installed)               Build Host:
Group       : System Environment/Kernel     Source RPM:
Size        : 35220692                         License: GPLv2
Signature   : DSA/SHA1, Thu 01 Jul 2004 02:07:31 PM PDT, Key ID
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : The Linux kernel (the core of the Linux operating system).
Description :
The kernel package contains the Linux kernel (vmlinuz), the core of
the Red Hat Linux operating system. The kernel handles the basic
functions of the operating system: memory allocation, process
allocation, device input and output, etc.
Comment 6 Harald Hoyer 2004-12-07 06:27:44 EST
could you remove the kill_udev lines from start_udev and retry? They
are not that important.
Comment 7 Harald Hoyer 2004-12-07 06:30:56 EST
btw, which version of udev do you have?

Please try udev-039-10.FC3.5 from 

Comment 8 Stig Hackvan 2004-12-09 17:02:39 EST
I am using the latest released udev and commenting out the calls to
pidof and kill did get the boot process past udev_start only to hang
after mounting swap partitions.  i'll see what i can find out and
report it elsewhere in the bug system, but if someone there could help
work on this, i think it's critical...  

pidof/kill shouldn't hang on such a recent kernel.  My system has been
crippled for weeks thanks to FC3 and the usb-storage bugs that are
causing it have been filed against the kernel for quite some time.
Comment 9 Stig Hackvan 2004-12-09 23:02:14 EST
harald, i rebooted again with bash -x in /etc/rc.d/rc.sysinit and the
hang after mounting swap partitions was (again) /sbin/pidof from
sysVinit, so I think this is NOT a udev bug...it's a sysVinit bug. 
I'm going to file a new report there and reference this bug.
Comment 10 Stig Hackvan 2004-12-13 14:22:08 EST
harald, this is filed also as bug # 142516...  do you think you could
nudge to get that bug "assigned"...
Comment 11 Harald Hoyer 2004-12-14 07:59:29 EST
sorry, no chance..