Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, "ps -ef"
shows a "sh -e /lib/udev/net.agent" running with a PPID of 1. This
process doesn't exit until I reboot. If this is normal under the
circumstances, please disregard.
Does SysRq-T show where it hangs?
Ummm... No. I didn't have the CONFIG_MAGIC_SYSRQ flag set, so I set it,
and recompiled the kernel. Guess what - now the system comes up
normally without any problem. The block devices appear in /dev. To
recap: without CONFIG_MAGIC_SYSRQ on the 2.6.24-rc3 kernel the missing
block devices error in /dev occurs and the init scripts fall over on
startup, and with CONFIG_MAGIC_SYSRQ the system comes up normally.
To answer the earlier questions about distro, and udev version, my
system is similar to Bob's, except that I am running Debian
testing/lenny which comes with udev version 114 (dpkg reports udev
version 0.114-2). I am running an EV67 variant CPU.
I do not run an initramfs - I have the necessary drivers for the various
discs compiled into the kernel and use the root kernel option to point
to the required root partition.
When running the broken kernel udev is running (according to 'ps') and
executing /sbin/udevtrigger manually generates a number of errors of the
form:
scsi_id[<pid>]: scsi_id: unable to access '/block'
The missing /dev/* entries do not appear.
Cheerz
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
