Fedora 45's kmscon console: what changed and how to check

Fedora 45 introduces kmscon as the VT console implementation (official ChangeSet: Use kmscon as default VT console). But “introduced” and “you can see it” are two different things — the measurements below save you a detour.

What is installed, and what actually runs

rpm -q kmscon
systemctl list-unit-files "kmscon*"
systemctl status kmscon --no-pager | head -3

kmscon-10.0.3-2.fc45.x86_64

UNIT FILE          STATE    PRESET
kmscon.service     disabled disabled
[email protected]  enabled  enabled

○ kmscon.service - KMS System Console
     Loaded: loaded (/usr/lib/systemd/system/kmscon.service; disabled; preset: disabled)
     Active: inactive (dead)

The second table is the point:

• [email protected] is enabled — this is the unit that takes over a VT, starting kmscon on demand when you switch to a tty;
• kmscon.service is disabled — it is not the master switch for “make the console kmscon”, so do not read it as a fault.

How to tell who is drawing your console

This command is the dividing line:

cat /sys/class/vtconsole/*/name

(M) frame buffer device
(M) dummy device

(M) marks the currently bound backend. If the first line is frame buffer device, the in-kernel fbcon is still drawing characters and kmscon has not taken over.

On a plain virtual machine (no KMS driver, no GPU passthrough) this is a normal result, and the Cloud and Server images behave the same — so “Cloud does not enable it, only Server does” is not accurate.

Caution

On F45 we checked the Cloud and Server images separately: both have kmsconvt@ enabled, kmscon.service disabled, and the VT still provided by fbcon. The difference only shows up on hardware with a real DRM driver.

Common misreadings

What you see	Likely truth
kmscon.service is disabled	normal; takeover comes from kmsconvt@
no kmscon in /sys/class/vtconsole	the VM has no KMS driver and falls back to fbcon
the local console font looks unchanged	same as above, still fbcon
remote fine, local garbled	most likely DRM/driver, not kmscon

What to check when something really breaks

journalctl -b -u kmsconvt@tty1 --no-pager | tail -20
journalctl -b -u kmscon --no-pager | tail -20
dmesg | grep -iE "drm|kms" | tail -10

Suggested order:

1. confirm you are not simply on another VT (Ctrl+Alt+F2 and so on);
2. check /sys/class/vtconsole to identify the backend;
3. only then look at the logs and DRM errors in dmesg.

Danger

Do not start changing kernel parameters (nomodeset, video= and the like) when the console misbehaves. That changes the boot chain and the graphics stack at once, turning one problem into two, and it is hard to undo cleanly.

When you will actually notice

• Discrete GPU or integrated graphics passthrough: kmscon gets a KMS device, so fonts and Unicode rendering differ from before;
• Plain VMs and serial consoles: essentially no change, the VT is still fbcon;
• Servers with IPMI or remote KVM: depends on the display device the BMC exposes, worth verifying once.

Related pages

• Fedora 45: changes, download and upgrade — the six changes at a glance
• Upgrading to Fedora 45 — post-upgrade checks
• Fedora kernel and hardware compatibility — boot chain and kernel-side troubleshooting
• Official: Fedora 45 ChangeSet