Description of problem: Cannot switch from X display to console Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.5.3-6.fc10.x86_64 kernel-2.6.27.9-159.fc10.x86_64 plymouth-0.6.0-0.2008.11.17.3.fc10.x86_64 How reproducible: Every time. Steps to Reproduce: 1. From XFCE or gnome, type ALT-CTL-F[2-6] 2. 3. Actual results: X display remains, but is dead. Expected results: X display replaced by console shell prompt Additional info: 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 restored. 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 Xpress 200] 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: Section "ServerFlags" Option "AutoAddDevices" "off" EndSection 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 suppresses evdev. 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 http://forums.fedoraforum.org/showthread.php?t=204953 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 related.
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 encounter it.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.