我在服务器上恢复 SELinux 时遇到了问题，希望得到一些帮助。
语境
在我们的服务器上，我最近将 SELinux 从 更改enforcing为permissive，但由于它没有解决我们的一个奇怪问题（意外的权限被拒绝），我甚至将其设置为disabled... 无论如何，SELinux 不是问题所在。我们弄清楚了，现在它已经解决了 ... 但 SELinux 现已被禁用！
现在我想恢复它。所以我只是将它再次更改为，并希望系统在下次启动时enforcing自动检测到它需要重新标记（因此不需要），touch /.autorelabel过去有效的（tm）。遗憾的是它在启动时卡住了，10 分钟后我们又回到禁用状态以恢复服务。文档指出这可能需要很长时间，所以我安排在周末重启。但周末过后它仍然卡在启动状态。
奇怪的是，服务器的硬盘没有显示任何磁盘活动。
当我在虚拟机上执行上述操作时，它会启动到同一点，然后打印一条消息，提示需要执行 SELinux 重新标记并执行该操作。在服务器上，我们看不到该消息。
评论
服务器有一些 CIFS 安装，这是 SELinux 尝试重新标记 CIFS 文件系统的原因吗？这可以解释较长的时间和没有磁盘活动，但不能解释控制台上没有消息的原因。
技术信息
- CentOS 7.6 (1810) x86_64
- 裸机，戴尔服务器，6 个 HDD RAID6（硬件）
- 没有日志写入磁盘，最后启动的单元是
Update UTMP about System Boot/Shutdown.
注意：RHEL 知识库文章建议首先从禁用状态转为通过宽容状态强制执行。每次重新启动时，通过触摸 强制重新标记/.autorelabel。这将是我周末的下一次尝试。但任何有关发生的事情的见解都欢迎。
更新 01
我现在已经做了进一步的测试。以下所有启动模式均失败：
- 启动
selinux=1, enforcing=0, autorelabel=0 - 启动
selinux=1, enforcing=0, autorelabel=1 - 启动
selinux=1, enforcing=1, autorelabel=0 - 启动
selinux=1, enforcing=1, autorelabel=1
只有使用 启动才selinux=0有效。我所说的失败，是指启动时控制台上没有错误消息，也没有关于 SELinux 重新标记的消息，系统挂起数小时，看不到磁盘活动。
我现在已经注释掉了cifs我的所有卷/etc/fstab，并在宽容模式下重新启动，并启用了自动重新标记。启动大约需要 20 分钟，但我可以看到它在做一些事情（控制台上打印出已开始重新标记，显示 FS（如 sysfs）是只读的并且被忽略，磁盘活动可见，等等）。因此，SELinux 现在已在宽容模式下启用。我现在将在本周末尝试强制模式。
显然，那些 CIFS 挂载似乎是问题所在，但我不明白为什么。在我看来，CIFS 挂载会被重新标记忽略，就像 sysfs 一样。我在这里误解了什么吗？
答案1
有什么特定的原因要使用吗/.autorelabel？我的理解是它会触发restorecon。
要弄清楚为什么会挂起，我建议切换到宽容模式，并在没有/.autorelabel文件的情况下启动机器。当系统启动并运行时，尝试restorecon -rFv /。最终不要从开始/，而是从例如/var或整个系统的一小部分开始。
restorecon 的标志-v显示了文件系统上正在进行的所有修改。它应该能让你很好地了解在启动过程中它会在哪里“挂起” /.autorelabel。我预计文件系统中会有一些区域存储大量小文件。或者最终是网络安装的存储。
一旦完成切换，enforcing就不需要再/.autorelabel运行了。
[编辑]
我刚刚在 Fedora 29 机器上验证了上述关于/.autorelabel和的陈述。启动，这是一个 bash 脚本。该脚本使用参数运行。 是另一个实际运行 的 bash 脚本。restorecon/lib/systemd/system/selinux-autorelabel.service/usr/libexec/selinux/selinux-autorelabel/sbin/fixfilesrestore/sbin/fixfilesrestorecon