2024 年中秋适逢台风贝碧嘉来袭（熟悉的开头:D），强降水给小区带来的树倒、停电等一系列灾害，我的装了洗手.jpgManjaro 系统的 N100 小主机在 226 天的 uptime 后终于趁着停电休息了一把。供电恢复后通过 openVPN 、智能家居 app 发现路由器、 IoT 设备都已重新上线，困惑的是唯独这台小主机仍然处于失联状态。等到节后回来便研究了一番。以下全程感谢 @wzyboy 再一次的不吝指导。

接上显示器和外设开机发现，系统已经处于 emergency mode 状态。此时遇到的第一个坑是，emergency mode 的第一行提示 “loadkmap short read”，加上按一些字母键都没有反应（此时实为输入密码状态，但无回显），由于对 emergency mode 不熟悉使我和 gpt 误认为键盘映射出现问题。实际上此时只要输入 root 的密码就可以登录系统。

以 root 登录后输入 dmesg 查看内核输出的启动信息，发现在正常启动过程中有以下看起来很关键的报错：

intel_ish_ipc: ishtp-ish timed out waiting for fw-initiated reset
intel_ish_ipc: ISH: hw start failed.

于是一阵搜索，越搜越觉得困惑和茫然，是不是内核 bug，是不是硬件损坏…gpt 也小心翼翼地建议在 grub 启动项中屏蔽 ish 有关硬件，满怀希望地保存后重启，问题依旧。

emergency mode 中，系统很明确地提示要用 journalctl -xb 命令去查看启动日志，于是很仔细地查看这一千七百八行日志，这里我边看边在想，和 dmesg 不同的是阻塞正常启动的关键错误信息可能不会按时间顺序出现在日志的最后面，但仍会以不同颜色的字体标出。

仔细观察日志后发现与 /etc/fstab 有关的挂载错误，却没被我放在心上。我知道挂载一个不存在的分区会引起启动问题，因此在 /etc/fstab 中设置了 nofail 来长期把一移动硬盘挂载在系统中。虽然排错时移动硬盘未插入，不至于影响正常启动吧？所以又错过了奇点，从别的角度甚至是 USB Live CD 的 chroot 等方式试图修复系统。等到回过头继续从 journalctl -xb 日志侦错时，还是觉得大致记下报错的分区 UUID 去 /etc/fstab 看一眼吧。这一看才发现该 UUID 所对应的是一个未设置 nofail 、已经被合并了进 / 了的、不存在的分区，因为操作时间久远且一直未重启才忽略了该问题，注释该行，问题解决。

在排错的过程中，因为系统设置了中文导致 emergency mode 的字体全变成方块，这个问题在我首次接触 debian 时也遇到过，不过此次学到了通过设置变量 export LANG=C 的方法强制 fallback 到比 en_US.UTF-8 还基本的 locale 来避免中文显示问题。甚至还了解到了有趣的 Linux tty 勉强型中文字体——戴着有限字符空间的镣铐跳起支持中文的舞。又让我想起了一些汉化版 FC 游戏因 ROM 空间不足而被迫实施的一些奇技淫巧。

Linux 启动排错可能使人更有机会了解 “Linux 系统是怎么编排硬件的” 。而我一直想象的一个场景是：把桌面环境的 Linux 自行配置成家用路由器——通过安装 pppoe 、 upnp 等软件包来实现家用路由器功能；配置多网卡、网桥、路由表等来实现 WAN-LAN 口转发等，这样的场景想必更有挑战，也会使人更加了解 “Linux 系统是怎么编排网络的” 。