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 makedevs... -- stig
what is initio???
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
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 read: http://fedora.redhat.com/docs/udev/ Which version of udev do you have? Try updating udev, if you have the original udev version.
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/ ./bin: 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* ./dev: 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 ./etc: total 0 drwxrwxr-x 2 root root 60 Dec 4 19:38 udev/ ./etc/udev: total 4 -rw-r--r-- 1 root root 1128 Dec 4 19:38 udev.conf ./lib: 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 ./loopfs: total 0 ./proc: total 0 ./sys: total 0 ./sysroot: total 0
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 kernel: -- ...ar-cache-apt-FC2+/archives > rpm -qip kernel-2.6.6-1.435.2.3.i686.rpm 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: tweety.build.redhat.com Group : System Environment/Kernel Source RPM: kernel-2.6.6-1.435.2.3.src.rpm Size : 35220692 License: GPLv2 Signature : DSA/SHA1, Thu 01 Jul 2004 02:07:31 PM PDT, Key ID b44269d04f2a6fd2 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.
could you remove the kill_udev lines from start_udev and retry? They are not that important.
btw, which version of udev do you have? Please try udev-039-10.FC3.5 from http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/udev-039-10.FC3.5.i386.rpm
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.
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.
harald, this is filed also as bug # 142516... do you think you could nudge to get that bug "assigned"...
sorry, no chance..