F45 的 kmscon 控制台：变了什么、怎么确认

Fedora 45 引入 kmscon 作为 VT 控制台的实现（官方 ChangeSet：Use kmscon as default VT console）。但「引入」和「你看到它」是两件事——下面的实测会让你少走一段弯路。

实际装了什么、谁在跑

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)

关键在第二张表：

[email protected] 是 enabled —— 这才是接管 VT 的单元，切到某个 tty 时按需启动 kmscon；
kmscon.service 是 disabled —— 它不是「让控制台变成 kmscon」的总开关，别把它当成故障。

怎么判断你的控制台到底是谁在画

这条命令是分水岭：

cat /sys/class/vtconsole/*/name

(M) frame buffer device
(M) dummy device

(M) 表示当前绑定的后端。如果第一行是 frame buffer device，说明此刻仍是内核 fbcon 在画字符，kmscon 没有接管。

在纯虚拟机（无 KMS 驱动、无 GPU 直通）上，这个结果很常见，而且 Cloud 与 Server 镜像的表现一致——所以「Cloud 没启用、Server 才有」的说法不准确。

常见误判

你看到的	可能的真相
`kmscon.service` 是 disabled	正常，接管靠 `kmsconvt@`
`/sys/class/vtconsole` 里没有 kmscon	虚拟机没有 KMS 驱动，回落到 fbcon
本地控制台字体和以前一样	同上，仍是 fbcon
远程正常、本地花屏	多半是 DRM/驱动问题，不是 kmscon

真正出问题时怎么查

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

顺序建议：

先确认是不是停在了别的 VT（Ctrl+Alt+F2 等）；
再看 /sys/class/vtconsole 判断后端；
然后才看日志与 dmesg 里的 DRM 报错。

什么时候这个变化对你可见

有独立显卡或核显直通：kmscon 能拿到 KMS 设备，字体与 Unicode 渲染和以前不同；
纯虚拟机、串口控制台：基本无感，VT 还是 fbcon；
服务器带 IPMI/远程 KVM：取决于 BMC 暴露的显示设备，值得单独验证一次。