Red Hat Bugzilla – Bug 480041
The X display that will not die
Last modified: 2018-04-11 06:18:25 EDT
Description of problem:
Cannot switch from X display to console
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. From XFCE or gnome, type ALT-CTL-F[2-6]
X display remains, but is dead.
X display replaced by console shell prompt
With F10 on an x86_64 machine, I can no longer switch from the X display
to a console prompt with ALT-CTL-F[1-6]. I believe that control does
switch to a console, because the X windows and mouse go dead, but the
dead X display remains and no black console with shell prompt is seen.
If I then type ALT-F7, windows in the X display blink and control is
If I kill the X server with ALT-CTL-BS all the X windows die and
disappear, but the blue screen remains, so that whatever console prompt
there may be is invisible. All that can be done then is to press
ALT-CTL-DEL and wait for the system to reboot.
Actually, there is one other recovery that works. With the X server
killed, but the residual X blue screen blocking all user activity, press
CTL-D to logoff, then in the blind type a userID, passwd, and startxfce4.
If you manage to do all that successfully, a new X session starts and
restores normal XFCE operation.
This problem occurs only on an x86_64 machine with Fedora 10. That same
machine rebooted to Fedora 9 switches properly between X and console.
This machine has this video controller:
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon
Other 32 bit machines with F10 all switch properly between X and console.
I also note that XFCE runs on console 7, while gnome runs on console 1.
Both exhibit the same failure to release the X display when switching
to a console. Apparently the conversion from a perfectly working system
to the "new look" is incomplete.
As you can infer from the above, I routinely convert all new Fedora
systems to run at initlevel 3 and manually run startxfce4 (or rarely,
startx). I also remove 'rhgb' from the kernel line in grub.conf
because I *like* to see what's happening during boot and shutdown.
It also bypasses the deplorable gdb "Welcome" screen. The dumbing
down of Linux that rages on in F10 is truly sad.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 329106 [details]
Xorg.log with xorg.conf.1
Created attachment 329107 [details]
xorg.conf.1 - original
Created attachment 329109 [details]
Xorg.0.log.2 with no xorg.conf present
I attach two sets of files:
Xorg.0.log.1 and xorg.conf.1 - the version that prompted this bz.
Xorg.0.log.2 - as captured with xorg.conf file entirely absent.
Please note that the original xorg.conf file, created by
system-config-display, contains this manually contrived addition:
Option "AutoAddDevices" "off"
I inserted this to suppress the loading of the evdev module, which
is necessary to overcome the defect in that new code - with
evdev the left arrow key is ignored. This means, eg, CTL-ALT-RtArr
works, but CTL-ALT-LftArr is ignored. (These are used by XFCE to move
to adjacent "desktops".) Other uses of the left arrow key also fail.
This is intolerable, but it's another issue, previously reported, and
hopefully being fixed.
Meanwhile, it's necessary to suppress evdev.
My original complaint - failure to release the X display - remains,
with the absent xorg.conf file. I still cannot switch to a simple
console prompt. All other aspects of the X display seem
to be indistinguishable with and without the xorg.conf file.
I will revert to an xorg.conf file that contains only the above three
lines, and report seperately if that makes any difference.
this is a graphics issue, changing to xorg-x11-drv-ati
(In reply to comment #5)
> with evdev the left arrow key is ignored. This means, eg, CTL-ALT-RtArr
> works, but CTL-ALT-LftArr is ignored.
I haven't seen this issue in a while now. Please make sure you're up-to-date, the bug is almost certainly gone. If not, please point me at the bugreport where this issue is listed.
Sorry to burst your bubble, but I can assure you the evdev bug is
still alive and kicking.
I thought my 64 bit machine was up to date, but yum update gave 31 new
packages. Unfortunately, none had any effect on the two problems at
issue here. I did verify that after these updates, and deleting the
xorg.conf file, the left arrow key is still ignored. I still cannot
switch to a console, either. I've reinstated the xorg.conf fix that
This fix is required on 3 of 4 machines that I've installed F10 on.
1 - a 32 bit AMD Athlon, nvidia driver
2 - an IBM T30 laptop, radeon driver
3 - this 64 bit AMD Athlon, ATI Radeon Xpress 200 adapter
4 - a new Asus N10JA2 netbook, nvidia driver
Only #4 works correctly without the evdev suppression fix.
For #2, suppressing evdev restored arrow key function, but removed
touchpad scrolling. It was necessary to explicitly invoke the
older synaptics driver. Fortunately, I was able to retrieve a working
xorg.conf file from an F8 backup.
(Only #3 is unable to switch to a console.)
After all the days of Googling for a solution to this problem I cannot
recall a specific BZ report. I did find this solution at
and there are endless pleas for help on the ubuntu fora.
Should I submit a separate new bz for the arrow key issue?
It is merely my uneducated suspicion, but these two problems may be
I have discovered the cause that blocks switching from X to a console.
It was a boot option 'vga=792' that I had added to the kernel line
in /etc/grub/grub.conf. For prior Fedora's, I have removed the silly
'rhgb' option and added this option to make the characters smaller than
the default so more info can be displayed during boot. Upon removing it,
I find the default console characters are now even smaller (better) and
I am able, once again, to switch from X to the numbered console screens.
Although my problem is resolved, the underlying problem remains.
Setting the vga resolution to any legal value should not affect the
ability to use a console screen. This is a pretty subtle failure.
I hope my stumbling upon it will not be ignored, and the underlying
code error will be fixed, even though few users are likely to
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.