![是什么导致在启动过程中挂载 rootfs、home、消息队列、内核文件系统的权限被拒绝?](https://linux22.com/image/132707/%E6%98%AF%E4%BB%80%E4%B9%88%E5%AF%BC%E8%87%B4%E5%9C%A8%E5%90%AF%E5%8A%A8%E8%BF%87%E7%A8%8B%E4%B8%AD%E6%8C%82%E8%BD%BD%20rootfs%E3%80%81home%E3%80%81%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97%E3%80%81%E5%86%85%E6%A0%B8%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E7%9A%84%E6%9D%83%E9%99%90%E8%A2%AB%E6%8B%92%E7%BB%9D%EF%BC%9F.png)
我的 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.cache
rpm -V "$(rpm -q --whatprovides /usr/bin/mount)" .M....G.. g /var/log/lastlog
fixfiles check /usr
libsemanage.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:s0
一些有趣的是:
Would 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
或者内核只是重播日志。在这种情况下,运行fsck
without-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 可能是导致问题的原因,并感谢他的帮助!