Bug 120372 - graphical xserver crash when using graphical login on test 2 with 305 updated 4/7/04 to xorg
Summary: graphical xserver crash when using graphical login on test 2 with 305 updated...
Alias: None
Product: Fedora
Classification: Fedora
Component: XFree86   
(Show other bugs)
Version: 2
Hardware: i386 Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-08 04:01 UTC by dusty bradshaw
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-25 14:06:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description dusty bradshaw 2004-04-08 04:01:22 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
after updating test2 on 4/7/04 xserver would crash when i tried to
login as root graphically. After rebooting and editing the kernel line
to runlevel 3 and loging in text based, i was able to get xserver up
by typing startx. If i logged in graphically as root, it crashed and
threw all kinds of errors, if i runlevel 3, and log in as root and
then startx the graphical environment runs fine. thanks'

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

How reproducible:

Steps to Reproduce:
1.update 305 as of 04/07/0
2. logout to login screen
3. login as root.
4. password
5. xserver crashes
6. reboot and append grub so you boot into runlevel 3
7. text login as root
8. type 'startx' and xserver WROKS!
9. apply salve to chaffed areas and rest

Additional info:

Comment 1 dusty bradshaw 2004-04-08 04:45:04 UTC

failed to run command "/sbin/poam_timestamp_check": failed to execute
shild process "/sbin/pam_timestamp_check" (permission Denied)
/usr/share/rhn/rhn_applet/rhn_applet.py:362: DeprecationWarning:
integer argument expected, got float
   self.animate_timeout_tag = gtk.timeout_add(math.floor(1000 *
ANIMATION_TOTAL)TIME/len(frames)), self.animate_handler)

** (nautilus : 2085): WARNING ** destroyed file still being monitored
** (nautilus : 2085): WARNING ** destroyed file still being monitored
** (nautilus : 2085): WARNING ** destroyed file still being monitored
** (nautilus : 2085): WARNING ** destroyed file still being monitored
[root@localhost root]#
9nautilus:2085) Bonobo-WARNING **: Leaked a total of 1refs to 1 bonobo


I also get a gnome_segv when i try to login as root graphically.

Comment 2 John Dennis 2004-04-08 18:28:20 UTC
Try adding selinux=0 when you boot your kernel. Does the problem go away?

Comment 3 dusty bradshaw 2004-04-09 03:25:26 UTC
Thank you for your reply. 

I have a question for you.Its neat that disabling selinux at boot
makes the problem go away. I had to do that with 303 kernel.  However
I would like to know if my workaround (booting runlevel 3, loging in,
and then startingx manually) leaves sel on? I like the idea of having
sel work.., not just disabling it. I think my method leaves sel on,
while working around the problem as well. 

 Thnak you for the sel tip. I had not tried to disable selinux in this
case, though i probably should have. I dont really want to disable it
though. Thanks.. 


Comment 4 John Dennis 2004-04-12 15:49:08 UTC
If you don't disable selinux at boot it should still be on modulo
whatever your security policys allow. In an attempt to make more
things run with selinux there has been some relaxing of the policy,
just something to keep in mind. I'm sorry to say I still don't know
what the particular problem you encountered is and we will pursue it,
but I'm glad for the interim you have a workaround

Comment 5 Mike A. Harris 2004-11-25 14:06:25 UTC
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:


If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

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