私の古い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
を実行すると、hda
、hda1
、hda2
、またはhda3
デバイスがないことがわかります。これらのデバイスは通常は存在するはずです(udevが作成すると予想されます)。また、/dev
にはsda
、sda1
、sda2
、またはsda3
デバイスも含まれていないため、更新されたudevまたはカーネルが異なるディスクデバイスの呼び出し規則を変更する問題は発生していません。ディスクデバイスが「隠す」ことができる/dev/disk
ディレクトリもありません。
したがって、次の、潜在的に汚いステップは、hda1
の下にhda
、hda2
、hda3
、および/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
を書き込み可能として再マウントすることを除く)からSIGUSR1
をinit
に送信するポイントまで。今、私は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としてログオンできます(理論的には、この混乱の根本原因を修正します)。
カーネルを再コンパイルして、CONFIG_SYSFS_DEPRECATED
もCONFIG_SYSFS_DEPRECATED_V2
も設定されていないことを確認しました。
ただし、CONFIG_IDE
が設定されていない(およびカーネルがハードドライブを見つけられなかった)状態で数回再試行した後、CONFIG_IDE
setと、「下」にあるカーネル構成オプションをいくつか見つける必要があることが判明しました。非推奨の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に役立つことを願っています)