Dear Maintainer,

I am currently testing kmscon in forky inside a QEMU KVM guest.
When forky runs on a linux-image-amd64 kernel, kmscon appears to run and handle TTY switching fine (with CTRL-ALT-F<number>),
both between instances of itself and to/from instances of getty@.service. Disabling getty@.service and enabling kmsconvt@.service,
to set kmscon as default for all TTYs, also appears to work well after a reboot.

However, for lightweight VMs, I prefer running linux-image-cloud-amd64. When running this kernel flavour,
roughly 3 out of 5 times, switching from fbcon to kmscon or between kmscon TTYs apparently causes the target TTY to freeze.

How this "freeze" appears depends on whether QEMU is running the VM on its default virtual firmware (= Legacy BIOS)
or OVMF (= UEFI). On the former, a frozen kmscon typically appears as a black screen, while on OVMF I can at least
see a solid (non-blinking) kmscon cursor in the upper-left corner of QEMU's virtual screen.

Sometimes (= not always), attempts to switch back to a default non-kmscon console from a frozen kmscon
(with CTRL-ALT-F<number>) will even cause *all* ttys to freeze (regardless of whether they run fbcon or kmscon),
forcing me to stop kmsconvt@tty<number>.service via SSH or a serial console.

The same apparent game of chance applies on every boot if I try
'systemctl enable getty@.service && systemctl enable kmsconvt@.service'
followed by rebooting the VM (in an attempt to make kmscon the system-wide default for all new TTYs).

If, on a forky VM with these symptoms, I install and reboot into a build of linux-image-amd64
(instead of ...cloud-amd64), the problem seems to disappear completely.
Boot the same VM guest back into ...cloud-amd64, and the game of chance returns.



How to reproduce:

1. Boot your functioning Debian forky VM.
It should be able to reach an official package mirror and should be using the default getty@.service for all TTYs.
Example basic QEMU command *without* OVMF/UEFI:
qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -smp 2 -m 4G -netdev user,id=natdev0,hostfwd=tcp::2222-:22 -device virtio-net-pci,mac="$(randmac --qemu)",netdev=natdev0,id=natnic0 -smbios type=41,designation=onboardlan,instance=1,kind=ethernet,pcidev=natnic0 -drive file=/path/to/your-vdisk.qcow2,if=virtio,format=qcow2
2.1 If you are using linux-image-amd64, enter command inside guest: apt -y install linux-image-cloud-amd64.
(otherwise, skip to step 3.)
2.2 Reboot the guest, making sure it boots into the kernel which was just installed.
3. Enter command inside guest: apt -y install kmscon
4. Enter command inside guest: systemctl start kmsconvt@tty2.service
5. Press CTRL-ALT-2 to switch to QEMU's 'compatmonitor0'.
6. Enter command in QEMU's 'compatmonitor0': sendkey ctrl-alt-f2
7. Press CTRL-ALT-1 to switch back to your VM guest screen.
Observe whether you get a working and responsive console, or a frozen one.
8. Press CTRL-ALT-2 to switch to QEMU's 'compatmonitor0'.
9. Enter command in QEMU's 'compatmonitor0': sendkey ctrl-alt-f1.
This should return you to your working, "classic" console on tty1,
either still reponsive or, if kms was also frozen, also frozen.
10. If necessary, repeat steps 5-9 a few times to provoke a frozen kmscon.



Workaround:

Install and boot into linux-image-amd64 instead of linux-image-cloud-amd64.
It will take up more storage space and RAM, but kmscon will apparently run and switch just fine.



Other troubleshooting info:

When I provoke the issue, kmscon itself outputs the following line once:

  Error: video_fbdev: cannot get finfo (9): Bad file descriptor

...followed by repeated lines of the following, until I manage to switch away or kill it:

  Warning: terminal: cannot swap display [fbdev] -22

dmesg does not show any complaints from the kernel side. I know kmscon is a userland program,
but thought I'd check anyway since switching from/to default fbcon is part of it.

I have, unsuccessfully, tried playing around with the --no-drm and --no-mouse options.

The kmscon project's own documentation [1] does not seem to specify what kind of kernel config
settings/modules it needs, and I lack the knowledge necessary to narrow down which options it would
need to be set a certain way in order to run and switch properly
(assuming, possibly in error, that the kernel is lacking something).



I am not sure whether I should file this bug against kmscon, linux, qemu, or another package.
I picked kmscon for now, since that is the package I am having apparent basic usage issues with.
Please feel free to correct me on that and/or which additional package(s) it affects.
Severity set to important per explanation in reportbug.

Thank you.

[1] https://github.com/kmscon/kmscon/tree/main#requirements

On Fri, 16 Oct 2026 14:15:29 +0000 Aka Sikrom <asikrom@proton.me> wrote:
 > Package: kmscon
 > Version: 10.0.4-1
 > Severity: important
 > X-Debbugs-Cc: asikrom@proton.me
 >
 > Dear Maintainer,
 >
 > I am currently testing kmscon in forky inside a QEMU KVM guest.
 > When forky runs on a linux-image-amd64 kernel, kmscon appears to run and handle TTY switching fine (with
CTRL-ALT-F<number>),
 > both between instances of itself and to/from instances of getty@.service. Disabling getty@.service and enabling
kmsconvt@.service,
 > to set kmscon as default for all TTYs, also appears to work well after a reboot.
 >
 > However, for lightweight VMs, I prefer running linux-image-cloud-amd64. When running this kernel flavour,
 > roughly 3 out of 5 times, switching from fbcon to kmscon or between kmscon TTYs apparently causes the target TTY to
freeze.
 >
 > How this "freeze" appears depends on whether QEMU is running the VM on its default virtual firmware (= Legacy BIOS)
 > or OVMF (= UEFI). On the former, a frozen kmscon typically appears as a black screen, while on OVMF I can at least
 > see a solid (non-blinking) kmscon cursor in the upper-left corner of QEMU's virtual screen.
 >
 > Sometimes (= not always), attempts to switch back to a default non-kmscon console from a frozen kmscon
 > (with CTRL-ALT-F<number>) will even cause *all* ttys to freeze (regardless of whether they run fbcon or kmscon),
 > forcing me to stop kmsconvt@tty<number>.service via SSH or a serial console.
 >
 > The same apparent game of chance applies on every boot if I try
 > 'systemctl enable getty@.service && systemctl enable kmsconvt@.service'
 > followed by rebooting the VM (in an attempt to make kmscon the system-wide default for all new TTYs).
 >
 > If, on a forky VM with these symptoms, I install and reboot into a build of linux-image-amd64
 > (instead of ...cloud-amd64), the problem seems to disappear completely.
 > Boot the same VM guest back into ...cloud-amd64, and the game of chance returns.
 >
 >
 >
 > How to reproduce:
 >
 > 1. Boot your functioning Debian forky VM.
 > It should be able to reach an official package mirror and should be using the default getty@.service for all TTYs.
 > Example basic QEMU command *without* OVMF/UEFI:
 > qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -smp 2 -m 4G -netdev user,id=natdev0,hostfwd=tcp::2222-:22
-device virtio-net-pci,mac="$(randmac --qemu)",netdev=natdev0,id=natnic0 -smbios 
type=41,designation=onboardlan,instance=1,kind=ethernet,pcidev=natnic0 -drive
file=/path/to/your-vdisk.qcow2,if=virtio,format=qcow2
 > 2.1 If you are using linux-image-amd64, enter command inside guest: apt -y install linux-image-cloud-amd64.
 > (otherwise, skip to step 3.)
 > 2.2 Reboot the guest, making sure it boots into the kernel which was just installed.
 > 3. Enter command inside guest: apt -y install kmscon
 > 4. Enter command inside guest: systemctl start kmsconvt@tty2.service
 > 5. Press CTRL-ALT-2 to switch to QEMU's 'compatmonitor0'.
 > 6. Enter command in QEMU's 'compatmonitor0': sendkey ctrl-alt-f2
 > 7. Press CTRL-ALT-1 to switch back to your VM guest screen.
 > Observe whether you get a working and responsive console, or a frozen one.
 > 8. Press CTRL-ALT-2 to switch to QEMU's 'compatmonitor0'.
 > 9. Enter command in QEMU's 'compatmonitor0': sendkey ctrl-alt-f1.
 > This should return you to your working, "classic" console on tty1,
 > either still reponsive or, if kms was also frozen, also frozen.
 > 10. If necessary, repeat steps 5-9 a few times to provoke a frozen kmscon.
 >
 >
 >
 > Workaround:
 >
 > Install and boot into linux-image-amd64 instead of linux-image-cloud-amd64.
 > It will take up more storage space and RAM, but kmscon will apparently run and switch just fine.

Hi,

Thanks for the detailed bug report. This is likely an upstream bug as reported by
https://github.com/kmscon/kmscon/issues/577 .

About Legacy BIOS: the cloud-amd64 kernel has neither DRM nor a VESA framebuffer
driver, so under BIOS kmscon has no graphics device to draw on at all and a black
screen is expected there. That part is likely a limitation of the kernel flavour rather than
this bug.

Thanks,
Boyuan

We believe that the bug you reported is fixed in the latest version of
kmscon, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1151059@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Boyuan Yang <byang@debian.org> (supplier of updated kmscon package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 17 Oct 2026 00:12:10 -0400
Source: kmscon
Architecture: source
Version: 10.0.4-2
Distribution: unstable
Urgency: medium
Maintainer: Boyuan Yang <byang@debian.org>
Changed-By: Boyuan Yang <byang@debian.org>
Closes: 1151059
Changes:
 kmscon (10.0.4-2) unstable; urgency=medium
 .
   * debian/patches: Add patches to fix frozen or blank VTs with the
     fbdev backend after VT switches (Closes: #1151059).
Checksums-Sha1:
 64f20c63a0f28b93194cd79eb861a7ed3f166b2e 2890 kmscon_10.0.4-2.dsc
 075743506f441ae3eedbad9646d68b0f66f5503f 1981969 kmscon_10.0.4.orig.tar.gz
 3d772893fc487bdeb7d669e5e4f0c87a2e956663 13804 kmscon_10.0.4-2.debian.tar.xz
 cc19e043cda12230768b2737a9e84ad3463223b3 11746 kmscon_10.0.4-2_amd64.buildinfo
Checksums-Sha256:
 3b7f716fe6c65ea8518adddfd6ba8c74180f613135a6f0b3fb07f4c833e9b153 2890 kmscon_10.0.4-2.dsc
 6ba69baaa3fe72de361c56c98a1b2bf77b206d043415bc00109a0c27ef7cefdb 1981969 kmscon_10.0.4.orig.tar.gz
 e167f346ece3782bcbcbded1de02dee65429b975722cd6a846c49e3a157698ea 13804 kmscon_10.0.4-2.debian.tar.xz
 6d0f673bf6b015718950ee7316984aa039f4852234f7aeb3a2690773dec04946 11746 kmscon_10.0.4-2_amd64.buildinfo
Files:
 84cafc339ca4c48e21eba85724f0871f 2890 utils optional kmscon_10.0.4-2.dsc
 e0903180dc9174d5fdee842a9451aff4 1981969 utils optional kmscon_10.0.4.orig.tar.gz
 599564aeef9d2ebd9bbd443300e39433 13804 utils optional kmscon_10.0.4-2.debian.tar.xz
 ce79c6ccc99eb375a3ab75f67d348f57 11746 utils optional kmscon_10.0.4-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmrS+MYACgkQwpPntGGC
Ws6eMA/7BKyQbyON3RglWmNhfh2FEHunXbcta/X6+grEhWusWf7aqsBga5S6JHsf
VsdyX3bGHuIt42bL9DL5/8eVMieq+J7WiBQM8X/XKVveA/Q34x28R+KdeZplLv1b
H1SJX206r/u3fRkA6KswgJSQsAND47BAmy8oFxVQj8IRHG9ZrPE0JD3xl3imorTv
tBhTqs0GIa6JcqHthVYlUuBxD3wXJu0XI2t2u6K7T0gsTAm/Nv5pSBrXEGa5B1y+
j9znODG2ZC+4kPK3lYmUu9ZLqWqeJEGt6yJdBhRCSV5n+W7JHW3YyCH0mQR990ph
OvRF3/iCYFVyDIhgkxBII4kIFa++hhATaeyp64c95XTi+LAXODMlLgY4I+Yc8G+C
Vp/EVF/I3Qm+J2p0z62zNZszWGGiQgOAL5wcXXBpzuZE4KV3o0H161Gsh5bPdzr+
7bU0k2PgEq91cJ0xEMNUrzqcmdB9lCC/YYMuHIX8bRURekC7dnIL/w2UX23VPXMf
TeGH8wQ5xa9hhbt+/Wul6nC4QFZ9L4yubAVDnx31opvmFCOVaUcDXNJJkrCwGGBH
IbFY2rHtWEY/n4RESpMs3gFy+yiepO4SdeCNXUOnQ5m8GZToGRnsPyKiD0Euuxb9
tVAxVbYA4nY8E5xUfRn06KBglhlI9WipgXZYgPLVwlydFJKdrAo=
=UtlE
-----END PGP SIGNATURE-----