web-dev-qa-db-ja.com

gentooブートで/ dev / hda3を作成しないudevのトラブルシューティング方法は?

私の古いgentooラップトップは、おそらくemergeを使用してソフトウェアを更新し、udev + kernelをアップグレードし、「udev/kernelをアップグレードした後にこれらのことを実行してください」というメッセージを受け取り、「見てみます」と考えているために、udevに問題があるようです。画面出力に表示され、システムを再起動する前に、これらのメッセージを読み、後で処理してください。」残念ながら、少し急いでいたので、もちろん、これらのメッセージを確認するのを忘れ、マシンをシャットダウンし、物理的に現在の自宅の場所に移動して起動しましたが、/dev/hda3が見つからなかったために迎えられました。

手動で/dev/hda3を作成し、initにシステムの起動を続行させることで、これを回避することができました(以下で詳しく説明します)が、これを完全に修正する方法についてアドバイスが必要です(したがって、起動するたびに以下の手順を繰り返す必要はありません)。

(インストールしたパッケージのインストール後のメッセージをすべて見つけることができるGentooマシンを誰かが指すことができれば、udevとカーネルに関連する指示を見つけることができます。)

関連するソフトウェアバージョン:

Gentoo-hardened-kernel 2.6.36-r6(推奨)および2.6.28-r9(シャットダウン前の21か月間使用)。以下で説明する面倒な手動起動プロセスは、両方のカーネルバージョンで機能することが確認されています。 udevパッケージはudev-151-r4です。

起動すると、すべてが正常に見えるようになります(マシンはカーネルを起動し、/ proc、/ sys、/ devをマウントし、udevdを起動し、ueventsに基づいて/ devにデータを入力し、ueventsを処理し、/ dev/ptsをマウントします)。 「ルートファイルシステムのチェック」のステップ。

そこで放出します

Failed to open the device '/dev/hda3': No such file or directory

次に、rootパスワード(または続行するにはCtrl-D)を要求されます。

それを入力すると、シェルでmountは、rootfsがマウントされており、/dev/root/にマウントされていることを示しています。また、mountは、/etc/mtabが書き込み可能ではない(読み取り/専用ファイルシステムなど)と文句を言います。起動が完了していないことを考えると、これはすべて私には理にかなっています。

ls /devを実行すると、hdahda1hda2、またはhda3デバイスがないことがわかります。これらのデバイスは通常は存在するはずです(udevが作成すると予想されます)。また、/devにはsdasda1sda2、またはsda3デバイスも含まれていないため、更新されたudevまたはカーネルが異なるディスクデバイスの呼び出し規則を変更する問題は発生していません。ディスクデバイスが「隠す」ことができる/dev/diskディレクトリもありません。

したがって、次の、潜在的に汚いステップは、hda1の下にhdahda2hda3、および/devを手動で作成することです(他のgentooサーバーの1つを覗いて、メジャー番号とマイナー番号を適切に把握しました権限とグループメンバーシップ):

mknod /dev/hda b 3 0
mknod /dev/hda1 b 3 1
mknod /dev/hda2 b 3 2
mknod /dev/hda3 b 3 3
chmod 660 /dev/hda*
chgrp disk /dev/hda*

残念ながら、Ctrl-Dを実行するか、ここにexitを書き込むと、中断されたブートシーケンスは続行されませんが、代わりに再起動が開始されます(これにより、マシンは/dev/hdaが見つからない状態になります)。thatこの問題を解決するためのパスは、残念ながら役に立ちません。

initが開始され、さまざまなinitスクリプト(/ proc、/ sys、および/ sysのマウントなど)の実行を開始するとすぐに、「I」を押す場所を試した(失敗した)別の回避策など)が、ブートシーケンスが/ dev/hda3をチェックする(失敗した)試行に達する前に、インタラクティブブートモードに入ることができません。

代わりに、/dev/hda3デバイスを使用してOSファイルシステムをマウントし続けます。
mount -o remount -o rw /dev/hda3 /

これで、マシンのファイルシステムへの書き込みアクセス権が与えられ、この状況のトラブルシューティングに関するいくつかのオプションが提供されます:構成ファイルの修正、さまざまな初期化の開始-スクリプトやサブシステムなど。

notが機能しないことの1つは、ランレベルを変更することです。その理由は、init 3がエラーメッセージinit: /dev/initctl: No such file or directoryで失敗するためです。もう一度、他のGentooサーバーをスニークピークすると、/dev/initctlがアクセス許可600を持ち、root:rootに属するパイプであることがわかったので、それを再作成します。

mknod /dev/initctl p chmod 600 /dev/initctl

init 3は失敗しますが、少し異なります。しばらくハングしてから、メッセージinit: timeout opening/writing control channel /dev/initctlをあきらめます。元のinitプロセス(プロセスID 1)には、この新しく作成された/dev/initctlが読み取られるように開かれていないため、これは理にかなっています。

さて、initのマニュアルページを読むと、SIGUSRを送信するとinitが閉じて/dev/initctlが再び開くことがわかります。 正確に必要なものなので、コマンドkill -lを実行して、すべての信号とその番号のリストを取得します(SIGUSR1の番号は10であることがわかります) )次に、コマンドを発行します
kill -10 1
init/dev/initctlに再度開くには、実行レベル3の入力を再試行します。
init 3

ここで、initはランレベル3に入ろうとし、多数のスクリプトを実行します。残念ながら、これらのスクリプトはすべてERROR: cannot run syslog-ng until sysinit completesで失敗します。そこで、システムを再起動し(init/dev/initctlをリ​​ッスンさせたので、実際には期待どおりに動作します。rootとしてログオンし、rebootを発行します)、繰り返します。上記の手順(/dev/hda3を書き込み可能として再マウントすることを除く)からSIGUSR1initに送信するポイントまで。今、私はinitにブートシーケンスを再開させようとしていますが、より穏やかな方法で、/etc/inittabファイルを再読み取りさせます。

init q

何も起こらなかったようです。そこで、sysinitと呼ばれるように見えるランレベルのエントリを見つけた/etc/inittabを調査します。私はリスクを冒してそれを再実行します:

init sysinit

今回はinitが使用法のメッセージで文句を言います。 /etc/inittabをもう一度読むと、sysinitエントリが引数sysinitを使用して/sbin/rcを呼び出していることがわかります。だから、私はthatを試してみることにしました:

/sbin/rc sysinit

システムはいくつかのサービスの起動を再試行し成功します!それだけでなく、/proc/sys、および/devをマウントするためにinitスクリプトを再実行すると、それらがすでにマウントされているかどうかを確認するためのチェックが行われます(コードでサニティチェックとエラーチェックを実行し、それに応じて動作することがどれほど価値があるかを証明します例外的な状況に遭遇したとき)。これに満足して、/etc/inittabエントリbootwaitのコマンドも実行することにしました。これも、ランレベルの文字または数字が欠落しているためです。

/sbin/rc boot

繰り返しになりますが、主にネットワーキングのために、いくつかのinitスクリプトが開始されます。予期しないエラーは報告されていないので、ランレベル3への移行を再試行できます。

init 3

Initscriptが終了すると、マシンが起動し、rootとしてログオンできます(理論的には、この混乱の根本原因を修正します)。

2
IllvilJa

カーネルを再コンパイルして、CONFIG_SYSFS_DEPRECATEDCONFIG_SYSFS_DEPRECATED_V2も設定されていないことを確認しました。

ただし、CONFIG_IDEが設定されていない(およびカーネルがハードドライブを見つけられなかった)状態で数回再試行した後、CONFIG_IDEsetと、「下」にあるカーネル構成オプションをいくつか見つける必要があることが判明しました。非推奨のATA/ATAPIサポート。繰り返しになりますが、他のサーバー(/ dev/hda検出が適切に機能している)でスニークピークが発生し、不足しているATA/ATAPI関連のカーネルオプションを追加しました。 どれ実際に追加したオプションは書き留めていませんが、ATA/ATAPIでアクティブ化されたすべてのオプションのリストは次のとおりです。CONFIG_IDE_Gd
CONFIG_IDE_Gd_ATA
CONFIG_IDE_PROC_FS
CONFIG_IDE_GENERIC
CONFIG_IDE_PCIBUS_ORDER
CONFIG_BLK_DEV_GENERIC
CONFIG_BLK_DEV_PIIX

また、シリアルATAとパラレルATAのサポートを無効にしました。

したがって、now起動して、/dev/hda3デバイスを正常に検出するカーネルがあります。

非推奨のATA/ATAPIカーネルサポートに依存し、notより新しいSATA/PATAカーネルサポートを使用することは、これが悪い習慣であることを私は知っています。最終的には、代わりにSATA/PATAに移行する必要があります。しかし今のところ、私は満足しています(そして私のLinuxシステムについてもう少し知識があります)。

(そして、質問を投稿してから回答し、受け入れられたものとして自分の回答を選んだ場合は、お詫びします。この回答/質問がU&Lに役立つことを願っています)

4
IllvilJa