RHES7.7を実行しているホストの1つに以下の問題があります。
cat /etc/redhat-release
Red Hat Enterprise Linux Serverバージョン7.7(Maipo)RHES7.7を実行する2つのホストがあります。そのうちの1人は再起動後にこの問題に直面しました。メッセージを送る
authorisation is not available check polkit running
これは、基本的にネットワークサービスなどが実行されていないことを意味します。したがって、コンソールを介してのみホストにアクセスできます。メンテナンスパスワードやデータなどを入力してログインできます。 systemctl restart polkitを使用してpolkitを起動しようとしましたが、上記のメッセージで失敗して再起動しました。どんな提案でも送ってくれてありがとう。
PS:これを実行すると、journalctl -u polkit
「アイテムなし」が表示されます!
ありがとう
修正する
私が受け取ったエラーは次のとおりです。
ありがとうございます。要求された出力を見つけてください。申し訳ありません。コンソールを介してのみホストにアクセスできます。
答え1
これはauthorisation is not available check polkit running
赤ニシンです。システムが緊急モードに移行し、最小限のシステムサービスしか実行されないようです。この状態では、polkit.service
不活性は正常であり、予想される。
リストされた最初のエラーメッセージはカーネルからのものです。
nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 122124
オープンソースのNVidia GPUドライバであるNouveauについて。そのドライバーやNVidia独自の(プライベートソース)ドライバーを試しましたか?コンソールにはどのグラフィックハードウェアがありますか?
このメッセージが現在の問題に関連していない可能性があります(または以下を参照)。特定のハードウェアおよび現在のドライバーのサポート状態に応じて「ノイズ」にすることもできます。
2番目のメッセージは次のものから来ますsystemd-udevd
。
Error running install command for rtl_pci
これは、モジュールがロードされるのを防ぐのと同じように自分で発生しますinstall rtl_pci /bin/false
。副作用でエラーメッセージが表示されます。/etc/modprobe.d/local-blacklist.conf
rtl_pci
エラーメッセージを削除するには、をに/bin/false
置き換えます。これにより、モジュールの取り外しがエラーではないことをシステムに通知できます。local-blacklist.conf
/bin/true
第3のメッセージは、システムが緊急モードに移行する理由であり得る。systemd
16進エスケープをデコードすると、次のように表示されます。
Timed out waiting for device dev-disk-by-label-\/apps.device.
/dev/disk/by-label/\/apps
これは、つまりラベル付きのファイルシステムを表します/apps
。あなたによると、/etc/fstab
ext4タイプのファイルシステムでなければならず、にマウントする必要があります/apps
。
にリストされている他のすべてのファイルシステムは/etc/fstab
正常にマウントされました/apps
。出力によれば、対応するファイルシステムlsblk
は見つけることができるだけであることが示されます/dev/sdd
。アンマウントされたext4ファイルシステムを含むことができる他のデバイスはありません。
しかし、それによると、lsblk
ディスクにはパーティションがありません。ディスク全体を単一のファイルシステムに初期化しましたか?そうでない場合は、ディスクのパーティションテーブルが破損/上書きされたか、ディスクに障害がある可能性があります。
systemctl status apps.mount
および/またはインストールjournalctl -u apps.mount
の試行中に発生した問題に関する追加情報を提供することもできます。
他の初期化システムを使用する以前のRHELバージョンとは異なり、RHELベースのsystemd
RHEL 7.xは、ファイルシステムにマウントオプションがない場合は、リストされているファイルシステムのいずれかがマウントできない場合に緊急モードになります。したがって、マウント障害はシステムが緊急モードに移行する最大の理由です。/etc/fstab
noauto
nofail
/apps
一時的に最後の行をコメントアウトし/etc/fstab
て再起動して、システムをより正常な状態にすることができます。これにより、追加の診断と回復が容易になります。
/dev/sdd
まず、状態を確認してトラブルシューティングを開始できますsmartctl -x /dev/sdd
。ディスクエラーを示す場合は、新しいディスクを注文し、可能であれば、良好な/apps
バックアップから復元する計画を立てる必要があります。ただし、smartctl
ディスクにエラーが発生したことを示していない場合、これはすべてではない可能性があります。ディスクがsmartctl
常に検出できないようにエラーが発生する可能性があります。
(良いバックアップがなく、その中にあるデータの/apps
価値が大きい場合は、プロのデータ復旧サービスを使用するのか、それとも直接データを復旧するのかを決定する必要があります。)
/dev/sdd
パーティションテーブルが存在する必要があることを知っている場合は、testdisk
それを修復するのに最適なツールになることができます。
yum install epel-release
yum update
yum install testdisk
testdisk /dev/sdd
/dev/sdd
ディスク全体が単一のext4ファイルシステムに初期化されていると確信している場合は、次のことを試すことができます。
e2fsck -C0 /dev/sdd
ツールが質問を始めると(自動的に安定して解決できない問題があることを示す)、スキャンを中止して最初にディスクイメージを作成する必要があります。
メモ:このコマンド仮説あなたが指すデバイスしなければならないext2/ext3/ext4 ファイルシステムを含み、それに応じて動作します。有効なスーパーブロックが見つからない場合は、ディスクの先頭が破損しているか上書きされているか、ファイルシステムが単にディスクの先頭から起動していない可能性があります。
不明な場合、またはディスクにハードウェア障害の症状がある場合は、最初にすべきことはできるだけ早くエラーが発生したディスクをイメージすることです。ddrescue
または同様のツール。さらに、潜在的にエラーが発生したディスクのイメージを保存するには、適切なサイズの別のディスクが必要です。