[solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

kermit63 · 2022-12-08 05:10:45

I very rarely use virtual consoles but recently found I can't invoke it using ctrl-alt-fn on my main installation. I dismissed the problem as probably related to the nvidia-390xxk-dkms driver that I use, but didn't really pursue troubleshooting any further.

Yesterday I booted to the 12-02 arch live ISO to do some lvm partition resizing and found the same problem. I got curious since this rules out the nvidia driver as the culprit.

Since I use ventoy and have several other ISOs on the stick, I found that all arch-based live ISOs I have (12-02 arch, manjaro and endeavourOS) suffer the same problem. The debian-based clonezilla ISO works just fine however. The main difference as far as I can tell is that the clonezilla ISO still uses kernel 5.19.x.

To test this hypothesis, I created a separate lvm partition and installed a very basic arch on it with both linux-lts and linux kernel, intel-ucode and lvm2 and nothing else. I found that I can switch virtual console with the linux-lts kernel but not with the stock linux kernel.

I googled around for similar problems but the most I can find relates to laptop keyboards requiring the press of a special key to activate function keys. This is not my case since I'm using a pretty standard desktop keyboard.

BTW, the PC in question is an intel i3-4th gen with nvidia gt730 gpu. Too bad I gave away my 2 other newer computers during the height of the pandemic so I can't check if the problem is specific to this machine alone.

Last edited by kermit63 (2022-12-08 09:45:00)

seth · 2022-12-08 07:31:14

Can you still https://man.archlinux.org/man/core/kbd/chvt.1.en ?

kermit63 · 2022-12-08 08:04:06

Thanks for the response.

No. chvt behaves the same way as if pressing ctrl-alt-fn. Works for linux-lts but not for the stock kernel.

seth · 2022-12-08 08:25:19

Does it work if you boot w/ "nomodset"?
Out of what context does it fail? From the archiso attempt, probably incl. the multi-user.target (console only)?

kermit63 · 2022-12-08 09:43:51

wow. "nomodeset" actually solved the problem. It never occurred to me to try it since I never had to add it with the older kernels to enable virtual consoles or boot to multi-user.target.

Some context:

For the previous chvt suggestion, I booted into the arch iso and issued a chvt 2 command and the screen just froze until I pressed ctrl-alt-f1 and I got back to the original screen. Also tried it with the test basic arch install and issued the chvt command after logging in. It failed in the sense that the screen just froze until I hit ctrl-alt-f1.

For nomodeset, I booted into the arch iso after pressing 'e' to add nomodeset. This time ctrl-alt-fn worked as it should in the sense that a new login screen showed up under tty2. Tried it with both the test basic arch install and my main install with the same successful result.

To make the change permanent, I added "nomodeset" as a kernel parameter to my custom grub.cfg.

Thanks for the help.

Is this some sort of regression in the newer kernel? I have to admit I know very little of the linux kernel and just treat it as a black box that provides drivers for various devices.

Last edited by kermit63 (2022-12-08 09:51:10)

seth · 2022-12-08 11:53:24

"nomodeset" is probably not a good solution, in particular you should have troubles to start any GUI target (but for the VESA driver)?
But it suggests that the issue is w/ the fb console - there's no second GPU in the system?

nvidia historically had issues w/ fb consoles, in that case you could try eg. https://wiki.archlinux.org/title/GRUB/T … ramebuffer

Do you have a journal from an affected boot? ("sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st" to upload the previous one)

kermit63 · 2022-12-08 14:14:16

seth wrote:

"nomodeset" is probably not a good solution, in particular you should have troubles to start any GUI target (but for the VESA driver)?
But it suggests that the issue is w/ the fb console - there's no second GPU in the system?

Hmm, you may be on to something. Does the integrated intel gpu count as a 2nd GPU? If it does then yes. In the UEFI setup, I chose nvidia as the primary gpu, but there was no option to turn off the integrated one.

Good thing I'm an old fart who keeps detailed documentation of my arch install from 8-10 years back. Based on my notes, I had trouble starting graphical target upon installation of the nvidia driver via startx although nouveau worked just fine. What's funny is the problem seemed to have resolved itself after I arch-chrooted into the system and installed lightdm.

A few years later, I saw the 2nd link on your sig and thought I'd give it a try (set multi-user.target as default) but was unable to do so. The system will boot, spew out a few lines of comments typical of the booting process, then freeze. Reverting the default back to graphical.target gave me back my working installation.

When I started noticing my inability to use virtual consoles, I experimented a bit with the combo of lightdm and nvidia driver. The results were:
- if both are installed, I can boot to graphical target.
- if either one of the two (lightdm and/or nvidia driver) is uninstalled, I am unable to boot to graphical target.

nvidia historically had issues w/ fb consoles, in that case you could try eg. https://wiki.archlinux.org/title/GRUB/T … ramebuffer

II'm currently doing a linear programming run which might take another 6-8 hours to complete. The save and restore feature of the software I'm using is a bit wonky so I'm hesitant to reboot. I'll give it a try afterwards.

Do you have a journal from an affected boot? ("sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st" to upload the previous one)

I've done so many reboots while testing the system that it's difficult for me to keep track of which journal to post. Just to be sure, I'll remove "nomodeset", which will result in an affected boot, then post that journal. Hopefully after 6-9 hours.

kermit63 · 2022-12-09 00:23:20

The link you provided to disable framebuffer gave 2 options, so I tried both.

GRUB_GFXPAYLOAD_LINUX=text resulted in a boot error with the message "no suitable video mode found" and then froze. It never even got to the luks passphrase prompt, so I assume no jounral entry was created for this attempt.

GRUB_TERMINAL_OUTPUT=console resulted in a modified grub screen and booted successfully. However, virtual consoles are still disabled.

In both attempts, I removed the "nomodeset" kernel parameter from grub.cfg.

The corresponding journal for the 2nd option: http://0x0.st/od9y.txt

seth · 2022-12-09 09:25:31

Dec 09 07:59:54 arch kernel: pci 0000:01:00.0: vgaarb: setting as boot VGA device
Dec 09 07:59:54 arch kernel: pci 0000:01:00.0: vgaarb: bridge control possible
Dec 09 07:59:54 arch kernel: pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
…
Dec 09 07:59:54 arch kernel: fb0: EFI VGA frame buffer device
…
Dec 09 07:59:54 arch kernel: nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
Dec 09 07:59:54 arch kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module  390.154  Wed Jun 22 04:50:54 UTC 2022 (using threaded interrupts)
…
Dec 09 07:59:56 arch kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

Try to blacklist i915, "module_blacklist=i915" and enable https://wiki.archlinux.org/title/NVIDIA … de_setting

kermit63 · 2022-12-09 11:57:42

please ignore the previous nonsense I posted. As it turned out I made a typo in adding the kernel parameters.

i915 is now blacklisted and kms early loading enabled.

I can now access the virtual console.

To summarize:

Early KMS loading by itself did not seem to affect the behavior of the virtual console.
It was the blacklisting of i915 that yielded the desired result.

@seth Thanks for all the help and patience.

Last edited by kermit63 (2022-12-09 12:14:42)

V1del · 2022-12-09 12:04:31

Afaik i915 gets pulled in by snd-hda for potential HDMI ports or so, to be sure sure make the modprobe.d/i915.conf read

install i915 /usr/bin/true

kermit63 · 2022-12-09 12:07:28

@videl sorry for wasting your time. I made a typo in the kernel parameters. All is working now.

Arch Linux

#1 2022-12-08 05:10:45

[solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#2 2022-12-08 07:31:14

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#3 2022-12-08 08:04:06

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#4 2022-12-08 08:25:19

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#5 2022-12-08 09:43:51

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#6 2022-12-08 11:53:24

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#7 2022-12-08 14:14:16

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#8 2022-12-09 00:23:20

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#9 2022-12-09 09:25:31

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#10 2022-12-09 11:57:42

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#11 2022-12-09 12:04:31

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

#12 2022-12-09 12:07:28

Re: [solved]lvirtual console (ctrl-alt-fn) stopped working with kernel 6.x

Board footer