对于工作中使用服务器的公司来讲，每到节假日来临时，总免不了对服务器进行下电。而收假回来的早上，则会有一个早上的时间会花费在服务区的开机和修复工作上。是的，修复无法开启或开机失败的服务器。

几乎每次节假日售价回来，恢复服务器的正常工作状态都是一件不得不做的事情。或者开机进入紧急模式，或者因为服务启动失败等等原因，总有一些服务器无法正常启动。而通常，启动时看到的都是如Welcome to mergency mode。

emergency_mode.png

紧急模式下，网络等服务均没有开启，SSH无法连接到终端，大部分的工作都不可用。但是紧急模式下，可以通过journalctl -xe来查看系统启动过程中的日志。

#journalctl -xe
...
May 6 09:46:13 server systemd[1]: data.mount mount process exited, code=exited status=32
May 6 09:46:13 server systemd[1]: Failed to mount /data.
Subject: Unit data.mount has failed
Defined-By: sustend
Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Unit data. mount has failed.
The result is failed.
May 6 09:46:13 server systemd11: Dependency failed for Local File Systems.
Subject: Unit local-fs.target has failed
Defined-By: sustend
Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Unit local-fs.target has failed.
The result is dependencu.
May 6 09:46:13 server systemd[1]: Dependency failed for Migrate local SELinux policy changes from the old store structure to tr
Subject: Unit selinux-policy-migrate-local-changes@targeted.service has failed
Defined-By: sustend
Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Unit selinux-policy-migrate-local-changes@targeted.service has failed.
The result is dependency.
May 6 09:46:13 server systemd[1]: Job selinux-policy-migrate-local-changes@targeted.service/start

根据日志中的报错信息，很容易可以得出系统在启动时需要挂载/data目录，但是失败了。从而导致操作系统进入紧急模式。

而对于大多数人的使用习惯来说，需要使用到开机挂载的文件系统目录都是写入/etc/fstab中的。

/etc/fstab 的使用

众所周知，/etc/fstab文件用来保存操作系统中的挂载目录信息，是一个静态文件。并且操作系统开机时默认也会加载/etc/fstab中的文件系统目录。

默认的/etc/fstab分区表中写入了boot和root分区的信息，以便于操作系统开机后可以挂载相应的两个文件系统目录。

#cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu May  5 09:54:17 2022
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/rhel-root /                       xfs     defaults        0 0
UUID=6bd8018f-79db-421a-a0a4-29693822ea8c /boot                   xfs     defaults        0 0

但是一旦尝试向分区表中写入其他的一些文件系统目录后，操作系统进行了重启，则极有可能会导致系统开机进入紧急模式。

正如上面的事件，就是一次因为开机加载/etc/fstab分区表中的文件系统目录失败而导致操作系统进入紧急模式的。那么，如何正确的使用/etc/fstab就成为一个值得考虑的问题了。

在考虑这个问题前，还是先回到我们最初的目的上。目的是什么？

我们需要的是一个可以在操作系统开机后自动挂载我们所需要使用到的目录，而不需要每次开机后手动挂载。如果需要每次操作系统开机后手动mount一次或多次，费时费力不说，更有可能影响应用的使用，所以，手动mount并不是一个解决方案。

既然是开机后进行自动挂载，那么通过Linux操作系统的开机启动任务 + mount自然也是可以实现相同的目的。

仅仅需要将在操作系统上已经挂载的文件系统目录，以命令的形式写入到/etc/rc.d/rc.local文件中。

#cat /etc/rc.d/rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

# auto mount /data dir
mount -t xfs -o rw,noatime /dev/vdb /data

/etc/fstab开机挂载失败的原因探索

在很多情况下，通过向/etc/fstab分区表中写入文件系统目录的愿景是美好的，我们期望可以通过fstab能够将操作系统上的文件系统分区信息进行管理，以满足生产与应用的需要。

但经过多次的实践证明，随意向分区表中写入文件系统分区信息并不总是好的。因为，一旦分区表中的目录在开机过程中没有被成功加载，系统则必定会进入紧急模式。

那么，造成分区表加载分区信息失败的原因会是什么？

操作系统在开机前会进行硬件扫描，主要扫描的设备包含CPU、内存、启动(引导)盘等，而操作系统的主分区(\、boot、root)通常都是建立在启动盘之上。经过了硬件开机自检，启动盘确认正常后，也即是说，建立在启动盘上的文件系统目录(例如, root、boot)都是可以被正常挂载的。

倘若你在系统启动盘下新建了/opt、/usr、/tmp等目录，开机时也是可以成功加载文件系统目录。而我们所说的失败，则更多的原来于非操作系统启动盘以外的硬件磁盘(块设备)。

简单点说，操作系统的启动盘在操作系统上的展现形式可能是/dev/vda - /、而当你在操作系统的分区表中写入/dev/vdb - /data的分区信息，并期望开机后能够自动加载/data目录，那么可能会导致加载分区表失败。

以下三个原因仅为个人推想,可能与实际原因相悖

  • 这或许是因为操作系统启动时仅仅加载了部分设备，而当需要加载分区表中的/dev/vdb设备时，该设备尚且没有被操作系统所识别到，这种情况下会导致失败。
  • 系统启动时加载分区表中的分区信息时，需要依赖对应的服务(或依赖)，而依赖尚未加载完成。
  • 对于手动挂载文件系统目录后，挂载目录时使用了/dev/vdb格式的分区，因为某些原因(异常掉电、拔插硬盘)导致的系统识别到的分区名称发生变化(例如，从/dev/vdb变为/dev/vdd)，而写入到分区表中的配置没有发生变化，重新加载分区表信息的时候会导致失败。

总而言之，向/etc/fstab中写入除系统启动盘之外的硬件设备可能并不是一个好的主意。如果你需要在开机后自动挂载某个文件系统目录，那么我更推荐你使用/etc/rc.d/rc.local + mount来实现自动挂载目录。