ハードリセット後、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を再構築します。 Boot、proc、sys、dev、chroot、sudo dracut は /mnt にインストールされます。
アドバイスに従ってください：
実行し
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:s0RAMが正常に動作していることがわかりました。 memtest86は3.5回のパスと8時間以上のテスト時間でバグを見つけられませんでした。
9. SELinuxを無効にし（/etc/selinux/configでSELinux = disabled）、再起動します。システムはエラーなしで起動します！これは問題が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時間稼働します。時々（数週間に1回程度）完全に凍結することもあります。 HDDが書き続けています（繰り返し聞こえますが、音は不規則です）。キーボード、マウス、またはリモートSSHアクセスに応答しません。一晩中何度も試してみましたが、回復しなかったので、これが起こるたびに強制的にリセットする必要がありました。今回は待たずに数分後にハードリセットしました。残念ながら、それ以降は始まっていません。
システムが停止する約1分前に、特定のスクリプトが応答しないというFirefoxメッセージボックスが表示されたことを覚えています。私の選択は覚えていません（殺してください/待ってください）。
ハードウェア：Hitachi HTS725032A9A364 2.5インチHDDおよび4GB LPDDR3 RAM（基本時計）を搭載したGigabyte GB-BACE-3160 Brix PC。
詳しくは[ここ]
答え1
起動プロセス中にrootfs、ホーム、メッセージキュー、およびカーネルファイルシステムのマウント権限が拒否される原因は何ですか？
[...]
これらすべての場合
Failed at step EXEC spawning /usr/bin/mount: Permission denied理由として提示されます。どうやって？独自のファイルシステムを認識しませんか？
これらのファイルシステムをマウントできない理由は、実際には、mount権限拒否エラーのためプログラムを実行できないためです。あなたが見つけたログメッセージは次のとおりです。mount自分で実行すると、同じエラーが表示されることが予想されます。
ディスクのシステム損傷に非常に似ています。
一般的に言えば、停止したシステムは満足できません。これは完全に予期しない結果ではありません。ハードウェアの問題、カーネルのバグ、またはカーネルが現在の解決策を知らないハードウェアのバグがある可能性があります。
RAMに欠陥があると、奇妙なことが起こり、交換コストが比較的安価であるため、一度見てみる価値があります。たとえば、RAMをテストするために使用できますmemtest86+。ご提案いただいた@thecarpyに感謝します。
Linuxでいくつかの新しく広く使用されているハードウェアの処理に問題がある場合は、他の人が最新バージョンのLinuxで問題を解決した可能性があります。ハードウェアがしばらく使用されている場合、または他のLinuxユーザーが使用していない場合は、修正するのが難しい場合があります。
私もこのようなシステムを使ったことがあり、同様の問題の影響を受けました。これ- これは非常に低い電力のIntel CPUで発生する問題のようです。[1][2]- Celeron J3160のようなJシリーズがもう少し強力だと思うので、同じ問題かどうかはわかりません。
しかし、これを完全に無視して、このような「不可能な」メッセージの直接的な原因が何であるかを知る方法が気になったら、私が提案できる2つの異なる技術があります。 （その後、すでに使用している技術の1つを選択するか、少なくとも私たちに説明する方法を選択してください。）
rpm -V "$(rpm -q --whatprovides /usr/bin/mount)"元のパッケージチェックサムを確認するためにより一般的に使用できますrpm -V --all。出力に「c」を含む行は通常無視する必要があります。これらの行は、変更が許可されている構成ファイルを表すためです。 --all を使用すると、これらの項目の多くを見ることができます。また、「g」という行は無視してください。これは、いくつかのログファイルを含むファイルを動的に「作成」することを意味します。したがって、を使用することをお勧めします。最初からパッケージを確認するrpm -V --all | grep -v " [cg] "最初の方法を試してみることをお勧めします。mounthttp://ftp.rpm.org/max-rpm/s1-rpm-verify-output.html- Fedoraを使用していることを考慮すると、2番目に確認する必要がある「権限の拒否」の状況はSELinux属性の破損です。
fixfilesたとえば、このプログラムはfixfiles check。 Fedora開発者でさえ実際にSELinuxを正しく使用する方法がわからないので、これは驚くほど関連性のない出力を提供する可能性があります。私はこのコマンドに関する有用なアドバイスを見つけるのが難しいと思います。fixfiles check /usrこれは、少なくとも/usr/bin/mountで発生する特定のエラーに対処しながら、より広範な損傷を見つけ、最も騒々しい誤りを防ぐことができることを願っています。
これまで私は以下を持っています：
- SMARTによって報告されたディスクの状態を確認し、短期および長期テストを実行します。ディスクは完全に健康です。
はい、SMARTの健康をテストすることは常に良いです。ディスクの破損が疑われる場合は、これらのテストのいずれかを実行することをお勧めします（Longが最善だと思います）。
- fsck を使用してファイルシステムの整合性を確認します。すべてのパーティションがきれいです。
良いアイデアですが、1つの問題があります。ハードウェア障害が発生した場合にファイルシステムの整合性を確認したことを指定するには、実行したことを指定する必要がありますfsck -f。
（ジャーナルファイルシステム（ext4など）の「ダーティ」状態がクリアされたfsckか、カーネルが単にログを再生した可能性があります。この場合なしfsckで実行すると、追加の-f操作なしでファイルシステムが「クリーン」とマークされたことが報告されます。 )
また、ext4をルートファイルシステムとして使用していることを指定する必要があります（この場合を前提として）。 btrfsまたはXFSを使用している場合、既存のコマンドではfsck何も実行できません。
（この場合、ファイルシステム固有のコマンドがより役立つかもしれないし、そうではないかもしれません。デフォルトでは、ext2ファイルシステムファミリは、元のロギングよりも前に完全な整合性チェックファイルシステムをfsck実行できるように設計されたシステムが開発されました。さまざまな歴史があります。
btrfsとZFSは、独自にエラーを検出するように設計された「チェックサムファイルシステム」です。この時点で、「クリーンアップ」の実行を検討するのは合理的です。その後、その時点で生成されたチェックサムと比較して、ファイルシステムに書き込まれたデータを明示的に確認します。 （パフォーマンス上の理由から除外された特定の種類のファイルはここには含まれません。）
たとえば、ディスクへの転送中にデータが破損した場合、Cleanはこれを検出しますが、SMARTテストは検出しません。 )
答え2
問題は、ファイルの不正なファイルコンテキストが原因で発生します/usr/bin/mount。samba_share_t
ファイルコンテキストの変更は、ハードリセットによるいくつかのバグによるものではなく、SELinux警告ブラウザの最初の提案に従うことによる不注意な決定によるものです。以下のスクリーンショットをご覧ください。
最初の提案は、smbdがgetattrにアクセスできるように/usr/bin/mountファイルコンテキストを変更することです。samba_share_t
解決策は次のとおりです。
- 無効なファイルコンテキストを削除するには、デフォルト値を復元してファイルラベルを再指定してください。
[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警告ブラウザの最初の提案に誤って従ったことに気づきました。システムを修復して再起動した後も同じアドバイスが表示されますので、以下のスクリーンショットを添付します。
SELinuxが問題の原因である可能性があることを指摘し、助けてくれた@sourcejediに感謝します！