[SOLVED]Cannot reach virtual console

tethys · 2025-04-18 16:52:14

I cannot reach any of the virtual consoles, neither using Ctrl+Alt+F2 for example, nor with "sudo chvt 2".
First time I try I get the journal message

 Started Getty on tty2

but it does not switch to the virtual console: the graphical enironment just becomes unresponsive but I can switch back to a responsive graphical environment (GNOME) using Ctrl+Alt+F7.

Next time when I try it is the same, but I get the following messages in the journal:

rfkill: input handler enabled
rfkill: input handler disabled

The effect of Ctrl+Alt+F2 and "sudo chvt 2" seems to be the same.

Does anyone sees this behavior? I use kernel 6.14.2-arch1-1.

Resolution of the issue
It turned out that the cause of the failure to reach the VTs was lightdm. With Gnome's GDM the VTs are reachable.

Last edited by tethys (2025-05-03 13:00:50)

seth · 2025-04-18 19:32:25

Hardware, drivers and display server will be relevant information as you likely can switch the VT but that's not reflected by the framebuffer (ie you can't see it, try to blindly log in and "touch /tmp/test" then check from the GUI whether the file appeared)

tekstryder · 2025-04-19 11:51:43

tethys wrote:

does not switch to the virtual console: the graphical enironment just becomes unresponsive

You supplied no helpful information other than a symptom.

IFF you're using nVidia GPU, which has been otherwise properly set up per all wiki instructions AND it's of a Pascal or older generation, you should add these kernel parameters:

nvidia_drm.modeset=1 nvidia_drm.fbdev=0

Last edited by tekstryder (2025-04-19 11:53:28)

tethys · 2025-04-23 18:43:14

Thank you for your replies seth & tekstryder.
This is an Intel Processor, X11, GeForce GTX 1080, nvidia 570.133.07-5, Gnome, lightdm.
I have a laptop with roughly the same software but different hardware (Intel Processor, X11, integrated Intel graphics, Gnome, gdm) and the VTs work there.
So I think the the problem is indeed due to Nvidia.
I must mention that the VTs worked before, but it's a long time since I did not test them anymore (perhaps 2 years).

@seth:
I could check what you asked for and it is indeed so, ie "touch /tmp/test" produced a file.
Interestingly enough, when I returned to Gnome, I realized that the commands given in VT were mirrored in Gnome in whatever window was open (which can lead to security issues!).

@tekstryder:
I have indeed a file "/etc/modprobe.d/nvidia.conf" containing:

options nvidia_drm modeset=1 fbdev=1

I made these changes about one year ago because of mesa and it was documented in ArchWiki at that time.
Same ArchWiki entry (https://wiki.archlinux.org/title/NVIDIA … de_setting) now says that "Starting from nvidia-utils 560.35.03-5, DRM defaults to enabled".
So, I modified the above options to

options nvidia_drm fbdev=0

I will report the effect of these changes after rebooting.

Last edited by tethys (2025-04-23 18:45:19)

tekstryder · 2025-04-23 21:32:35

tethys wrote:

I have indeed a file "/etc/modprobe.d/nvidia.conf" containing:

That's not going to be sufficient as it does not load early enough to prevent the simpledrm device initilization.

If that's the entire contents of the file you can delete the file outright and rebuild your initramfs.

As mentioned above, add these two kernel parameters to your kernel cmdline for whatever bootloader you use.

nvidia_drm.modeset=1 nvidia_drm.fbdev=0

Ensure they are spelled/entered exactly as above.

Last edited by tekstryder (2025-04-23 21:34:37)

tethys · 2025-04-24 06:18:52

OK, thank you tekstryder, I will try that at next reboot.
I forgot to mention that I have also added nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm to the initramfs.

seth · 2025-04-24 06:22:51

That's irrelevant, the simpledrm device gets created *very* early and only the kernel commandline parameter is even intrepreted to prevent this.
Ie. even iff nvidia and its configs were loaded early enough, that would still not block the simplydumb device.

Interestingly enough, when I returned to Gnome, I realized that the commands given in VT were mirrored in Gnome in whatever window was open (which can lead to security issues!).

Was that open window an interactive shell (ie. you ran that command from *there*)?
Because at that point we're rather not looking at a merely stale framebuffer and maybe the console on the other VT is never really reached.

tethys · 2025-04-24 10:04:40

Seth wrote:

Was that open window an interactive shell (ie. you ran that command from *there*)?
Because at that point we're rather not looking at a merely stale framebuffer and maybe the console on the other VT is never really reached.

I know, that's what I thought at first when a terminal was open and the commands were mirrored in it. But then I checked again just while replying earlier to this thread and what I typed blindly appeared in the browser message window (and nothing appeared in the terminal window which was minimized).

seth · 2025-04-24 12:55:05

Gnome is wayland? Same w/ gnome on X11?

tethys · 2025-04-24 15:45:32

I don't use Wayland, only X11.

seth · 2025-04-24 18:59:48

Ok, does this happen w/ eg. an openbox session, even if you run picom along it? Or only w/ gnome?
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General

tethys · 2025-04-24 19:36:30

Unfortunately I do not have openbox installed on this computer at the moment so I cannot check that right away.
Xorg.log

seth · 2025-04-24 19:42:58

Fwwi, doesn't have to be openbox specifically - any WM (or actually no WM, but you'd at least to have to setup https://aur.archlinux.org/packages/xinit-xsession ) that is not gnome/mutter (or cinnamon/muffin) will do.

The xorg log is a bit older

[     5.327] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Apr 18 17:02:12 2025
…
[  3354.319] (II) Server terminated successfully (0). Closing log file.

but unsuspicious :\
(single GPU, single output, no errors, no completely bogus config files - the kernel didn't have the suggested parameters, obviously)

tethys · 2025-04-26 10:45:44

I tried to boot with

nvidia_drm.modeset=1 nvidia_drm.fbdev=0

to no effect, still no VTs visible:
Xorg.log

I also installed openbox but I am having trouble starting it with lightdm. I also tried to logout (which otherwise I never do) to see if I can choose from there an openbox session but I saw only a low-resolution black screen. Moving the mouse cursor I could see that it changes form like there is something to type in but I did not do anything blindly because I forgot how the login screen looks like. So I just rebooted blindly from a VT.

After reboot I looked a the logs and saw the following line in "seat0-greeter.log":

Failed to create GBM buffer of size 3840x2160: The argument ist invalid

So at this point I am not sure where to look further.

tekstryder · 2025-04-26 12:06:19

tethys wrote:

I tried to boot with
nvidia_drm.modeset=1 nvidia_drm.fbdev=0
to no effect, still no VTs visible

tekstryder wrote:

• IFF you're using nVidia GPU ✓
• which has been otherwise properly set up per all wiki instructions ???
• AND it's of a Pascal or older generation ✓

I suspect the 2nd bullet may not be completed.

Please post a full system journal from an affected boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

In your OP you stated you are using Gnome DE.

Did you try with GDM rather than lightdm?

tethys wrote:

So I just rebooted blindly from a VT.

You're creating a moving target with openbox, but you DID have a VT available in that case?

EDIT: See also...

• https://forums.developer.nvidia.com/t/n … ank/238007

-and-

• https://gitlab.archlinux.org/archlinux/ … /issues/16

Last edited by tekstryder (2025-04-26 12:10:28)

seth · 2025-04-26 16:45:20

I also tried to logout (which otherwise I never do)

Don't autologin, you should then have no problems to select an openbox session (@tekstryder, I asked for that to get the mutter compositor out of the way) - and are you btw 100% sure about gnome on X11?

loginctl session-status

tekstryder · 2025-04-26 17:01:10

seth wrote:

I asked for that to get the mutter compositor out of the way

Are you suggesting I should have read the entire thread, specifically #11-#13? The audacity.

The OP smelled like the old nVidia "No TTY For You!" issue with older cards, but perhaps there's more to it.

tethys · 2025-04-26 20:01:51

Thank you for your replies tekstryder and seth.

This computer runs for some 7 years with nvidia, so I suppose that the installation was done properly.

+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.133.07             Driver Version: 570.133.07     CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1080        Off |   00000000:01:00.0  On |                  N/A |
| 24%   38C    P8             12W /  180W |     550MiB /   8192MiB |      1%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A             723      G   /usr/lib/Xorg                           244MiB |
|    0   N/A  N/A             813      G   /usr/bin/gnome-shell                     92MiB |
|    0   N/A  N/A            1687      G   /usr/bin/gnome-system-monitor            11MiB |
|    0   N/A  N/A           35358      G   /usr/lib/firefox/firefox                165MiB |
+-----------------------------------------------------------------------------------------+

As I mentioned before, the VTs were working some time ago ...

And here is the journal for the boot with nvidia_drm kernel parameters: journal

$ loginctl session-status
1 - tethys (1000)
  Since: Sat 2025-04-26 10:40:05 CEST; 10h ago
  State: active
 Leader: 729 (lightdm)
   Seat: seat0; vc7
    TTY: tty7
 Remote: no
Service: lightdm-autologin
   Type: x11
  Class: user
Desktop: gnome
   Idle: no
   Unit: session-1.scope
         ├─729 lightdm --session-child 13 16
         └─759 /usr/lib/gnome-session-binary

Apr 26 10:40:05 asus systemd[1]: Started Session 1 of User tethys.

I am working on the problem with lightdm and openbox right now and I will report if I can reach the VTs from openbox as soon as I have that solved. A search for "Failed to create GBM buffer of size : invalid argument" brings results related to nvidia and arch and I am looking into that too. Unfortunately this is my homeoffice computer and therefore I have only very limited time left for debugging and rebooting.

tekstryder · 2025-04-26 20:59:35

tethys wrote:

I must mention that the VTs worked before, but it's a long time since I did not test them anymore (perhaps 2 years).

tethys wrote:

As I mentioned before, the VTs were working some time ago.

Yes. I have the same generation card as yours. TTY functionality for our cards was busted when fbdev=1 became the default, hence the advised kernel parameters you now have in place.

The two bug reports I linked upthread go into far more detail about this issue if you're curious.

tethys wrote:

This computer runs for some 7 years with nvidia, so I suppose that the installation was done properly.

That is not a safe assumption to make. There have been numerous changes from upstream to driver defaults, and even more changes to how Arch packages the driver.

The good news is that a lot of the user config and some various custom files previously advised by the Wiki are no longer necessary.

The bad news is figuring out what cruft is safe/good to remove, especially on a 7yr old install.

Firstly tho, it appears you have both GDM and lightdm active at the same time. You'll need to disable one or the other.

If you go the x11/lightdm/openbox route, @seth will take it from here

Side note: get rid of that nvidia-fake-powerd thingy.

tethys · 2025-04-26 22:00:54

I looked over the Wiki Nvidia page just to be sure and checked, everything seems to be OK.

I do not have gdm installed:

$ pacman -Qi gdm
error: package 'gdm' was not found

tekstryder wrote:

Side note: get rid of that nvidia-fake-powerd thingy

I checked some time after implementing nvidia-fake-powerd and at that time the problem was not solved, Are you sure the problem is now solved?

tekstryder · 2025-04-26 22:38:46

tethys wrote:

I do not have gdm installed

Derp, thought I saw a fully registered GDM session or was looking at the wrong log.

tethys wrote:

tekstryder wrote:
Side note: get rid of that nvidia-fake-powerd thingy
I checked some time after implementing nvidia-fake-powerd and at that time the problem was not solved, Are you sure the problem is now solved?

This?

• https://forums.developer.nvidia.com/t/b … ges/192892

If so, looks as if it was fixed back in the 510 driver a few years ago.

Back to your first post in the thread:

tethys wrote:

it does not switch to the virtual console: the graphical enironment just becomes unresponsive but I can switch back to a responsive graphical environment (GNOME) using Ctrl+Alt+F7

I only chimed in here as these are exactly the same symptoms of default fbdev=1 with Pascal or older GPU. We've ruled that out now.

tekstryder wrote:

Did you try with GDM rather than lightdm?

I'm still curious if the behavior is the same when using GDM.

tethys · 2025-04-27 10:07:26

OK, some success. Searching for "Failed to create GBM buffer of size : invalid argument" led me to the problematic package webkit2gtk, which is needed by lightdm-webkit2-greeter, which was the lightdm greeter when I got the error and the black screen. Changing the lightdm greeter allowed me to get to the login screen, from where I could chooose and run openbox. And indeed the VTs are accessible from openbox, ie I can see the text on the black background.

tekstryder · 2025-04-27 11:19:26

Okay, with the openbox tangent solved... and from Gnome? Can you reach a functional TTY?

tethys wrote:

I have indeed a file "/etc/modprobe.d/nvidia.conf" containing:
options nvidia_drm modeset=1 fbdev=1

Did you delete this file, or at least remove that line, and rebuild your initramfs?

Let's be sure:

cat /sys/module/nvidia_drm/parameters/fbdev

tethys · 2025-04-27 14:50:02

Yesterday I booted with the kernel parameters you mentioned earlier (nvidia_drm.modeset=1 nvidia_drm.fbdev=0) and I could not reach the VTs.

I removed the section of the file with "options nvidia_drm modeset=1 fbdev=1", but I did not regenerate initramfs. After reading once more the wiki I see that the "modconf" hook in "mkinitcpio.conf" takes into account the files in "/etc/modprobe.d/", so I should have done it. But do not the kernel parameter "nvidia_drm.fbdev=0" override the initial "/etc/modprobe.d/nvidia.conf" which was used when generating the initramfs?

You say that you also have nvidia and you can reach the VTs. Before I regenerate the initramfs can you tell me if you made any changes in the default "mkinitcpio.conf"?

As for now:

# cat /sys/module/nvidia_drm/parameters/fbdev
Y

By the way, i removed nvidia-fake-powerd and it's working fine, thank you for the tip!

seth · 2025-04-27 14:53:28

Yesterday you were still using the troublesome lightdm greeter, did you?
Tried after fixing that?

Arch Linux

#1 2025-04-18 16:52:14

[SOLVED]Cannot reach virtual console

#2 2025-04-18 19:32:25

Re: [SOLVED]Cannot reach virtual console

#3 2025-04-19 11:51:43

Re: [SOLVED]Cannot reach virtual console

#4 2025-04-23 18:43:14

Re: [SOLVED]Cannot reach virtual console

#5 2025-04-23 21:32:35

Re: [SOLVED]Cannot reach virtual console

#6 2025-04-24 06:18:52

Re: [SOLVED]Cannot reach virtual console

#7 2025-04-24 06:22:51

Re: [SOLVED]Cannot reach virtual console

#8 2025-04-24 10:04:40

Re: [SOLVED]Cannot reach virtual console

#9 2025-04-24 12:55:05

Re: [SOLVED]Cannot reach virtual console

#10 2025-04-24 15:45:32

Re: [SOLVED]Cannot reach virtual console

#11 2025-04-24 18:59:48

Re: [SOLVED]Cannot reach virtual console

#12 2025-04-24 19:36:30

Re: [SOLVED]Cannot reach virtual console

#13 2025-04-24 19:42:58

Re: [SOLVED]Cannot reach virtual console

#14 2025-04-26 10:45:44

Re: [SOLVED]Cannot reach virtual console

#15 2025-04-26 12:06:19

Re: [SOLVED]Cannot reach virtual console

#16 2025-04-26 16:45:20

Re: [SOLVED]Cannot reach virtual console

#17 2025-04-26 17:01:10

Re: [SOLVED]Cannot reach virtual console

#18 2025-04-26 20:01:51

Re: [SOLVED]Cannot reach virtual console

#19 2025-04-26 20:59:35

Re: [SOLVED]Cannot reach virtual console

#20 2025-04-26 22:00:54

Re: [SOLVED]Cannot reach virtual console

#21 2025-04-26 22:38:46

Re: [SOLVED]Cannot reach virtual console

#22 2025-04-27 10:07:26

Re: [SOLVED]Cannot reach virtual console

#23 2025-04-27 11:19:26

Re: [SOLVED]Cannot reach virtual console

#24 2025-04-27 14:50:02

Re: [SOLVED]Cannot reach virtual console

#25 2025-04-27 14:53:28

Re: [SOLVED]Cannot reach virtual console

Board footer