求助：有没有无影响检查 /etc/fstab 的可靠方法？

oferge0311 2026-08-26 14:32 1

最近在做一批 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 思路。

感谢。

最新回复 (58)

cslive 08-26 14:47

1楼

命令写在/etc/rc.local 里
oferge0311 楼主 08-26 15:01

2楼

@cslive 是重启前的检查，避免出现因为 fstab 文件而重启失败，进行规避。写在自启文件里面的化，没这个而此操作的必要性吧？ fstab 本身就会在启动时会操作一遍的阿
cslive 08-26 15:07

3楼

@oferge0311 #2 不要动 fstab 文件，"mount /dev/sdb /mnt"写在/etc/rc.local 里即可，你动 fstab 拼错了或者 nfs 挂载不上卡住了启动不起来进救援模式改文件很麻烦，写在/etc/rc.local 不会影响启动，最多目录挂不上去
oferge0311 楼主 08-26 15:13

4楼

@cslive 最多目录挂不上。。。。。如果是数据盘呢，如果是 nfs 共享存储呢。。。大批量主机，你这个方法能正常拉起系统吗，要做到的是减少工作量，但后续的检查工作不比 1 台机器起不来修的工作量要小阿，难道还要在重启之后执行一遍 mount -a 吗
Kirkcong 08-26 15:16

5楼

我们的方案是，分批重启，一天重启个五六台
kenX 08-26 15:17

6楼

需求都这么明确了，丢给 ai 出个脚本不行了？
oferge0311 楼主 08-26 15:19

7楼

@kenX 用 ai 跑了脚本了，但是主机批量蛮大的，预计的情况也不一定，我不太想使用。出问题肯定算。。。
oferge0311 楼主 08-26 15:20

8楼

@Kirkcong 五六台。。。。我们的机器还是蛮多的，测试灾备的主机环境是这个的千倍多，生产比测试灾备的要多几倍
cslive 08-26 15:21

9楼

@oferge0311 #4 我已经说的很清楚了，这种方法能保证重启，挂不上去那肯定你命令有问题，盘有问题，nfs 网络问题，这些是你要想办法解决的
Kirkcong 08-26 15:23

10楼

@oferge0311 所以这是个长期计划，半年一年差不多了
oferge0311 楼主 08-26 15:24

11楼

@cslive 要做到的是重启前的检查呀，fstab 文件拿最简单的，defaults 没有 s 都会起不来进入救援。
Kirkcong 08-26 15:26

12楼

@oferge0311 你们可以多分几个人，每天多重启几台。如果你说生产机器也面临这个问题，那我只能说架构整体太脆弱了，怎么会允许这种事情呢？如果是前人留下的，那就看愿意花多少成本去填坑了。
dream10201 08-26 15:28

13楼

改成开机不自动挂载，访问挂载目录才自动挂载，这样就不会影响到开机。
oferge0311 楼主 08-26 15:28

14楼

@Kirkcong Linux 这个开源项目，内核漏洞不断的被发现，厂商不断的发布补丁，不断的打，太多了，压根属于上上上一个还没打完，又来新的，只能是可着优先级高的业务系统进行操作了。而且我也不想去管这个，不是该操的心，只想看看能不能学到一种方法，丰富自己的同时还能减轻工作，毕竟每次遇到机器起不来修也很麻烦，走各种流程
oferge0311 楼主 08-26 15:30

15楼

@Kirkcong 生产环境已经算好了的，问题少的，顶多遇到个 fstab 和网络网卡问题，其他都是配合应用解决它们的服务，测试和灾备环境才是真正属于，运行时候就是个雷，重启才发现。几台可不止，测试灾备最多一晚上 1000 台，生产目前最多是 600 多，几乎都是一个业务的。
Kirkcong 08-26 15:37

16楼

@oferge0311 没办法，只能不断的打补丁。你这个场景里面最大的问题不在于怎么做到 runtime to permanent.而是说架构本身没设计好，比如我们的机器，不管是 dsr 还是 psr,所有机器都统一配置，需要持久化的东西都在 ansible playbook ，即便没有挂载上的，直接跑 mount -a 即可。甚至每个机器安装的 rpm 、pip modules 都是一样的，全都由 ansible role 管理，而 ansible 文件则放在 bitbucket 中。

如果你不是管事的，那就直接把这问题报告上去，说清楚现状，以及风险点。怎么决策是上面的事情。你千万不要去做任何冒险的事情，因为一旦出了事，都是你的；如果弄好了，没什么收益，并且出事的概率极大。
oferge0311 楼主 08-26 15:41

17楼

@Kirkcong 明白您的意思，但根据这一季度做的这几万台，能正常拉起系统的，一般都甩不到我们身上。我也不去做这个问题报告，和+1 领导说一下这个问题，+1 领导是技术的，如果是他提供的脚本，肯定是比我从 ai 跑出来的脚本，从”安全与执行“要强的。我们也是用 ansible 操作，机器太多，后续要替换其他的了。我们有个镜像仓库，补丁包打到里面，yum update 去指定对应的仓库名称的特定包，都是写好的 yaml [都是+1 写的]
june4 08-26 15:44

18楼

都要重启了为什么不能变化下系统状态呢？重启了不是又重置了。如果 mount -a 出问题，那就先别重启，通知人修复机器问题再重启，否则不是明知故意个留个雷在这机器吗反正也是要解决这个问题的
oferge0311 楼主 08-26 15:45

19楼

@Kirkcong 目前就是重启前升级失败的问题，这种一般都是跑 playbook 时的 python 被应用改了，或者 rpm 需要 rebuilddb 重构一下，或者也就是存储满了，升级不了。现在就是有点钻牛角，想要简单且不那么冗余的预防这个重启后系统失败拉起的点。前面 6 楼老师说的直接跑 ai 脚本出来也行。我在试 13 楼老师的取消开启不自动挂载方案在我的本地机，但这种应该不适合在大批量生产环境。有种不如不做，做了反而怪你。
oferge0311 楼主 08-26 15:47

20楼

@june4 我有考虑过如果先执行 mount -a 是不是万事大吉，但生产环境的 mount -a 如果出现挂载点重复等操作，也不是不可能存在的，如果覆盖挂载，比重启起不来去修还要麻烦。
oferge0311 楼主 08-26 15:48

21楼

@dream10201 您的想法是好的，但我想了想，在自测机可以这样试一下，但我所描述的背景环境，不太适合这种方式，不如不做，做反倒都是你的错了。我只是想多学到一种方式方法。哈哈，谢谢！
Kirkcong 08-26 15:50

22楼

@oferge0311 别做，只用上面给的脚本，上面给你什么你就用什么，让你怎么做就怎么做。你们机器体量大，架构零散，极大概率出事，我说的是指，在所有人意想不到的东西上出问题，起因可能是你导致的，也可能不是，但你会非常焦虑，别人也会首先怀疑近期谁做了变更。

实验新东西不能在这种大型变更上尝试，太危险了。
oferge0311 楼主 08-26 15:52

23楼

@Kirkcong 是的，规避这种不必要的风险，就像是您说的，一旦出了事，都是我的；如果弄好了，没什么收益，并且出事的概率是不确定性的。所以我在几个社区发布了帖子，希望是讨论一下，如果是有效的方法，我也仅做个学习记录。
unused 08-26 15:53

24楼

建个 mnt namespace 在里面挂载
Moishine 08-26 16:22

25楼

好久没在本站看到技术讨论了😄
zhsj 08-26 16:42

26楼

没见过有实现好的，感觉只能具体场景具体检查。

fstab 应该是 ansible 脚本直接生成的，这样至少保证 fstab 和你配置仓库里的一致。比如 uuid ，直接 ansible 获取过来的吧。nfs 地址，肯定是你配置文件里写死的，这样和你配置仓库里每个机器的网络结构也能对应起来。
oferge0311 楼主 08-26 16:43

27楼

@unused 没太明白您的意思，方便稍微的说一下吗，我在自测机试一下，工作环境就不去做这个实验了
zhsj 08-26 16:46

28楼

思路可以转换下，不是说检查生产环境 fstab 是不是有问题（不要让人去生产环境直接做变更），而是这个 fstab 是配置仓库生成的，确保可控。
adoal 08-26 16:54

29楼

感觉 [因为 mount -a 可能会把当前未挂载的文件系统真正挂载起来，也可能主动访问 NFS 、NAS 等网络存储，甚至改变当前系统状态。在复杂生产环境中，这种操作有可能产生额外影响，极端情况下甚至可能出现不可逆的问题] 这个现状的复杂性才是你问题的根因。可能还是得想办法把这种挂载操作的不可控给解耦隔离到一个较小的范围更合理吧。
unused 08-26 17:13

30楼

@oferge0311 没有具体测试过，不知道 `unshare --mount` 后 `mount -a` 能不能满足你的需求。这样会实际挂载文件系统，但是没有特殊情况的话这些挂载和原 namespace 是隔离的。`man 7 mount_namespaces` 看一下
huhy 08-26 17:26

31楼

可以先找台同环境的服务器测试机，在上边测试完漏洞修复后再去到生产环境进行操作。
Dlin 08-26 17:44

32楼

干什么的，你们机器咋这么多。
oferge0311 楼主 08-26 19:55

33楼

@adoal 问题的关键确实就是这样的，不能执行 mount -a 就是因为在复杂的生产环境中反倒会有额外的影响，甚至不如选择机器起不来去修复。
oferge0311 楼主 08-26 19:56

34楼

@huhy 复杂的生产环境，没办法做到找相同环境的测试机去做测试的，我只是想预防一下因为 fstab 而导致的系统启动失败进入救援模式修复
oferge0311 楼主 08-26 19:57

35楼

@Dlin 这个。。。机器确实很多
oferge0311 楼主 08-26 20:00

36楼

@zhsj 不是，和 29 楼的 adoal 老师说的一样，复杂的生产环境，每个主机的 fstab 不一定是什么样子的，目前我遇到因为 fstab 问题起不来的有。1.没有对应的 lv 和挂载点 [创建的时候就创建错了，2 年未重启过，没发现过] 2.lv 写错，导致未成功挂载 [也是一年多未重启过，从未被发现] 3.defaults 的参数少写了个 s.只有 default [这个当时光顾着拉起系统，没看上次修改是什么时间，估计也是几年]
ota 08-26 20:32

37楼

有感，之前也是，我有一部分用了 sshfs ，有部分用了 nfsv4 ，挂载出现问题导致一些服务直接宕机，深有体会。还好我机器不多，我直接全部改成 nixos 跑了，尽可能环境可回滚可复现。统一管理同一份配置文档。
zhsj 08-26 21:08

38楼

你这几年没重启的机器没救了，一看就不像现代工具管理的，自己一个个检查吧
fstab 08-26 21:38

39楼

[Unit]
Description=Mount Disk with UUID
After=local-fs.target

[Mount]
What=/dev/disk/by-uuid/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Where=/home
Type=ext4
Options=defaults,nofail

[Install]
WantedBy=multi-user.target

我是写到 systemd 挂载单元，放到/etc/systemd/system 里面的，开机挂载，就算硬盘坏了，也不影响启动。
fstab 08-26 21:39

40楼

打开论坛一看 fstab ，我还想着谁挂我呢- -
oferge0311 楼主 08-26 21:51

41楼

@zhsj 这个。。。这个。。。。机器太多太多了，几年两三年没重启的不算什么。。。。至于现代化工具，不太清楚什么算现代化工具阿。。。复杂的生产环境，成千台连测试机都不满足
oferge0311 楼主 08-26 21:52

42楼

@ota 复杂的生产环境，当我统计数量，顺带统计了一下业务，业务都几百+，应该没办法统一的去管理同一份配置文档，一个业务一个挂载点都是有可能存在的/(ㄒoㄒ)/~~
oferge0311 楼主 08-26 21:53

43楼

@fstab O(∩_∩)O 求助如何挂你，哈哈
oferge0311 楼主 08-26 21:56

44楼

@fstab 以 system 去管理吗，那是不是要和前面第 13 楼的 dream10201 老师说的方法有点类似，需要先取消 fstab 的开机不自动挂载，然后再以 system 服务去管理磁盘挂载，这好像是个好方法诶，值得学习记录一下，不错，谢谢老师，不过在我这个复杂的生产环境，可能没办法实现，不过是个好方法。我上一次去学习 systme 还是以普通用户去绕过 root 用户，完全实现--user 用户级的开机自启
ihciah 08-26 22:41

45楼

用 nixos 管理，拿一台机器做实验，挂了也能回到上一个 generation 。验证通过后全量发。
ihciah 08-26 22:44

46楼

哦不对，你这里是想验证各种不同的 fstab 。。
那看起来你只能尽可能 dry run fstab 同款逻辑了，然后写脚本兜底，启动挂了 revert 。
oferge0311 楼主 08-26 22:46

47楼

@ihciah 如标题，我是想使用一种方法来尝试检查不同的 fstab [该死的生产环境] ，目前看只能跑脚本了。
j0ck1e 08-26 22:56

48楼

"mount -a 可能会把当前未挂载的文件系统真正挂载起来",生产环境就不该出现这种问题，长期挂载的设备才应该写在 fstab 里面，实际 fstab 和 mount 必须对得上，不要考虑什么 rc.local ，systemd ，虽说 systemd 也是官方建议，但写起来实在费劲，通用便捷性还是不如 fstab ，如果你只是担心 fstab 写错导致重启进入紧急救援模式，不妨在不确定的条目中加上 nofail 参数
busier 08-27 00:19

49楼

杀个乱写 fstab 的程序员祭天
laminux29 08-27 06:52

50楼

思路完全错了，你这是在生产环境上做测试。

正确的思路是，在测试环境上，把改动做好，形成不可变系统。正式环境上只做监控，不做测试。
Rorysky 08-27 09:31

51楼

nofail
salmon5 08-27 09:47

52楼

nofail #nfs 不需要添加，nfs 无法挂载也不影响启动；
#本地盘如果不存在，系统无法启动，可以添加/dev/vdd /mnt/vdd ext4 defaults,nofail 0 0 ，镜像了 ECS 不带数据盘，也不影响启动
man systemd.mount 查看 nofail 帮助；属于 systemd ，不属于 nfs ；因此只能/etc/fstab 中使用，无法在 mount 命令中使用
salmon5 08-27 09:49

53楼

重启不检查，新配置的时候检查，不要头疼医头
yanqiyu 08-27 09:57

54楼

> UUID 或设备路径错误文件系统类型错误挂载参数不支持本地设备不存在 NFS 等网络文件系统不可达其他只有实际挂载时才会暴露的问题

那现在这个机器是怎么拉起来的？按理说只要现在机器还在运行出问题的最多就是 nfs ？
Busy 08-27 10:25

55楼

生产环境做测试是为了什么，服务器可能被交接过 N 次，非重大问题，是不重启的。
内核级补丁，那就不要将挂载写到 fstab 。
各个服务通知到责任人，重启后通知他们解决。
你怎么可能清楚知晓他们是如果对待挂载目录的。
killva4624 08-27 10:27

56楼

生产环境不能进行测试，只能从配置文件静态分析是否有错误。
既然无法用一个方式来一把验证，那你的问题应该分阶段去看，或者说，先解决能解决的部分，小规模验证、优化，再大规模推广。
然后是增量问题：规范 fstab 配置文件写入，新增机器统一要走标准的处理方式，比如出现人工手写或者注释不全等不规范问题...如果业务不规范，那么你做为机器管理方，要提出自己的声音，进行业务规范。

然后是存量问题：存量 fstab 配置文件，是否静态分析（语法、磁盘是否存在、权限设置）就已经能解决大部分错误了，如果是，那就没有必要纠结，先全量扫描修复一遍；然后小规模（比如 5%）重启，看是否有新的 case ，新的 case 能否用别的方法，加到扫描脚本里处理，依次类推。
coefu 08-27 10:44

57楼

一个 mount -f 的事情，搞那么多心理活动，你难道不看 man 手册？

mount from util-linux 2.37.4 (libmount 2.37.4: selinux, btrfs, namespaces, assert, debug)

唯一要验证的就是，你那些七里八里的机器 os 的 mount 支不支持 -f 。
coefu 08-27 10:44

58楼

@coefu 撤回，是我没仔细看 op 原帖。