最近在做一批 Linux 主机的 CVE 漏洞修复，遇到一个比较实际的问题，想请教一下大家有没有成熟的处理方式。
因为很多安全补丁，现在都是涉及到内核级别，安装完成后都需要重启才能真正生效，但是在批量重启主机之前，也遇到了 /etc/fstab 中存在异常配置而无法拉起的情况。
因为如果 /etc/fstab 里存在错误，比如：
UUID 或设备路径错误 文件系统类型错误 挂载参数不支持 本地设备不存在 NFS 等网络文件系统不可达 其他只有实际挂载时才会暴露的问题
都有可能导致主机重启后进入救援，或无法拉起
目前想要与大家探讨的是：
希望在 reboot 之前，对 /etc/fstab 做一次尽可能接近真实挂载结果的检查，但又不能真正执行挂载操作，也不能对当前系统状态造成影响。
我测试过：
mount -a -v -f
以及：
findmnt --verify --verbose
但实际测试下来，这两种方式的结果都无法完全和真正执行：
mount -a
的结果对应起来。
问题在于，大批量生产主机又不适合在重启前直接执行 mount -a 。
因为 mount -a 可能会把当前未挂载的文件系统真正挂载起来，也可能主动访问 NFS 、NAS 等网络存储，甚至改变当前系统状态。在复杂生产环境中，这种操作有可能产生额外影响，极端情况下甚至可能出现不可逆的问题。
所以想请教一下大家：
有没有一种相对可靠的方式，可以做到：
不实际 mount / umount 不产生真实写入 不改变当前系统状态 尽量检查出设备、UUID 、文件系统类型、挂载参数、网络挂载等问题 检查结果尽可能接近真实的 mount -a 最好适合通过 Ansible 、Shell 等方式批量执行
或者大家在做大规模 Linux 主机补丁升级、批量重启之前，通常是怎么处理 /etc/fstab 风险检查的？
感觉单纯做语法检查还不够，但真正执行挂载又风险比较大，所以想看看有没有比较成熟的 pre-reboot check 思路。
感谢。
1
Select Language