我去年8月出去旅行，今年8月出去旅行，在外面访问家里 memos，都挂了，我每次都吐槽出远门家中网络必挂，-_-。一开始我一直认为是主路由网络挂了，以前我用的是野路子来的 OpenWrt 固件（比如各种高大全固件），但是今年我转战了 ImmortalWrt 官方构建的固件，这个稳定性很好建议使用这个。建议从他们的 firmware-selector 网站下载适合你的镜像 -> https://firmware-selector.immortalwrt.org/

第一次down机买了个风扇给机械硬盘散热

最近发现可能不是这么回事，应该是我的 pve 宿主机和上面的 debian11 虚拟机的问题，这个问题从一次远程访问家中 pve 宿主机执行一些命令时候报错 Input/output error 开始。

我的 pve 宿主机上有两块磁盘，如下

NAME SIZE MODEL
sda 3.6T ST4000VX000-2AG166
nvme0n1 238.5G HS-SSD-C2000Pro 256G

在宿主机上执行各种需要读写磁盘的命令都会报错 Input/output error

回家后发现主机温度很高，直接强制断电了，然后将外壳拆下，发现机械硬盘非常烫，我就赶紧拿起风扇对着吹。

大概吹了30多分钟，主机很凉快了，尝试再次开机，发现一切如常。支线：决定购买风扇增加散热

第二次down机发现已失效的nfs挂载

第三天发现memos又无法访问了，进 pve 终端查看虚机状态是 RUNNING，但是 ping 不通，最后只好执行 qm stop 100 && qm start 100 重启了一下虚机，也正常了。接着进入debian11 的终端立即检查，发现了关键错误 Read-only file system, rsyslogd: file '/var/log/syslog' write error - OS error: Read-only file system

从日志中的 Read-only file system 错误可以看出，你的系统根文件系统已被内核强制挂载为 只读模式 。这是Linux系统检测到严重磁盘错误时的保护机制，防止进一步数据损坏。以下是详细分析和解决方案：

关键日志解读
核心错误 ：rsyslogd: file '/var/log/syslog' write error - OS error: Read-only file system
含义 ：rsyslog（系统日志服务）尝试写入 /var/log/syslog 时失败，因为文件系统已处于只读状态。

还有一段核心错误

kernel: FS-Cache: Duplicate cookie detected
kernel: FS-Cache: O-cookie c=00000000439c879b [p=000000000e48f285 fl=222 nc=0 na=1]
kernel: FS-Cache: N-key=[16] '0400000002000000020008010a0a0a01'

这段日志帮我找到了磁盘挂载的问题。我查看 /etc/fstab 发现了4个无效挂载点(下图是我注释之后截的)

原来是我以前在软路由（10.10.10.1）上接了这4块硬盘，但是后来取下了这几块硬盘，然后这边没删除，给忘掉了。几年前就意识到要将家里各种设备的职责划分清楚，软路由就只专心做好路由，不搞下载和做种，所以当时就把这几块硬盘拔掉了，对应的 NFS 服务也就不存在了。所以现在这个小问题的解决办法就是删除这几行或者注释这几行。

pve宿主机 /etc/fstab 这个文件还硬编码写死了这几个挂载，导致拖慢系统，有时候甚至卡死了，于是我赶紧添加了注释，重启了pve，再次执行 journalctl -b -p 3 --no-pager 输出如下

-- Journal begins at Sun 2025-07-27 21:59:23 CST, ends at Fri 2025-09-05 22:04:09 CST. --
-- No entries --

没有输出就是最好的状态，于是我以为这就解决问题了。

第三次down机安装intel-microcode后彻底解决

第四天发现又访问不了 memos 了。这一次一定要找到原因。在我大量的 google, bing, chatgpt, deepseek 之后，看到一些有用的信息，猜测有可能是内核版本 5.13.19，pve版本7.1-7，还有我的CPU Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz 之间的冲突。也看到了国内恩山论坛这个帖子

https://www.right.com.cn/forum/thread-8266555-1-1.html [虚拟机相关] 记录对于说N5105在PVE不稳定无故死机的一种解决方法

最后我增加了 non-free 的四个源之后，试图安装 intel-microcode，期待解决问题。

新的源文件/etc/apt/sources.list内容

# 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释
deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye main contrib
deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye main contrib non-free

deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-updates main contrib
deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-updates main contrib non-free

deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-backports main contrib
deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-backports main contrib non-free

# 以下安全更新软件源包含了官方源与镜像站配置，如有需要可自行修改注释切换
deb https://security.debian.org/debian-security bullseye-security main contrib
deb https://security.debian.org/debian-security bullseye-security main contrib non-free

执行 apt update 之后执行 apt-get install intel-microcode，成功安装 intel-microcode 软件包

一段和chatgpt的对话，它照着日志讲出了核心原因

目前接着观望pve宿主机和debian11虚机的运行情况。

后续更新

2025年09月15日上午更新，稳定运行，10.10.10.5 是虚拟机 IP，宿主机本身的IP是 10.10.10.3，虚机没断过网络，各种服务也没有 down 过。基本上可以判断出之前就是因为 intel 微码没有安装导致的虚拟机 down…… 不过这个机器组装以及系统安装是在 2021 年，怎么现在才出现这样的问题呢……有点不解

# uptime
08:54:49 up 8 days, 19:06,  1 user,  load average: 0.02, 0.03, 0.05

# ping -c 4 10.10.10.5
PING 10.10.10.5 (10.10.10.5) 56(84) bytes of data.
64 bytes from 10.10.10.5: icmp_seq=1 ttl=64 time=0.170 ms
64 bytes from 10.10.10.5: icmp_seq=2 ttl=64 time=0.198 ms
64 bytes from 10.10.10.5: icmp_seq=3 ttl=64 time=0.215 ms
64 bytes from 10.10.10.5: icmp_seq=4 ttl=64 time=0.214 ms

--- 10.10.10.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.170/0.199/0.215/0.018 ms