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. 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 -- System Information: Debian Release: forky/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 7.2.9+deb14-cloud-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages kmscon depends on: ii init-system-helpers 1.69+nmu3 ii libc6 2.43-7 ii libdbus-1-3 1.16.2-8 ii libdrm2 2.4.134-3 ii libegl1 1.7.0-3+b1 ii libfontconfig1 2.17.1-5 ii libfreetype6 2.14.3+dfsg-3 ii libgbm1 26.1.6-1 ii libgles2 1.7.0-3+b1 ii libglib2.0-0t64 2.90.1-2 ii libpango-1.0-0 1.58.2-1 ii libpangoft2-1.0-0 1.58.2-1 ii libtsm4 4.8.0-0.1 ii libudev1 262-1 ii libxkbcommon0 1.13.1-1 ii login 1:4.16.0-2+really2.42.4-1 ii ncurses-term 6.6+20260608-2 ii zlib1g 1:1.3.dfsg+really1.3.2-3 kmscon recommends no packages. kmscon suggests no packages. -- no debconf information
