Description of problem: When adding 'single' to the kernel command line, upstart doesn't appear to respond. The last message that is seen is the udev startup, and then it sits there doing nothing. Version-Release number of selected component (if applicable): upstart-0.3.9-5.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Add 'single' to the kernel command line 2. Let it boot 3. Watch it do nothing after udev runs Actual results: fail Expected results: work Additional info: Playing around with it a bit, I found that if you hit ctrl+alt+del while it's at the "hung" state, it will send signals to processes and then drop you into the shell prompt that you expected it to put you in to begin with. That's cute. Doing ctrl+alt+del again does the regular reboot.
hmm. WFM. What do you have in event.d that's pertinent? Maybe I fiddled with something on my install and forgot about it.
Sorry, not quite sure what you're asking here. /etc/event.d/rc1 simply has: start on runlevel 1 stop on runlevel console output script set $(runlevel --set 1 || true) if [ "$1" != "unknown" ]; then PREVLEVEL=$1 RUNLEVEL=$2 export PREVLEVEL RUNLEVEL fi exec /etc/rc.d/rc 1 end script I will note that upstart got installed as a dependency for event-compat-sysv-0.3.9-8.fc9.noarch which got pulled in by something else. So I didn't explicitly install it, if that makes a difference.
What happens if you boot with 'udevinfo' or 'udevtrace'?
(In reply to comment #3) > What happens if you boot with 'udevinfo' or 'udevtrace'? Odd. Adding udevinfo produces a massive amount of spewage from udev, then it goes to the prompt as expected. [2 minutes] udevtrace doesn't really produce any output, but it still goes to the prompt as expected. [2 minutes] Just having 'single' there without the udev* additions and it simply sits.
(In reply to comment #4) > Just having 'single' there without the udev* additions and it simply sits. After letting it sit a bit longer, eventually it says: Wait timeout. Will continue in the backgroun[FAILED] and doesn't go to the prompt.
(In reply to comment #5) > (In reply to comment #4) > > Just having 'single' there without the udev* additions and it simply sits. > > After letting it sit a bit longer, eventually it says: > > Wait timeout. Will continue in the backgroun[FAILED] > > and doesn't go to the prompt. And now it just did that without 'single' at all. udev is messing with my mind.
This appears to be more a udev issue that an upstart issue, but I could be wrong...
I agree. I'll try again with tomorrow's rawhide and see what happens.
Any news on this?
(In reply to comment #9) > Any news on this? I doubt this is an upstart issue. It's already been moved over to udev. As for new news, nothing much. udev still intermittently decided to go to lunch on my machine and I've not had time to play with it more.
Created attachment 297599 [details] photo of screen after hitting ctrl+alt+del I passed 'single udevinfo' on the command line this morning and got the udev hang. Then I hit ctrl+alt+del and took a picture. This is the screen right after I did the ctrl+alt+del
Created attachment 297600 [details] screen a bit after The screen a bit later on
The ctrl-alt-del thing is logged as 435577.
try "udevdebug" instead of "udevinfo"
(In reply to comment #14) > try "udevdebug" instead of "udevinfo" http://picasaweb.google.com/jwboyer/Udev Pretty pictures from the places udev hung when trying with udevdebug instead. I apologize in advance for the crappy quality. If you can't get to them for some reason, let me know and I'll just attach them here. Those were the only places where a noticeable delay of any duration was to be seen. The rest of the time udevdebug seemed to spew a bunch of output that scrolled too fast off of the screen. Let me know if there's more I can do.
Update the title of the bug to reflect reality at this point. The delays have happened regardless of the 'single' being present or not.
seems like problems with scsi and/or usb which devices do you have?
Stock Thinkpad z60m. I played around a bit with power on/off vs. reboot, etc. Nothing to really notice there. Occasionally it won't hang, but it does for the most part. Then I played around with having a USB key or SD card in the built-in reader during booting. Again, nothing really noticeable with that. I'm waiting for it to decide to boot so I can give you a smolts.org URL.
http://www.smolts.org/show?uuid=pub_f7e62da4-3fee-42c1-8049-e59e8a564dc1
udev-118-9.fc9 now has support for a "modprobedebug" kernel command line, which may identify a kernel module causing the delay. you also may try the new "udevnopersist" kernel command line.
http://koji.fedoraproject.org/koji/buildinfo?buildID=42806
any news on this?
(In reply to comment #22) > any news on this? Sorry. It's magically gone away with either the newer udev or a newer kernel. I tried for an afternoon last week to get it to hang through various reboot/power-off,power-on combinations and it doesn't happen any longer. Bill, have you had any kind of recreates?
No, the virt image where I saw it seems to work now.
I think we can either close this as WORKSFORME or RAWHIDE. If it happens again, I'll try to capture debug output with the new options and reopen.
Hm, I was just caught by a multiminute udev delay with kernel-2.6.25-0.172.rc7.git4.fc9.x86_64 and udev-118-11.fc9.x86_64. It eventually decided to continue when I was practically ready to hit a power button. I tried to reproduce that with "modprobedebug" but without any success. One thing is that was "not in a mood" and I did not get those delays. The other is that "modprobedebug" produces only the following on my screen: Starting udev: /sbin/start_udev: line 278: find: command not found Triggering Rest Line 278 is a closing "fi" of an an "if" starting on line 224. The problem is really here: 259 for i in $(find /sys -name modalias); do 260 modules=$(cat $i) 261 modprobe -a -v -q $modules 262 wait_for_queue $udevtimeout 263 done 264 echo "Triggering Rest" 'find' is /usr/bin/find and /usr may be not available at all at this point (as is the case on my system). I guess that /bin/awk is already present and "for" could loop through a list produced in awk with a help of 'stat' and 'chdir' functions. Not even that difficult (although not worth to bother if it is not going to be used). Do you still want this closed? It does not look that I can reproduce the issue on demand.