No virtual terminals (CTRL+ALT+F?) when no user logged in

gdm might have Fn lock turned off.

Please try this instead: Ctrl+Fn+Alt+F3

The "Fn" trick did not succeed. The keystrokes with "Fn" did not get recognised, these without Fn (i.e., the standard ones) did as shown below.

More info (after a dist-upgrade so last packages are in place) about behaviour today:

1. Boot until gdm graphical login appears.
2. Hit Ctrl+Alt+F?. Nothing happens. Kept at graphical login on virtual terminal 1.
3. Log in and start a graphical X session on any user.
4. Hit Ctrl+Alt+F?. Consoles show as required.
5. Hit Ctrl+Alt+Fxxx to return to the virtual terminal holding the X session. Log out of the graphical X session.
6. Hit Ctrl+Alt+F3. Screen keeps being that of gdm (now mouse cursor gets frozen), but the keystroke Ctrl+Alt+F3 IS recognised... and also subsequent ones: if I then type username and password, I see nothing but gdm on screen but, ...
7. Come back to tty1's gdm graphical login and log in to an X session as any user.
8. Hit again Ctrl+Alt+F3. Voilà: the invisible login at step 6 did actually succeed... the shell propmt is there, waiting for further input.

*For your information, there is also unexpected behaviour on virtual terminal switching in my main computer with 17.10 and Nvidia drivers but, well, this is not the place to report 17.10 bugs and mess up things.

So, I wonder if it is a gdm issue or any on graphics drivers/framebuffers... whatever... I'm not a developer so, well, my capabilities to diagnose/debug are limited.

Status changed to 'Confirmed' because the bug affects multiple users.

What graphics drivers are you using?

Note that Ctrl+Alt+Fn is not a system-wide keyboard shortcut. There's no such thing.

It has to be interpreted by whatever shell/GUI is on screen at the time. So that's not a driver problem but a shell problem. Although the shell could always be understanding the keys and failing to switch, so that could then be a driver bug :)

That said, I can't reproduce this bug in the final 18.04 release right now. Can anyone?

I am on Intel graphics (xps13 i7-4500U HD4400).

I can still reproduce it... basically, at boot, Ctr+Alt+Fn do nothing (behaviour steps 1 and 2 in #3). However, once you start a user's X session the shortcut "activates"... if an X session is open, things go as well (step 4). However, if such a session is closed, the shortcut is still active (and the virtual console recognises keyboard commands) but the screen does not show it (steps 6 to 8).

Further info: I updated my main computer to 18.04. That one has Nvidia graphics (updated to the latest nvidia-390 from PPA). Behaviour is different, but buggy, too, as follows:

1. boot
2. Hit ctrl+alt+f3. Console shows. Log in. exit (log out).
Expected behaviour: return to gdm's graphical login screen with responsive keyboard and mouse.
Actual behaviour: the gdm's screen appears but keyboard and mouse are unresponsive...
3. Hit ctrl+alt+f1.
Expected behaviour: even if ttt3's screen seems corrupted, hopefully ctrl+alt+f1 would return to gdm's graphical login screen with responsive keyboard and mouse on tty1.
Actual behaviour: screen blanks. Computer is unrecoverable from keyboard and mouse. Only REISUB can reboot it again (alternatively, accessing it via SSH shows that the OS is still alive and well, but graphics are messed up).

In summary, both Intel and Nvidia behaviours, in two different computers, seem buggy, although the actual behaviour is slightly different for each case.

A bold conjecture: does GDM use Wayland or X? Is this caused by any Wayland/X switching?

gdm3 uses Wayland by default.

Is your Intel machine also running Ubuntu 18.04?

Yes, both are on 18.04.

I wonder why I can reproduce it on three computers with two ubuntu versions, with both Nvidia and Intel and you cannot (post #6)... Just in case it might matter, I have other desktop environments (Plasma, xfce) also installed, but my session manager is set to gdm.

Additional info: I have a third computer which is still on 17.10 with Nvidia graphics, and it also sports the same kind of buggy behaviour as my post #8, so it seems this might be inherited from at least one prior version. I reported the bug and assigned it to gdm because, well, when the computer is apparently dead (step 3 in #8), if you SSH and do sudo pkill gdm, then it dies, respawns and things go back to normal, no need to reboot via REISUB when another computer is at hand.

Status changed to 'Confirmed' because the bug affects multiple users.

I get this bug if I uncoment WaylandEnable=false in /etc/gdm3/custom.conf .
If I use gdm3 with Wayland I get #1764643 instead.

I can confirm that I have the exact same problem in fresh install of ubuntu 18.04 today. Intel graphics here. Very annoying as this pops up just as I decided to upgrade after a period of testing ( where I never noticed this problem.)

I'm using 18.10 now and have noticed there's sometimes a confusingly long delay for the VT login prompt to appear. It's just a cursor on a black screen for a while, and then suddenly the VT login prompt appears (sometimes).

See also related bug 1775764.

I also have these problems (and also many other problems since 18.04) on multiple computers.
1 desktop with nvidia drivers and 1080ti
1 laptop with 1070
1 laptop with intel 620 : sometimes after repeatedly typing ctrl+alt+f3 it shows up.

I do not know way this version of Ubuntu is so much flawed. That impacts my robotics team and me greatly, so much that we will not be able to use it for our work!

@raphael-fáistonpc: I have been having this and other GDM3 related issues hitting the laptops I administer and its a showstopper here, too. My current "solution" has been to give up on GDM3 and just 'sudo apt install lightdm'. Perhaps that will let your robotics team get back to work without having to chuck all of the latest Ubuntu.

I too have this problem on multiple computers. Laptops behave the worst.
I tried a temporary work around:
in .bashrc I added:
alias text='systemctl isolate multi-user.target'
alias graphical='systemctl isolate graphical.target'

I then can type text to get to the virtual terminals and
type graphical to get back to the graphical screen.
I do not do alt-F1 to return and that still messes up.

Fresh Ubuntu 18.04 on Dell XPS13 9360, Intel video - can also reproduce this bug

Confirmed reproduced on latest Ubuntu 18.04.1. Switching between terminals with ctrl+alt+f1-7 does not work after initial switch and logout. Only a blank screen and unresponsive keyboard/mouse which had to be resolved through reboot.

Its' reproducible on AMD Ryzen APU's as well. Can the priority of this be bumped up and someone fix it. This is a basic feature which every Linux distro has.

Also reproduceable on a Lenovo Thinkpad W540. fresh install of Ubuntu 18.04 (Dualboot Windows 10).

I have same bug on ubuntu 18.04. Lenovo G560

Also affects 'mutter', since I imagine that's the component which must handle the key combo for gnome-shell.

I have same bug on ubuntu. Lenovo B5400.

Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic

The same problem
Dell Vostro 5648, i5-7200U

Even more, after pressing any time CTR-ALT-F#
Gnome desktop process terminates and i've got
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Alexander, please see bug 1550779 for that.

Reproducible on 18.04.3 LTS on a t460s Thinkpad. (Yes, enable function-lock, or remember to press Fn + ctrl + alt + f3)

Do a normal login and press CTRL-ALT-F1. Now it switches to a virtual
console showing the boot log. Alas there is no way to switch back
to any other virtual console!! Reboot here is the only option.

Do a normal login and press CTRL-ALT-F1. Now it switches to a virtual
console with a login prompt. Nice. Do not press ALT-F1 or you will end up
in the boot log again...reboot. Press ALT-F2 to get back to the graphical console.

Then I removed the comments for the two lines:
NAutoVTs=6
ReserveVT=6
in the file /etc/systemd/logind.conf
and rebooted.

Then it started to work better. F1 seems to be the gdm graphical login prompt.
F2 has the graphical desktop. F3 is the first virtual console terminal. I do not know where to boot log went...

However wait after pressing the CTRL-ALT-Fx and ALT-Fx keys when switching consoles.
If I switch between the consoles too fast,
them the X-process sometimes crashes and you get
the login screen again.

Typo above, the second CTRL-ALT-F1 in the text above should be CTRL-ALT-F3....

I have the same exact issue on 20.04 LTS. I'm using a Radeon RX 570 GPU. Kernel 5.4.0-29-generic

I have the same issue on:
* Ubuntu 18.04.4
* Kernel 4.15.0-111-generic
* Thinkpad T480s

Here is sit, in 2020, Nvidia, Ubuntu 20.04, SAME issue... as a desktop, full keyboard I have no Fn'b button (lol pun intended). Kernel, 5.4.0-47-generic, Nvidia Driver 450.66 (Game Driver)

I can reproduce it but only in:
* GNOME Shell 3.36.4
* KDE Plasma Shell 5.18.5

But in XFCE, LXDE, LXQT, MATE and others <Ctrl>+<Aly>+<F(n)> works fine for me.

At first, I've tried to use `sudo chvt 2` for switching form KDE on tty1 to Raw Console on tty2. After switching to tty2 <Ctrl>+<Aly>+<F(n)> works as in early days.
It doesn't depends on video drivers or kernel flags and etc. For my laptop I've got the same for nvidia:455.38 and for i915, with modeset and with nomodset, with GFX grub mode and without.

But I guess, this is not a system or hardware problem, because there are no any troubles with small environments. So after some research I found, that you can use `sudo kbd_mode`.

So for me `sudo kbd_mode -af` works fine without reboot.

* Laptop: DellXps 15 9570 4K Touch
* Operating System: Kubuntu 20.04
* Kernel Version: 5.8.0-7630-generic #32~1605108853~20.04~8bcf10e~dev-Ubuntu (from system76)
* OS Type: 64-bit
* Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz
* Memory: 15,4 Gib

Unfortunately I cannot find `DontVTSwitch` option in xorg.conf-like all-over the system, as was said for example here:
* https://unix.stackexchange.com/questions/34158/rebinding-disabling-ctrlaltf-virtual-terminal-console-switching

I think it'll be better solution.

The solution of Fredrik Öhrström (oehrstroem) also sounds great.

Status changed to 'Confirmed' because the bug affects multiple users.