When I go from my graphical session to a virtual console by Ctrl + Alt + F i (with i in 1 - 7 and 9-12) I see a completely black screen. Only on F8 I see the GUI. Not even a blinking coursor on the others. When I enter anything, I can't see anything.

What is the problem and how do I fix it?

My system

$ uname -a
Linux pc09 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Linux Mint 17 Qiana \n \l
$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GK110B [GeForce GTX Titan Black] (rev a1)
$ lspci -k | grep -A 2 -i "VGA"
01:00.0 VGA compatible controller: NVIDIA Corporation GK110B [GeForce GTX Titan Black] (rev a1)
Subsystem: NVIDIA Corporation Device 1066
Kernel driver in use: nvidia

edit: I tried the first steps suggested on http://forums.linuxmint.com/viewtopic.php?f=42&t=168108 and the problem seems to be the framebuffer.

I did this:

This has been an issue that has been an annoyance with Nvidia proprietary drivers for two or three years, and has kept me away from Ubuntu-based distros for some time. Finally, on the Nvidia forum, I found the workaround I'd been looking for. The problem arises with Nvidia proprietary drivers (Nouveau doesn't show this behavior): when you push ctrl-alt-F1, you get only a black screen or, at best, a flashing cursor that does nothing. The problem apparently, has to do with the way the framebuffer in implemented and this needs to be disabled. To see if this is the problem, first you need to make a couple of minor modifications to /etc/default/grub - but first, make a backup!

$ sudo cp /etc/default/grub /etc/default/grub.bak

Now edit the file by entering

$ sudo pluma /etc/default/grub

in the editor, uncomment the lines

#GRUB_TERMINAL=console
#GRUB_GFXMODE=640x480

by removing the #. Save the file and run undate-grub to implement the changes

sudo update-grub

Now I have (a low resultion) tty working again :-)

  • Video card and driver? Is KMS enabled and working? – jasonwryan Sep 23 '14 at 19:42
  • I've added the output of lspci | grep VGA. How do I check your KMS questions? – Martin Thoma Sep 23 '14 at 20:00
  • Are you using the blob or nouveau? With the proprietary driver, you may need a framebuffer like uvesafb. The Mint people should have it documented somewhere... – jasonwryan Sep 23 '14 at 20:40

That's because you are using the proprietary NVidia driver.

When I was OpenSUSE with the proprietary driver my consoles also would be black, now that I am using Ubuntu again they get an even "cooler" effect: (Don't worry, the screen is fine!) Other cool stuff the NVidia driver can do

The reason for this seems to be the NVidia kernel driver which, once initialized by the DDX (=device dependant X11) driver, cannot cope with requests from any other video subsystem (such as fbdev, VESA, Linux console, ...).

The console will still be activated when switching to it. To verify this, try logging in blindly into the console and enter something that will be easy to notice, such as wall or reboot:

<Your username>
<Your password>
echo "Test message" >/tmp/message; wall </tmp/message

After returning from the console you should see something like this in any terminal window:

Broadcast message from <Your username>@<Hostname>
        (/dev/tty2) at 23:38 ...

Test message

Unfortunately I do not know of any way to fix this except for using the OpenSource driver ("nouveau"). VT switching works fine using that driver, but that driver creates other issues (spontaneous crashes and generally less performance in my case). I'm also neither a kernel developer nor an NVidia developer so I can't do much more than analyzing the symptoms myself.

  • This is only an issue in the framebuffer console. If you dont use it the virtual consoles work fine. – casey Sep 24 '14 at 1:03
  • @alexander255 see my edit in the question: I got it (partially) to work again. I don't really understand what is going on here and what a good solution is, so I would appreciate if somebody could write a good answer. – Martin Thoma Sep 24 '14 at 11:47
  • @casey: Do you propose to rely on boot-time video setup? Or did you successfully run SVGATextMode with a modern nvidia card and its proprietary driver? – Incnis Mrsi Sep 13 '15 at 21:04
  • @IncnisMrsi Afaik the proprietary nvidia driver s incompatible with the framebuffer. Use noveau if you want both. – casey Sep 13 '15 at 21:08
  • @casey: When was it incompatible? In 2014, perhaps, but the current driver showed me a nice-looking TUI (albeit Ī̲’m not completely sure it was fbdev). Ī̲ kicked the nvidia module off my new box only after it hung me up.    By the way, Ī̲’m speaking namely about hardware text modes. – Incnis Mrsi Sep 13 '15 at 21:20

Don't know ubuntu system too well, but normally ttys are spawned by agetty during boot process. Perhaps ubuntu developers decided not to do so? Anyway you can try as root run /sbin/agetty 38400 tty2 linux and see if something has changed on tty2.

Normally this command is present in some configuration file under /etc folder. For example on my gentoo box in /etc/inittab I have

# TERMINALS
c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
c2:2345:respawn:/sbin/agetty 38400 tty2 linux
c3:2345:respawn:/sbin/agetty 38400 tty3 linux
c4:2345:respawn:/sbin/agetty 38400 tty4 linux
c5:2345:respawn:/sbin/agetty 38400 tty5 linux
c6:2345:respawn:/sbin/agetty 38400 tty6 linux

You can grep getty /etc/* to see if there is a file with similar lines.

  • First, if a virtual console isn’t created, then you can’t get to it, and if it exists, then cursor (normally) blinks there. Second, getty has nothing to do with video modes, especially on tty1 that is always present. Downvote. – Incnis Mrsi Sep 13 '15 at 21:06

I had this problem too and my workaround was to change into recovery mode and there choose the option "Resume". As I saw the login screen and pressed STRG + ALT + F1 I could see the text login and could interact with the system (for me important to install the proprietary NVIDIA drivers, ironic isn't it?). I hope, my workaround works for you too :)

Ugh. So, this problem had been bugging me for probably 18 months. I fixed it today finally.

I had to set up a UEFI boot partition and get the system capable of booting from it. I enabled efifb, simplefb, and the generic fb handler under pci options (many other combinations did not work). I have uefi booting a kernel directly, no intermediary bootloader is being used.

No combination of crap using bios compatible mode (simplefb, uvesafb, vesafb etc.) could get my VTs back once X11 loaded. Now I can switch back and forth happily when I break stuff :)

  • 1
    How were you able to pass kernel parameters directly from UEFI? – sherrellbc Dec 20 '16 at 18:49

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.