Fedora Account System
Red Hat Associate
Red Hat Customer
I run pre-release and rawhide Fedoras in virtualbox VMs for quick testing while leaving my systems running a released version. Just fired up a new VM with f45, and the vt console is essentially unusable. I understand it's been switched for this release to use fbcon. In any case, after opening a new virtual console I completely lose keyboard input in between 0 (can't even start typing login name) to well less than 100 characters. Consistently. Occasionally it stays working long enough run a command, a couple of times that output has stopped as well. I don't run graphical envs by default on these, for quick startup (that is, use multiuser.target instead of graphical.target). I tried a supposed workaround I found, to add "vconsole.use_kmscon=0" to the boot, but that didn't actually seem to help. Booting an f44 kernel cleans up the problem completely. Reproducible: Always
I also do test in VM (usually with KVM), but never experience a lock-up. Can you switch to another VT when that occurs ? Also kmscon is userspace, so changing the kernel command line has no effect. You can use `systemctl mask kmsconvt@.service` to disable it. By "Booting an f44 kernel", you mean booting rawhide with a F44 kernel, or a F44 VM ? Changing the kernel should have no impact on kmscon unless there are some driver issues.
Sorry, to clarify... vt switching works (for virtualbox, that's right-ctrl + FN), but the new one will lock up the same. "Booting f44" - this is a clone of an f44 VM, upgraded to f45's current state with dnf version-upgrade. As such it still has a bootable f44 kernel on it. 7.1.9-200.fc44.x86_64 and 7.2.1-300.fc45.x86_64 these are unmodified, just right off the packages. Thanks for the systemctl incantation, I'll try that.
I started the latest F45 compose in VirtualBox, and I can reproduce it. I think it's a screen refresh problem, because the command I type blindly are correctly executed. switching VT from ssh, using `sudo chvt 2` and back to vt 1, restore it for a few minutes, and I can see what I typed blindly before it freezes again. I found a workaround by disabling the vmwgfx graphic driver with: sudo grubby --update-kernel=ALL --args=modprobe.blacklist=vmwgfx So there is something between vmwgfx and kmscon, in the way the pageflip is done.
I've implemented a better workaround in kmscon, which is to use legacy modesetting/pageflip with the vmwgfx driver until a proper fix is found. https://github.com/kmscon/kmscon/pull/515
I found the root cause, and implemented a proper fix in kmscon. The problem arise when vmwgfx driver returns -EBUSY for a pageflip. (which is perfectly valid). Then scr->swapping was never cleared, so kmscon never tried to redraw the screen. https://github.com/kmscon/kmscon/pull/516 I will backport this fix to f45
FEDORA-2026-756d8c0914 (kmscon-10.0.3-2.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-756d8c0914
FEDORA-2026-756d8c0914 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-756d8c0914` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-756d8c0914 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
+3 in https://forge.fedoraproject.org/quality/blocker-review/issues/2169 , marking accepted FE.
FEDORA-2026-756d8c0914 (kmscon-10.0.3-2.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.