I am running Fedora 11 Preview, using the vesa fb driver. When I start in run level 5, and log in using gdm, I cannot switch to other virtual consoles with Ctrl-Alt-Fn. When I start X in run level 3 using startx, I can. (This laptop has an ATI 200M graphics chip, and the kernel loads radeondrmfb. I have to use the vesa driver because the radeon driver gives me screen garbage (bug 498457)) Note to me: Add details on what happens when I try to switch consoles, and whether there is a mingetty process for each virtual console.
If I boot in run level 3, then switch to run level 5 from a virtual console, then I can switch to other virtual consoles, even from inside of X (gdm and gnome) If I boot into run level 5, then I cannot switch to any virtual consoles. For example, when I press Ctrl-Alt-F2, the screen clears to completely black, except for a flashing text-mode cursor in the top-left corner. There are no login prompts. The same happens for all the virtual consoles. It is possible to switch back to X using Ctrl-Alt-F1. Even though the virtual consoles can't be accessed, there are mingetty processes running for each of tty1-tty6. Killing a mingetty results in a mingetty process for that terminal being respawned, but there is still no login prompt on that virtual console. Note to me: See if it's possible to switch from run level 5 to 3.
what's the output of initctl status on your machine after you boot into runlevel 5?
Ok, I tried "telinit 3" from an xterm inside X at run-level 5 from startup. X shuts down and I get a totally black, blank screen (backlight still on). Keyboard doesn't appear to do anything, power button leads to orderly shutdown. Casey, I'll have a look.
Hi Casey, "initctl status" needs a job id (sorry, not familiar with upstart), so I ran "initctl list" instead. control-alt-delete (stop) waiting logd (stop) waiting plymouth-shutdown (stop) waiting prefdm (start) running, process 1535 quit-plymouth (stop) waiting rc0 (stop) waiting rc1 (stop) waiting rc2 (stop) waiting rc3 (stop) waiting rc4 (stop) waiting rc5 (stop) waiting rc6 (stop) waiting rcS (stop) waiting rcS-sulogin (stop) waiting readahead-collector.event (stop) waiting readahead-disable-services.event (stop) waiting readahead.event (stop) waiting serial (instance) sulogin (stop) waiting tty1 (stop) waiting tty2 (start) running, process 1542 tty3 (start) running, process 1543 tty4 (start) running, process 1536 tty5 (start) running, process 1541 tty6 (start) running, process 1544 It is possible this is not an upstart bug. Could be something to do with the radeon-based vesa fb, and how it maps console numbers. Please let me know if there's anything I can do.
initctl list was what I meant to say :) Yes, according to Upstart, all the gettys are running. Upstart's primitive brain can sometimes say a process is stopped when it is running, but I've _never_ known it to say it was running when it was stopped, and can conceive of no way that would happen. You might want to inspect those PIDs next to the tty2-6 jobs, and check your /var/log/messages. In any case I don't think Upstart is the issue here. Bill, any thoughts?
I will boot into F11 Preview and try: echo foo > /dev/tty2 ... from within X. That should show up on the second console right? If it doesn't, I think it's a VC problem. Guys, if it's not an upstart problem, can you suggest a Component to choose instead of upstart? Thanks.
Running: echo foo > /dev/tty2 ... from within X doesn't display output on tty2. So I guess this is a VC problem, not an upstart problem. Can you suggest a Component to choose instead of upstart please? Possibly xorg-x11-drv-fbdev, xorg-x11-drv-ati, xorg-x11-drv-vesa, kernel? Thanks guys, Mitch.
Assigning to the kernel, although it could be something else.
No action on this for 10 days. Can I assign it to X/OpenGL Maintenance List (xgl-maint)?
This doesn't happen if X is running with the radeon driver, only with the vesa driver.
What should I do to get more information to use in debugging this?
I had the same 'problem' with an intel card, but the issue in my case seemed to be defaults in xorg that have changed in recent release. This lines brought back two old behaviours I used to have (Ctrl-Alt-Backspace to restart X and Alt-Fx for VT) /etc/X11/xorg.conf Section "ServerFlags" Option "DontVTSwitch" "false" Option "DontZap" "false" EndSection HTH
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm having this same issue with Fedora 11 using the Nvidia Proprietary drivers.
Hi Howard, When you're having the problem, are you using the proprietary drivers, or using VESA? What happens if you use the free/libre nv driver?
I'm using the Nvidia proprietary drivers, I downloaded and installed myself (only way to get dual screens to work properly, or the way I wanted anyway). I can't remember if I've ever used the nv driver, but I did use the nouveau(sp?) driver before. When I get a chance (at work now) I'll load up the nv and nouveou drivers and check that out.
I just flipped over, and I now see this when I run "initctl list": control-alt-delete (stop) waiting logd (stop) waiting plymouth-shutdown (stop) waiting prefdm (start) running, process 2070 quit-plymouth (stop) waiting rc0 (stop) waiting rc1 (stop) waiting rc2 (stop) waiting rc3 (stop) waiting rc4 (stop) waiting rc5 (stop) waiting rc6 (stop) waiting rcS (stop) waiting rcS-sulogin (stop) waiting readahead-collector.event (stop) waiting readahead-disable-services.event (stop) waiting readahead.event (stop) waiting serial (instance) sulogin (stop) waiting tty1 (start) running, process 2071 tty2 (start) running, process 2075 tty3 (start) running, process 2076 tty4 (start) running, process 2073 tty5 (start) running, process 2074 tty6 (start) running, process 2077 vpnc-cleanup (stop) waiting Note the "tty1" line says "running" and my X session is now on tty7, however they are all still blank and black with no prompt. I did add the two lines to the "Section "ServerFlags" " section of my xorg.conf file: Option "DontVTSwitch" "false" Option "DontZap" "false" But, none of the tty sessions have any login prompt. I also double checked and I'm using "nvidia" for the driver. I found, however, that the nouveau driver was still loading. So, when I reboot again I'll report back on the results.
Evidently the nouveau driver is used with the PulseAudio sound setup, as it showed some devices were removed when I blacklisted it. :-D. Even with it not loaded the tty# screens never came back to life. I wasn't able to get the nv driver up.
Do you get virtual consoles if you start in runlevel 3?
I've been having a similar problem, and I suspect that this may be the same problem that Mr. Davis reported. It's not that <ctrl>-<alt>-F2 (for example) fails to connect to TTY2; the problem is that the screen display is black-on-black and, if you try, e.g., a "^[[33;40m" to set the colors to green on black, you just get a "beep." So the problem is, I suspect, in the console emulation, since the standard control sequences are being ignored. In the black-on-black state you can log on and run commands, but - with no visible feedback - this is not very productive. (On those rare occasions when I need a "root" X-session, I can switch to tty2, log in as "root" and do a "startx -- :1" successfully. My assumption was that there was some file that should be in /etc/sysconfig/console/ that was missing, but I've been unable to figure out what should be in there.
*** Bug 509023 has been marked as a duplicate of this bug. ***
I seem to be having the same problem on my laptop, as well as some of my customer desktops. All are using nvidia proprietary modules.
Same problem here, using an NVidia Quadro FX card with NVidia's driver (x86_64-185.18.31-pkg2)
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.