Control: forwarded -1 https://github.com/kmscon/kmscon/issues/577
Control: tags -1 + upstream
On Fri, 16 Oct 2026 14:15:29 +0000 Aka Sikrom <[email protected]> wrote:
> Package: kmscon
> Version: 10.0.4-1
> Severity: important
> X-Debbugs-Cc: [email protected]
>
> 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 [email protected]. Disabling [email protected] and enabling
[email protected],
> 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 [email protected] && systemctl enable [email protected]'
> 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 [email protected] 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 [email protected]
> 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
