Debian Jessieを実行している私のデスクトップコンピュータは、起動するたびに緊急モードシェルに入ります。画面には、journalctl -xb
原因の検索と使用を使用してsystemctl default
起動を続行するように求められます。を実行すると、systemctl default
数週間システムを使用した後でも、目立つエラーなしにシステムが起動し続けます。
その過程を通して、journalctl -xb
急激な悩みに陥る明確な理由はありませんでした。簡単に判断できる方法はありますか?正確に緊急モードに切り替えることにしたのはなぜですか?問題がどこにあるかを知ることができる他のフラグまたは起動オプションはありますか?
答え1
エラーは、隣のデバイスの説明とともに、[ FAIL ]
コンソール(代わりに)に赤で表示する必要があります。[ OK ]
多くの場合、最初の失敗が最も重要です。上にスクロールして最後のいくつかの出力画面を表示するには、コンソールで Shift+pageup を使用します。出力量が多すぎると動作しないことがあります。
この機能は通常、[ OK ]
メッセージが表示されない場合にも機能します(たとえば、Debianで使用されているカーネルコマンドラインのため)。quiet
最初の失敗では、systemdは詳細モードに切り替わります。
それ以外の場合は、オプションなしで使用でき、systemctl
赤色で欠陥が強調表示されている既知のセルの大きなリストが表示されます。失敗した項目のみを表示するには、systemctl --state=failed
またはを使用しますsystemctl --failed
。
ユニットファイルを検索する場合は、emergency.target
ブートを.mount
。local-fs.target
または、initramfsがsystemdを使用している場合initramfsがルートファイルシステムをマウントできない場合。
local-fs.target
持っていますOnFailure=emergency.target
。ローカルファイルシステムの単位がlocal-fs.targetのRequiresリストに自動的に追加されるため、失敗します(存在しない限りDefaultDependencies=no
)。
$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount
答え2
時々「メンテナンスモード」のプロンプトが表示され、エラーを見つけるためにログをスクロールする必要があります。 Journalctlはページネーターとしてlessを使用するため、検索に少ないショートカットを適用できるはずです。
通常、私は検索機能(/)を使用して、「エラー」、「警告」、または「失敗」に対応する項目を検索します。そして、-iが大文字と小文字を区別しない検索を強制していることを確認してください。
だから私のキーストロークは次の傾向があります。
-i (case insensitive)
g (move to start)
/error
nnnn (skip through results)
g (move to start)
/fail
nnnn (skip through results)
g (move to start)
/warn
nnnn (skip through results)
技術的には、これは正確な問題の徹底的または正確な検索ではありませんが、このように開始問題を見逃したことはありません。
関連性の低いキーボードショートカットは次のとおりです。
http://www.thegeekstuff.com/2010/02/unix-less-command-10-tips-for- Effective-navigation/
答え3
時々journalctl -xb
「less」をポケットベルとして使用すると、問題がすぐに見つからないようにすることができます。代わりに、次を使用します。
journalctl -xb | egrep -i '(error|fail|warn)'
静かでないスタートシーケンスのコピーもあり、/var/log/boot.log
色分けの問題を簡単に確認できます。
more /var/log/boot.log
「less」の代わりに「more」を使用する理由は、後者のデフォルトの動作が制御シーケンスを超えているため、カラーコーディングを(エヘム)無駄な真珠に変更するためです。