Steps to Reproduce:
0.Vanilla install, Czech language and keyboard
1.Insert your user name, press Caps Lock twice, press Enter
2.Insert the password, press Caps Lock twice
3.Boot into Failsafe session [not required, just for faster reproducing],
press Enter to log in
4.In the terminal, enter
setxkbmap -symbols 'czsk(us_cz_qwerty)' -compat group_led
(This, except for s/symbols/layout/', is the setup I use in RHL 8.0
without these problems. -layout causes error messages in Phoebe)
6.Insert your user name, press Caps Lock twice, press Enter
7.Insert the password, press Caps Lock twice
Nothing unusual in 1., 2. and 6. After pressing Caps Lock for the second
time in .7, X restarts.
I've experienced this bug too. I'll give my two cents to help isolate the
conditions when it occurs.
My system is a Toshiba Satellite 3000 laptop with the i686 kernel and the vesa
driver under X driving the Nvidia Go chip. I doubt any of this matters though.
1) My system boots into runlevel 5
2) For the username, type "a", then "A", then "a" using the CapsLock to change
case. Notice the "You've got capslock on!" message being displayed. I'm not sure
whether this step is strictly neccessary.
3) For the password, simply switch the CapsLock on then off. Notice that the
"You've got capslock on!" message does not display. X/gdm-binary/gdmgreeter
crashes as soon as CapsLock is switched off.
I'm running the system with US English. I don't even need to logon with a valid
username/password to trigger this bug. I tried debugging from the virtual
console using strace and ltrace. Nothing crashes in such circumstances, but the
"You've got capslock on!" message is not displayed, so I still know there is a
bug. However, upon the killing of the ltrace or strace process monitoring the
gdmgreeter process, a crash occurs when the user switches back to the X console
(ie Alt-F7) without further keyboard input to gdm. My gut feeling is that it is
You might check the gdm log files, and see if anything ended up in there.
I'm wondering if this bug can be "fixed" by just setting:
I'm starting to lean towards just making that the default since there just
seem to be too many issues connected with just -HUP ing the X server. And
perhaps remove the -HUPing code and always have the slave quit. I think I
will do that right now in fact in CVS. It gives an ugly flicker since the
X server will change vt to vt1 when it ends and then back to vt7, but oh
well, who cares.
Altering the AlwaysRestartServer variable in /etc/X11/gdm/gdm.conf does not stop
the bug from occuring. gdm/X/whatever still crashes.
Furthermore, I've checked the /var/log/gdm/:0.log* files and there are no errors
of any sort. Last line in these logfiles were:
(==) Using config file: "/etc/X11/XF86Config"
Incidentally, I've changed my greeter from the default "graphical" greeter to
the "standard" greeter (which isn't the default, but still graphical) as seen in
the program ``gdmsetup''. It doesn't crash anymore. The effect is that gdm-login
is used rather than gdmgreeter. This points the bug squarely at gdmgreeter.
Furthermore, using the "graphical" greeter, but with a different theme (either
Circles or Happy GNOME) also seems to solve the problem -- odd. This indicates
that either the theme (if it has code) has bugs in it or it is triggering bugs
Taking gdm target/blockers.
I doubt this has/had anything to do with restarting the server or
the Xkb configuration when logged in. Most likely it is/was some
straightforward greeter crash.
I can't reproduce it though..
Can you reproduce it with 126.96.36.199 from Rawhide?
Owen, if you're referring to me to install the package from Rawhide, you'd have
to wait another few weeks. I've recently wiped phoebe and gone back to 8.0 for
I might try the phoebe gdm on RH8.0 to see if I can reproduce the bug and the
Rawhide gdm on RH8.0 to see if it can fix it. Might be a wait though.
Did another (fairly minimal) install, and it is now reproducible regardless
of Xkb setting. Using the suggested package (although with --oldpackage, I
didn't have gtk 2.2 final handy) causes the same.
It is a crash in gdmgreeter, attaching traceback from the Phoebe 1 version.
[Side note: Are/will the -debuginfo packages be available?]
Created attachment 89457 [details]
Thanks for the backtrace -- apparently this is a libgnomecanvas bug, see:
libgnomecanvas 188.8.131.52 is supposed to fix; so we need to upgrade that
libgnomecanvas 184.108.40.206 is in rawhide, so should be fixed now.
I indeed can't reproduce the crash with gdm-220.127.116.11-1 and libgnomecanvas-
1) enter any username
2) start entering a password, press Caps Lock
3) enter a bad password
a "Password" field appears again, not "Username". Only way I know of to get
back to the "username" prompt is Ctrl-Alt-Backspace.
I submitted that as bug 84626. Closing this one.