Bug 218234

/lib/udev/udev_run_hotplugd is provided by udev. Tag!

do find something in /var/log/messages?
maybe you could boot with udevdebug in the kernel command line?

> do find something in /var/log/messages?

Quoting myself: "failed to find something in logs". Unfortunately.
This happens before anyting is mounted although syslogd should be
already running.

> maybe you could boot with udevdebug in the kernel command line?

Smells to me like some kind of a race so 'udevdebug' will likely
disturb that sufficiently enough. :-)  In any case - this is producing
so much output that if "abnormal exit" appears there somewhere
it is not likely to be noticed and I am not sure if everything is
logged.

I attach below two udev traces from logs.  One from a boot
to level 3 and another to level 5 with rhgb and all that jazz.
When booting to level 3 I later found in dmesg output, although not
in /var/log/messages, the following:

kobject_add failed for vcs1 with -EEXIST, don't try to register things with the
same name in the same directory.
 [<c04051db>] dump_trace+0x69/0x1af
 [<c0405339>] show_trace_log_lvl+0x18/0x2c
 [<c04058ed>] show_trace+0xf/0x11
 [<c04059ea>] dump_stack+0x15/0x17
 [<c04e52f2>] kobject_add+0x165/0x18e
 [<c0553703>] class_device_add+0xa2/0x3de
 [<c0553ad1>] class_device_create+0x82/0xa2
 [<c05373f0>] vcs_make_devfs+0x3c/0x7e
 [<c053c2bf>] con_open+0x6f/0x7c
 [<c0532bfe>] tty_open+0x1e2/0x369
 [<c0476eca>] chrdev_open+0xfb/0x12f
 [<c046de32>] __dentry_open+0xc7/0x1ab
 [<c046df90>] nameidata_to_filp+0x24/0x33
 [<c046dfd1>] do_filp_open+0x32/0x39
 [<c046e01a>] do_sys_open+0x42/0xbe
 [<c046e0cf>] sys_open+0x1c/0x1e
 [<c0404013>] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb
Leftover inexact backtrace:
 =======================
kobject_add failed for vcsa1 with -EEXIST, don't try to register things with the
same name in the same directory.
 [<c04051db>] dump_trace+0x69/0x1af
 [<c0405339>] show_trace_log_lvl+0x18/0x2c
 [<c04058ed>] show_trace+0xf/0x11
 [<c04059ea>] dump_stack+0x15/0x17
 [<c04e52f2>] kobject_add+0x165/0x18e
 [<c0553703>] class_device_add+0xa2/0x3de
 [<c0553ad1>] class_device_create+0x82/0xa2
 [<c053742d>] vcs_make_devfs+0x79/0x7e
 [<c053c2bf>] con_open+0x6f/0x7c
 [<c0532bfe>] tty_open+0x1e2/0x369
 [<c0476eca>] chrdev_open+0xfb/0x12f
 [<c046de32>] __dentry_open+0xc7/0x1ab
 [<c046df90>] nameidata_to_filp+0x24/0x33
 [<c046dfd1>] do_filp_open+0x32/0x39
 [<c046e01a>] do_sys_open+0x42/0xbe
 [<c046e0cf>] sys_open+0x1c/0x1e
 [<c0404013>] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb
Leftover inexact backtrace:
 =======================

and that seems to related to udevd operations.  These backtraces
were not repeated when booting to level 5 although another boot
to level 3 produced those again.  OTOH I cannot tell when I will
see "abnormal exit" the next time and I never encoutered such
thing when booting to level 3 (although this may be "luck";
I was not doing that as often as a "normal" boot).

Created attachment 142875 [details]
udevdebug output from a "level 3" boot

Created attachment 142876 [details]
udevdebug output from a "normal" boot

Oops! I should add. Backtraces in comment #3 are from 2.6.18-1.2849.fc6
kernel.

One more clarification to comment #3.  When booting to level 3 _without_
'udevdebug' I am not seeing backtraces as quoted there; or at least it
did not happen when I was checking.

still a problem with latest kernel/udev/fedora versions?

> still a problem with latest kernel/udev/fedora versions?

I did not notice anything like that on a few tries with
2.6.22.5-49.fc6.  OTOH this was showing up only sporadically
so, unless an underlying cause is determined, who knows?

Fixed in recent F8?

I did not observe that for a long time so I guess that it is gone
although noticing that never was easy.  OTOH comment #9 still applies.

As far as I can interpret, the backtraces are from kernel drivers trying to
register files in sysfs. Namely "vcs1" and "vcsa1". Maybe a framebuffer module
not listed in /etc/modprobe.d/blacklist-compat.

maybe a kernel guy can give more information on comment #3 ?

The backtrace from a comment #3 may, or may not, be releated to
those abnormal exits.  In any case this was a while.

AFAICT _currently_ framebuffer modules are listed in
/etc/modprobe.d/blacklist-compat.  If your guess is correct that
would prevent the problem from showing up.

The issue was reported well over a year ago and I am afraid that
currently all setup from that time (configurations, software versions)
is impossible for me to reproduce.  It now apparently vanished so,
unless somebody has some insights to share, I would think that this
could be closed.

(In reply to comment #13)
> maybe a kernel guy can give more information on comment #3 ?

That was an old kernel bug that was causing duplicate virtual console names to
be registered.

close?

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers