Bug 498852

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.