Bug 112123 - rhgb hangs boot sequence after a crash
Summary: rhgb hangs boot sequence after a crash
Alias: None
Product: Fedora
Classification: Fedora
Component: rhgb   
(Show other bugs)
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-15 04:52 UTC by Herculano de Lima Einloft Neto
Modified: 2008-08-02 23:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-14 15:45:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace rhgb -i (29.29 KB, text/plain)
2004-11-12 12:50 UTC, Yijun Yuan
no flags Details

Description Herculano de Lima Einloft Neto 2003-12-15 04:52:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b)

Description of problem:
I'm not sure if this is an rc.sysinit bug or a rhgb bug.. anyway, after
a crash, rhgb loads and then we're back to text mode boot, prompting
for file system check.. say yes or say no, and after Enabling swap
space, the system hangs. Using -x in rc.sysinit showed the problem was
on a call to 'rhgb --sysinit', IIRC. It only happens after a crash,
but since it generates another crash, unskilled users are stuck.
Disabling rhgb on grub solves it.

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

How reproducible:

Steps to Reproduce:
1. Shut down uncleanly.
2. Boot with rhgb

Additional info:

This took place on a ze5375us HP Pavilion laptop, which needs
nofirewire  and no kudzu to boot. Pretty sure that's not relevant.

Comment 1 Daniel Veillard 2004-09-18 20:57:31 UTC
Does this still happens with current versions (FC2 and FC3 test1) ?


Comment 2 Yijun Yuan 2004-11-12 12:50:53 UTC
Created attachment 106562 [details]
strace rhgb -i

running rhgb -i results in segment fault, If is run by hand in runlevel 5

Comment 3 Yijun Yuan 2004-11-12 12:56:13 UTC
I met this problem on my FC3 box which is upgraded from FC2Test1. If I
enable rhgb, after "mounting local filesystem  [OK]", it switches to
vt8 and starts X. After 1-2 seconds, it turns to detailed view
automatically, but nothing appears. Mouse and Keyboard works
correctly. I can only use ctrl-alt-backspace to shutdown X, and
"enabling local filesystem quotas" appears on console, then the system
I tried to boot with "single" option and disabled rhgb. Then I started
rhgb manually, and tried to run rhgb-client -u "abcdefg", but nothing
happened on rhgb's detailed view.
I tried to edit /etc/rc.sysinit, using "rhgb -i" instead of "rhgb" in
the section after mounting local filesystem. This time no X is started
but a lot of "assertion failed" such as "GDK_IS_SCREEN(screen)"
appears on console. At last it gives an "Segment fault" and system
continues to boot.
my system environment:
Celeron 1.2G with 256M SDR, using nv driver in /etc/rhgb/xorg.conf
rhgb-0.14.1-1, initscripts-7.93.5-1, gdk-pixbuf-0.22.0-15.0,
gtk2-engines-2.2.0-6, gtk2-2.4.13-5, nscd-2.3.3-74
The result of Running "strace rhgb -i -- :1 > data 2>&1" is in
attachment file.

Comment 4 vodkamilkshake 2005-12-30 13:12:17 UTC
I am using FC 3 on an x86_64 and get the same problem. Instead of removing rhgb 
from boot options, i entered `single' as another option and it booted normally.

Comment 5 John Thacker 2006-10-25 20:19:55 UTC
Changing to FC3 per comments.  (Note that FC1 and FC2 are not even supported by
Fedora Legacy anymore.)

Comment 6 John Thacker 2006-10-29 21:05:10 UTC
FC3 and FC4 are supported by Fedora Legacy for security fixes only.  Does this
occur in a more recent, still supported version like FC5 or FC6?

Comment 7 Ray Strode [halfline] 2007-08-14 15:45:17 UTC
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.

Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.

Thank you in advance.

(this message is mass message)

Note You need to log in before you can comment on or make changes to this bug.