老本回春实录：当 Linux 把「锅」甩给了硬件，我信了
今天修了一台颇有年纪的 Acer Aspire S3。客户描述的症状很"玄学"：开机卡 LOGO，进系统后键盘时灵时不灵，还经常弹出"系统已禁用迟滞键"的提示。
作为一个常年和 Linux 打交道的老司机，我的第一反应是：这肯定是 XKB 配置冲突，或者是 i8042 内核参数的锅。
于是，一场"打怪升级"开始了。
第一关：GRUB 的倔强
刚接手时，机器直接 Kernel Panic，报错 VFS: Unable to mount root fs。
排查发现，这台老机器用的是 GPT 分区表，却跑在 Legacy BIOS 模式下。这种组合有个死穴：必须在磁盘最前面预留一个 1MiB 的 bios_grub 分区，GRUB 才能把引导代码嵌进去。显然，之前的引导结构崩了。
好在修复难度不大，Live USB 进系统，chroot 环境里一顿操作，update-initramfs 和 grub-install 走起。搞定引导，顺利进入桌面。
第二关：薛定谔的键盘
本以为大功告成，结果进系统没多久，键盘又开始"抽风"。难道是我之前写的键盘修复脚本（专门对付粘滞键误触的）有 Bug？
我决定用最"硬核"的方式验证——直接读 /dev/input/eventX。
写了一个简单的 Python 监听器，不碰键盘，看着终端。结果令人震惊：即便我手指完全离开键盘，终端里依然在疯狂滚动 key event 日志。
这说明什么？说明内核层真的在接收到"按键信号"。这已经不是 X11 或 Wayland 的软件问题了，而是硬件在"鬼手"操作。
第三关：终极宣判
为了彻底排除软件干扰，我插上了一个 USB 键盘。
结果：USB 键盘稳如老狗，毫无异常。
内置键盘：依然在自嗨。
结论实锤：内置键盘硬件故障。要么是排线氧化接触不良，要么是键盘矩阵老化漏电。那个"迟滞键禁用"的提示，其实是系统在无奈地说："大哥，你按得太快太乱了，我只能帮你屏蔽掉。"
结局与感悟
最后给客户的方案很简单：要么拆机重插排线，要么干脆外接键盘继续用。
这台 S3 的 CPU 和 SSD 其实还能战，可惜败给了岁月和物理层面的损耗。
这次排查也给我提了个醒：在 Linux 世界里，我们习惯了怀疑内核、怀疑驱动、怀疑配置。但有时候，信任 dmesg 和 /dev/input 的原始数据，才能看到真相。
修电脑如是，写代码亦如是。遇到诡异 Bug，不妨沉到最底层看一看。
提示：本页为真实维修与排障记录，已做匿名脱敏处理。硬件故障原因、修复方法及结果仅适用于该设备与对应测试条件。涉及拆机与硬件操作存在风险，如无把握请先联系专业人员评估。