Bug 112123
| Summary: | rhgb hangs boot sequence after a crash | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Herculano de Lima Einloft Neto <hlen> | ||||
| Component: | rhgb | Assignee: | Ray Strode [halfline] <rstrode> | ||||
| Status: | CLOSED CANTFIX | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3 | CC: | vodkamilkshake, wtogami | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-08-14 15:45:17 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Does this still happens with current versions (FC2 and FC3 test1) ? Daniel Created attachment 106562 [details]
strace rhgb -i
running rhgb -i results in segment fault, If is run by hand in runlevel 5
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 hangs. 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. 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. Changing to FC3 per comments. (Note that FC1 and FC2 are not even supported by Fedora Legacy anymore.) 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? 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) |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030525 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: Always Steps to Reproduce: 1. Shut down uncleanly. 2. Boot with rhgb 3. 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.