From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
When booting in graphical mode (/etc/sysconfig/init:GRAPHICAL=yes)
the boot process goes up to 'starting networking', then hangs (the little
rotary icon stops moving ;-)

When booting in text mode (/etc/sysconfig/init:GRAPHICAL=no) or having
clicked 'show details' once X comes up and starts to show the boot
progress bar, the boot process proceeds normally.

Analysis:

When the boot 'hangs' it is actually waiting for "rhgb-client". Once the
rotary icon stopped moving during 'starting networking', I could SSH into
the machine (the network was up) and get the process list.

One can see process "/usr/bin/rhgb-client --update=rawdevices"
doing nothing in particular. GDB shows a not very informative backtrace:

#0  0x0056a7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0064ab01 in connect () from /lib/tls/libc.so.6
#2  0x08048fcb in ?? ()
#3  0x00000004 in ?? ()
#4  0x096f8a68 in ?? ()
#5  0x0000006e in ?? ()
#6  0xbfe7d65c in ?? ()
#7  0x00000004 in ?? ()
#8  0x00000000 in ?? ()

A kill of that process brings us one step forward, a new rghb-client 
process shows up which hangs in turn:

/usr/bin/rhgb-client --update=gpm
/usr/bin/rhgb-client --update=crond

etc..

These processes are only started in graphical boot according to 
/etc/rc.d/init.d/functions:

update_boot_stage() {
  if [ "$GRAPHICAL" = "yes" -a -x /usr/bin/rhgb-client ]; then
    /usr/bin/rhgb-client --update="$1"
  fi
  return 0
}

This explains the differing behaviour in graphical and non-graphical boot.







Version-Release number of selected component (if applicable):
rhgb-0.14.1-5

How reproducible:
Always

Steps to Reproduce:
1. Start machine in graphical boot 
2. Boot process proceeds up to networking
3.

Actual Results:  Boot process hangs at "starting networking"

Expected Results:  Boot process should continue normally or timeout in rhgb-client

Additional info:

Possible hardware dependency:

This problem has only been encounterd on a Fujitsu-Siemens
Primery L100 (a weird machine if ever ever saw one), RHN sid=1005558364.

There is no problem on a Fujitsu-Siemens Primergy RX300 S2 on the same
network.

Here is the extract from the log of a successful boot:

Jun 14 13:12:10 rei2 sysstat: Calling the system activity data collector (sadc):
Jun 14 13:12:10 rei2 sysstat:
Jun 14 13:12:10 rei2 rc: Starting sysstat:  succeeded
Jun 14 13:12:29 rei2 smartd: smartd startup succeeded
Jun 14 13:12:10 rei2 readahead_early: Starting background readahead:
Jun 14 13:12:11 rei2 rc: Starting readahead_early:  succeeded
Jun 14 13:12:16 rei2 kudzu:  succeeded
Jun 14 13:12:19 rei2 iptables:  succeeded
Jun 14 13:12:20 rei2 rc: Starting pcmcia:  succeeded
Jun 14 13:12:29 rei2 acpid: acpid startup succeeded
Jun 14 13:12:20 rei2 sysctl: net.ipv4.ip_forward = 0
Jun 14 13:12:20 rei2 sysctl: net.ipv4.conf.default.rp_filter = 1
Jun 14 13:12:20 rei2 sysctl: net.ipv4.conf.default.accept_source_route = 0
Jun 14 13:12:20 rei2 sysctl: kernel.sysrq = 0
Jun 14 13:12:20 rei2 sysctl: kernel.core_uses_pid = 1
Jun 14 13:12:20 rei2 network: Setting network parameters:  succeeded
Jun 14 13:12:20 rei2 network: Bringing up loopback interface:  succeeded
Jun 14 13:12:22 rei2 network: Bringing up interface eth0:  succeeded
Jun 14 13:12:25 rei2 network: Bringing up interface eth1:  succeeded
Jun 14 13:12:34 rei2 cups: cupsd startup succeeded
Jun 14 13:12:34 rei2 sshd:  succeeded