johannes bauer wrote:
Since my FC5 installation a few weeks ago I have a curious problem. The
machine boots up nicely, I get the blue log-in screen, I type username and
password, my account comes up, but just when I should be ready to use it,
the screen goes blank (sometimes displaying some messages for 1/2 a
second), and the machine jumps back to the blue X-window log-in screen,
asking me again to log in. Only after the second, third, fourth, of
fifth log-in
try it works, and I then can use my account normally.
This behavior happens for both of my user accounts and started right
with my plain-vanilla FC5 installation. The only non-plain-vanilla
items are the files that were before in my account (which I copied over
from a backup disk) as well as some tweaking of which packages shall be
loaded.
Thinking that perhaps one of these old files gives this problem, I
tried to copy only some files over, but I was not able to identify any
one file that might cause it. It seems to be a gnome problem with
.gconf, since the problem appears only when I use Gnome, but not when I
use KDE. So I deleted files and once thought I had it narrowed down to
.gconf/apps/panel/applets, but then the error reappeared even if I start
with completely fresh directories .gconf and .gnome* (which made it
necessary for me to individualize the appearance). So the problem does
not seem to be a simple old file. Once I got rid of this problem in one
account (and I don't know how). Then I accidentally deleted the .gconf*
and .gnome* files, and now I am again seeing this problem in this
account.
I don't find any error file created in my account. From dmesg I get
the following error messages, but I think they are not related to this
annoying feature:
audit(1148538077.353:19): avc: granted { execmem } for pid=2488
comm="nautilus" scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
audit(1148538077.413:20): avc: granted { execmem } for pid=2488
comm="nautilus" scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
audit(1148538097.070:21): avc: granted { execstack } for pid=2636
comm="metacity" scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
audit(1148538097.070:22): avc: granted { execmem } for pid=2636
comm="metacity" scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
audit(1148538098.955:23): avc: granted { execstack } for pid=2641
comm="nautilus" scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
I tried also logging in with Gnome Failsafe. It sometimes gave me a
warning that the session lasted less than 10s, and the message in
~./xsession-errors was:
/etc/gdm/PreSession/Default: Registering your session with wtmp and
utmp
/etc/gdm/PreSession/Default: running: /usr/bin/sessreg -a -w
/var/log/wtmp -u /var/run/utmp -x "/var/gdm/":0.Xservers" -h "" -l ".0"
"bauer"
(process: 3797): Gtk-WARNING **: This process is currently running
setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:
http://www.gtk.org/setuid.html
Refusing to initialize GTK+.
I was unable to find anything related to this "feature" on the web
(google and this list archive), and hence I appreciate any suggestion,
like how I could also debug this besides slowly varying my setup.
For example, I would expect somewhere a file to tell me what went wrong.
My system is an Athlon XP 2000+, A7V333 motherboard with a simple
video card, an ATI Mobility-M 8MB. I keep FC5 up-to-date with yum.
Thanks!
--- Johannes Bauer
You have a clear description of your problem. Submitting a bug report
with these details may get some response. I can be of little help.
Gnome is more sensitive to network problems than KDE is. It might be
some network address problem and gnome components.
Also I had problems before with metacity using the livna provided
driver. It only killed metacity and did not exit X.
Are you using the xorg-x11 provided driver or the binary?
You might try switching to a virtual terminal and logging in as root.
Once logged in, set selinux to permissive via 'setenforce 0'. Then
switch back to the GUI login console and try to launch GNOME. If it
works, you might need to relabel your SELinux content on your system.
touch ./autorelabel followed by reboot might relabel your system correctly.
You might find errors regarding these errors in the /var/log/audit
directory and one of the audit.log files.
Jim
--
I told my kids, "Someday, you'll have kids of your own." One of them said,
"So will you."
-- Rodney Dangerfield
