☰

ルートが読み取り専用のときに upstart がハングした場合、どのようにデバッグすればよいですか?

tag-icon • tag-icon boot mount upstart
ルートが読み取り専用のときに upstart がハングした場合、どのようにデバッグすればよいですか?

14.04.2 LTS で失敗した/ハングしたシステム起動 (upstart) をデバッグしようとしています。ルートは luks コンテナ内の ext4 ファイルシステムです。ファイルシステムはクリーンな状態です。

ブート プロセスは upstart-socket-bridge の後に停止します (必ずしも特定のサービスの後に停止するわけではありません。たとえば、cups-daemon がインストールされると、その後停止します)。これinit -vもあまり役に立ちません。さまざまなサービスの開始/停止を単に記録するだけではない唯一のログ エントリは、init の直前の udev に関するものです。

Begin: Running /scripts/init-bottom ... done.
udev exit failed --rc=2

(編集) 当初、ルート rw を再マウントすると常にクリーン ブートにつながるように見えましたが、実際には予測不可能であり、いずれにしてもブートが失敗したり成功したりしました。何ですか?

観察: すべて正常に見えますが、システムは単にルートを書き込み可能に再マウントしたり、ブートを続行したりしません。

質問：ブート プロセスが停止する原因となっているサービスを特定するにはどうすればよいですか?

更新: getty経由で2番目のシェルを生成すると、initctl listハングアップした後に実行できます。これらは実行中のジョブです。

mountnfs-bootclean.sh start/running
udev start/running, process 438
upstart-udev-bridge start/running, process 432
plymouth start/running, process 122
resolvconf start/running
ssh start/running, process 767 <-- this one was manually started
mountall start/running, process 337
mountkernfs.sh start/running
mountnfs.sh start/running
bootmisc.sh start/running
upstart-socket-bridge start/running, process 745**
cryptdisks start/running
mountdevsubfs.sh start/running
mtab.sh start/running
network-interface (lo) start/running
network-interface (eth0) start/running
plymouth-ready (startup) start/running, process 315
plymouth-upstart-bridge start/running, process 316
mountall-bootclean.sh start/running
network-interface-security (network-interface/eth0) start/running
network-interface-security (network-interface/lo) start/running

アップデート2:

  • upstart とそのすべての依存パケットを再インストールしても (面倒で) 効果はありません。
  • init 52 番目のコンソールを使用すると、スタックしたシステムが正常に起動し続けることができます。
  • ルート rw を手動で再マウントしても (または rw カーネル パラメータを使用しても)、システムが停止するようになりました。ルートを書き込み可能に強制すると問題が回避できるという私の最初の観察は間違っています。

回避策:

どうやら、これは S のせいのようですureadahead。これをパージすると、5 回も問題なくクリーン ブートできました。元の質問に興味がある方や回答を知っている方のために、この質問 (および 100 回の追加レップ) をオープンのままにしておきます。ランダム トライアルでなければ、どうすればこの答えがわかったでしょうか。

答え1

参考までに、私が試した（失敗した）デバッグ手順を示します。ただし、他の人にとって役立つかもしれません。

  • 起動可能な別の Debian ライクなシステム (例: 起動可能な USB ペンドライブ上のライブ Ubuntu) を取得し、chroot を使用して検査対象のシステムに対して構成またはソフトウェアの変更を行います。異なるアーキテクチャのシステムでこれを行うには、qemu-static を使用します。
  • のようなスタンドアロンシェルをインストールしsash、カーネルコマンドラインを変更し（grubでeキーを使用するか、grub.cfg/cmdline.txtを編集して）、 を追加しinit=/bin/sash、再起動し、そのシェルの状況を調べてから、 を使用してexec init起動を続行します。
  • initスイッチと一緒に使用して-vログ記録を増やす
  • ルートファイルシステムを書き込み可能に早めにマウントする（例えば、initを実行する前にカーネルコマンドラインに「rw」を追加するmount -o remount,rw /） - これにより、より多くのログが可能になります。
  • 診る/var/log/upstart
  • init を実行する前に tty2 で追加のターミナルを起動します。getty -n -l /bin/bash 38400 tty2 &これは、システムの状態を調べるのに役立ちます (例ps -Af: iotop)
  • initctl listどのサービスがどの状態にあるかを把握するために使用します

関連情報