我的 Fedora 27 x64 在硬重置后无法启动。表明：
Failed to mount POSIX Message Queue File System,
Failed to start Remount and Kernel File Systems,
Failed to mount Kernel Debug File System,
Failed to mount Huge Pages File System [3]
在这些失败之后还有许多其他的失败。看https://photos.app.goo.gl/qBUxT40zA2MTLTwO2
在所有这些情况下
Failed at step EXEC spawning /usr/bin/mount: Permission denied
被给出作为一个理由。怎么会这样？它不能识别自己的文件系统吗？
我有 3 个内核：
vmlinuz-4.14.16-300.fc27.x86_64
vmlinuz-4.15.13-300.fc27.x86_64
vmlinuz-4.15.14-300.fc27.x86_64
无论我尝试启动哪一个，都会发生同样的情况。
到目前为止我有：
- 使用 fsck 检查文件系统完整性。所有分区都是干净的。
- 检查 SMART 报告的磁盘运行状况并执行短期和长期测试。磁盘完全健康。
- 重建 initramfs。在 /mnt 中安装了 boot、proc、sys、dev，chroot 和 sudo dracut。
遵循建议并：
执行
fsck -f on /dev/mapper/fedora-home，得到：tree extents for i-node 524820 (on level 2) could be narrower. Fix?<y>Y
允许修复此问题。
对于 /dev/mapper/fedora-root 来说也是如此，/dev/sda1（启动分区）确认它们是干净的。对于数据文件的额外分区，又发现了一个相同类型的错误。
rpm -V --all | grep -v " [cg] "返回如下：
.M....... /run/libgpod
..5....T. /var/lib/selinux/targeted/active/commit_num
.......T. /var/lib/selinux/targeted/active/file_contexts
.......T. /var/lib/selinux/targeted/active/homedir_template
S.5....T. /var/lib/selinux/targeted/active/policy.kern
.M.....T. /var/lib/selinux/targeted/active/seusers
.M.....T. /var/lib/selinux/targeted/active/users_extra
.M....... /var/run/pluto
not exists /var/run/abrt
.M....... /var/log/audit
not exists /usr/lib/systemd/system-preset/85-display-manager.preset
S.5....T. /usr/share/icons/Crux/icon-theme.cache
S.5....T. /usr/share/icons/Mist/icon-theme.cacherpm -V "$(rpm -q --whatprovides /usr/bin/mount)" .M....G.. g /var/log/lastlogfixfiles check /usrlibsemanage.semanage_make_sandbox: Error removing old sandbox directory /var/lib/selinux/targeted/tmp. (Read only file system). genhomedircon: Could not begin transaction: Read only file system
在许多类似于下面这一行的行中：
Would relabel /usr/src/handbrake/trunk/build/contrib/lib from unconfined_u:object_r:usr_t:s0 to unconfined_u:object_r:lib_t:s0Would relabel /usr/sbin/mount.nilfs2 from unconfined_u:object_r:bin_t:s0 to unconfined_u:object_r:mount_exec_t:s0
Would relabel /usr/sbin/umount.nilfs2 from unconfined_u:object_r:bin_t:s0 to unconfined_u:object_r:mount_exec_t:s0
Would relabel /usr/sbin/mkfs.nilfs2 from unconfined_u:object_r:bin_t:s0 to unconfined_u:object_r:fsadm_exec_t:s0事实证明 RAM 工作正常 - memtest86 在 3.5 次通过和超过 8 小时的测试时间内没有发现任何错误。
9. 禁用 SELinux（SELinux=在 /etc/selinux/config 中禁用）并重新启动。系统启动没有任何错误！这证明问题出在 SELinux 策略上。我相信我应该首先检查那些已以某种方式更改的 6 个顶级 SELinux 策略（参见第 5 页）。问题是如何明智地做到这一点。
检查对 SELinux 配置文件和 file_contexts 的本地修改：
semanage module -C -l Module name Priority Language semanage fcontext -C -l fcontext SELinux type Context /usr/bin/mount all files system_u:object_r:samba_share_t:s0 /usr/share/dnfdaemon/dnfdaemon-system all files system_u:object_r:rpm_exec_t:s0 /var/run/media/przemek/extra(/.*)? all files system_u:object_r:samba_share_t:s0 /var/www/html/photo all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/_cache all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/config all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/content all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/content/folders.json all files system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/photo/iv-config/language all files system_u:object_r:httpd_sys_rw_content_t:s0
有趣的是 /usr/bin/mount 的 fcontext 已经改变。
该系统作为简单的家庭服务器（www、邮件等）每天 24 小时运行。有时（比如几周一次）它会完全冻结。 HDD 不断写入内容（重复，但声音不规则）。对键盘、鼠标、远程 SSH 访问没有反应。很多次我尝试将其放置过夜，但它无法恢复，因此每次发生这种情况时我都被迫对其进行硬重置。这次我没有等待，而是在几分钟后硬重置了它。不幸的是从那时起它就无法启动了。
我记得在系统冻结前一分钟左右，Firefox 消息框出现告诉我某些脚本变得无响应。我不记得我的选择（杀死它/等待）。
硬件：配备 Hitachi HTS725032A9A364 2.5" HDD 和 4GB LPDDR3 RAM（默认时钟）的 Gigabyte GB-BACE-3160 Brix PC。
更多细节[这里]
答案1
是什么导致在启动过程中挂载 rootfs、home、消息队列、内核文件系统的权限被拒绝？
[...]
在所有这些情况下
Failed at step EXEC spawning /usr/bin/mount: Permission denied被给出作为一个理由。怎么会这样？它不能识别自己的文件系统吗？
它无法挂载任何这些文件系统的原因实际上是mount由于权限被拒绝错误而无法运行该程序。这就是您找到的日志消息所说的内容。我们预计，如果您尝试mount自己运行，您会看到相同的错误......
听起来很像磁盘上的系统已损坏。
一般来说，冻结的系统不会高兴，这并不是一个完全出乎意料的结果。您的硬件可能存在问题、内核错误或内核当前不知道如何解决的硬件错误。
有故障的 RAM 可能会导致奇怪的事情，而且更换起来相对便宜，所以绝对值得一看。您可以使用egmemtest86+来测试RAM。感谢@thecarpy 的建议。
如果 Linux 在处理某些新的但在其他方面很流行的硬件时遇到问题，其他人可能会在较新版本的 Linux 中解决该问题。如果硬件已经存在了一段时间，或者其他 Linux 用户不使用它，则可能很难修复。
我自己使用过一个这样的系统，受到类似问题的影响这个- 这似乎是功耗非常低的 Intel CPU 的一个问题[1][2]- 我认为像您的 Celeron J3160 这样的 J 系列功率更高一些，所以我不确定是否是同样的问题。
然而，如果我们完全忽略这一点，并想知道如何查看像这样的“不可能”消息的直接原因可能是什么，我还有另外两种技巧可以建议。 （然后对您已经使用过的技术之一进行挑剔，或者至少是您向我们描述的方式）。
rpm -V "$(rpm -q --whatprovides /usr/bin/mount)"您可以使用和 更广泛地使用来验证原始包校验和rpm -V --all。在输出中，您通常应该忽略包含“ c ”的行，因为这些行代表允许更改的配置文件。当你使用 --all 时你会看到很多这些。也忽略那些写着“g”的行；这意味着动态“生成”文件，包括一些日志文件。所以你可能想使用rpm -V --all | grep -v " [cg] ".可能值得尝试第一种方法，该方法只是从mount一开始就检查包，因为这将是一个很好的快速检查。http://ftp.rpm.org/max-rpm/s1-rpm-verify-output.html- 考虑到您使用的是 Fedora，第二个要检查的“权限被拒绝”的可怕情况是 SELinux 属性的损坏。这个程序是
fixfiles.例如，fixfiles check。这也可能会提供数量惊人的无关紧要的输出，因为即使是 Fedora 开发人员实际上也不知道如何正确使用 SELinux。我觉得这个命令的有用建议更难找到。fixfiles check /usr希望至少能够涵盖 /usr/bin/mount 中出现的特定错误，同时还寻找一些更广泛的损坏，并避免最嘈杂的误报。
到目前为止我有：
- 检查 SMART 报告的磁盘运行状况并执行短期和长期测试。磁盘完全健康。
是的，测试 SMART 健康状况总是好的。如果您怀疑磁盘损坏，运行其中一个测试（我认为长是最好的）是一个很好的清单项目。
- 使用 fsck 检查文件系统完整性。所有分区都是干净的。
想法不错，但我有一个挑剔的地方。要指定您已确认文件系统完整性，当可能出现硬件故障时，您必须指定您已运行fsck -f.
（日志文件系统（例如 ext4）的“脏”状态可能已被清除，fsck或者内核只是重播日志。在这种情况下，运行fsckwithout-f只会报告文件系统已被标记为“干净”，无需进一步检查。）
另外，您应该指定您正在使用 ext4 作为根文件系统（假设是这种情况）。如果您使用 btrfs 或 XFS，传统命令不一定fsck能实现任何目标。
（在这种情况下，特定于文件系统的命令可能更有帮助……也可能没有。基本上，文件系统的 ext2 系列最初早于日志记录，因此开发了一个fsck旨在能够进行彻底的完整性检查的文件系统。其他文件系统有不同的历史。
btrfs 和 ZFS 是“校验和文件系统”，旨在自行检测错误。此时考虑运行“清理”是合理的。这将根据当时生成的校验和明确检查文件系统已写入的数据。 （这不包括出于性能原因选择退出的某些类型的文件）。
例如，如果数据在传输到磁盘的过程中被损坏，“清理”会检测到这一点，但 SMART 测试不会。）
答案2
该问题是由文件的文件上下文不正确引起的/usr/bin/mount：samba_share_t。
文件上下文更改不是由硬重置导致的某些错误引起的，而是...由于我不谨慎地决定遵循 SELinux 警报浏览器的第一个建议。请参阅下面的屏幕截图。
第一个建议是更改/usr/bin/mount文件上下文以samba_share_t允许 smbd 访问 getattr。
解决方案是：
- 要删除无效的文件上下文，恢复默认值并重新标记文件：
[root@atlas ~]# ls -Z /usr/bin/mount system_u:object_r:samba_share_t:s0 /usr/bin/mount [root@atlas ~]# semanage fcontext -d /usr/bin/mount [root@atlas ~]# restorecon -v /usr/bin/mount Relabeled /usr/bin/mount from system_u:object_r:samba_share_t:s0 to system_u:object_r:mount_exec_t:s0 [root@atlas ~]# ls -Z /usr/bin/mount system_u:object_r:mount_exec_t:s0 /usr/bin/mount - 重启系统。
这可以在紧急控制台中完成，但我已经使用控制台将 SELinux 置于宽松模式，引导系统，然后如上所述更改文件上下文。
当我检查修改后的 SELinux 文件上下文时（请参阅我的第一篇文章的第 10 页），我注意到挂载的上下文看起来很可疑。此时我意识到，在问题开始前不久，我不谨慎地遵循了 SELinux 警报浏览器的第一个建议来更改挂载文件上下文。在系统修复并重新启动后，现在出现了相同的建议，因此我可以附上下面的屏幕截图。
感谢 @sourcejedi 指出 SELinux 可能是导致问题的原因，并感谢他的帮助！