Red Hat Bugzilla – Bug 504800
udev stalls starting up and computer doesn't boot
Last modified: 2009-06-30 07:14:21 EDT
Created attachment 347034 [details]
output of strace -s 512 -f -o /root/udev.log /bin/bash -x /sbin/start_udev
Last night before I left work I ran:
and suspended my laptop. This is the first time I've done that in a long time. Normally I just power off.
This morning on the bus ride to work I opened the computer and resumed. It surprisingly worked fine. I'm only mentioning the above, because suspend and resume is not something I do.
In the middle of the bus ride I tried to reboot the machine. It went down okay, but during boot up it would stall at "Starting udev: "
From there I booted with init=/bin/sh udevtrace udevinfo on my kernel command line and run:
setsid /bin/bash -i < /dev/tty1
mount -oremount,rw /
mount devpts /dev/pts -t devpts
strace -s 512 -f -o /root/udev.log /bin/bash -x /sbin/start_udev
and looked at the log in one screen window while watching the udev output in another.
I got a little confused reading the strace logs. If I ran ps -ef |grep udev, udevd was not running, but according the strace logs it looks like it never exited or crashed.
Anyway the last line in the udev debug spew was:
run /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.2/7-1.2:1.0 (895) '/usr/sbin/pcscd --hotplug'
So I tried
and rebooting the macine. After that the machine came up. I don't know if that's a red herring though, because it continues to boot now even though I've moved the pcscd binary back.
Another interesting fact, since this morning's events my system clock seems to be hosed. Whenever I boot the machine the time is off by several hours. The minutes are fine, though. It doesn't appear to be some utc-edt confusion because the delta is bigger than the the difference between utc and edt. There may be some bizarre hardware failure going on here.
I'm just filing the bug report so the strace is saved. Feel free to close it out WORKSFORME or whatever.
pcscd would have been killed after 3 minutes and even after 30 seconds your system should have continued, so I guess this was a kernel/hardware hiccup.
Haven't heard about such a bug elsewhere... and you can't reproduce it.. sorry.