破損したinitrdをリモートでデバッグする方法は?

破損したinitrdをリモートでデバッグする方法は?

背景

Linuxを実行するシステムがあります。モニター、キーボード、シリアルポートのないNASです。ネットワークポートがあります。実行中のソフトウェアが気に入らず、別のディストリビューションを実行しようとしています。

私が所有しているもの

従来のシステムでは、Webインタフェースを使用してROMをアップグレードして新しいカーネルを取得し、initrdを起動することができましたが、そのアップグレードはカーネル、initrdを解凍し、次の実行に過ぎない特別に作成されたkexecイメージkexecでした。パラメータを使用して新しいカーネルを起動するために必要です。

initrdはネットワーク接続を確立し、SSHサーバーを起動して完了するまで待ちます。その後、別のスクリプトを実行します。これを使用していくつかのテストを実行できます。適切なカーネル/initrdで起動し、SSH経由でログインし、stage-2スクリプトをカスタマイズし、ドロップビーアを終了し、最善を尽くします。

この方法を使用して、ハードドライブに動作するオペレーティングシステムを正常にインストールしました。 (現在はNixOSが重要ですが、後で変更することもできますが、私の質問は特定のディストリビューションに関するものではありません。)私は意図的にいいえ起動可能にしてください。フラッシュをそのままにして、ハードドライブのデータを除いて、NASがまだ「公式」であることを確認したいと思います。しかし、ディストリビューション自体のカーネルとinitrdを取得し、それをアップグレードイメージに入れようとしています。

質問

このカーネルとinitrdを使用すると、システムを起動できません。

私の試み

私はディストリビューション設定と私の設定を共有initrdとして設定しましたが、引き続きdropbearで起動します。その後、SSHシェルでディストリビューションのinitスクリプトを実行してみました。ただし、これはPID 1で実行されるため失敗します。

その後、PID 1は任意のコマンドを受け入れようとしました。パイプでスクリプトを実行し、リモートシェルからそのパイプに書き込んで、コマンドが目的の効果を得たかどうかを手動で確認しようとしました。しかし、これはうまくいきません。 init-shell(PID 1)は、最初のコマンドの後にEOFを確認してすぐに終了します。こんにちは、カーネルパニックです。

また、systemd--systemオプションを渡してPID 1で実行されているかどうかにかかわらず、私のシェルでディストリビューションのinitスクリプトを実行すると何が起こるかをテストしました。この形式では問題を再現できません。ただ働きます。

私の質問:今は何ですか?

この時点では、実際に複数のコマンドを実行できる他の方法を見つけるためにパイプライン方法を検討しています。コマンドの出力も見ることができれば最高です。

基本的に:実際にモニターやシリアルケーブルを接続しないと、SSHセッションで実行できないPID 1で実行されているブートローダの出力をリモートで表示する方法を知りたいです。

まったく異なるアプローチをとる答えも大歓迎ですが、私が扱っているシステムの制限を念頭に置いてください。モニターやシリアルケーブルがないだけでなく、VGAやシリアルポートもありません。必要に応じてキーボードを接続できるUSBポートがありますが、当然私が入力したものは何も表示されません。

答え1

これを達成するための一般的なアイデアは、initをバックグラウンドでinitrdベースのブートスクリプトを生成し、システムのルートディレクトリをマウントし続け、[ -x /root/sbini/init ] && exec chroot /rootを実行するスクリプトに置き換えることです。 /sbin /初期化。 (存在しない場合を処理するには、以下にいくつかのコードを入れてください。)

答え2

SSHセッションが開始されると、他のセッションもここに書き込むことができます/dev/pts/<N>。したがって、何が起こっているのかを確認するには、どのPID 1が実行されるかを制御することができるので、そこに書き込むだけです。 PID 1を使用してexec 0<>/dev/pts/0 1<>/dev/pts/0 2<>/dev/pts/0他の何も読み書きしないことを確認すると、何が起こっているのかがわかります。ついに失敗したとき、ディストリビューションのinitスクリプトは何をすべきかを尋ね、R再起動を求める入力にも正しく応答しました。

私が経験している実際の問題は、必要なカーネルモジュールがロードされていないために発生したようです。すべてを手動で操作できましたが、これは明らかにブロック、RAID、およびファイルシステムモジュールを使用してロードできることを意味しましたが、ディストリビューションのinitscriptはudevに依存しており、特にこれにはいくつかの追加モジュールが必要であることがわかりましたunix。カーネルに直接ビルドしないオプションはありません。)

関連情報