私は、initramfs イメージから起動する、完全にカスタマイズされた最小限の組み込み Linux (vanilla、3.3.8、i486、Vortex86dx) システムを持っています。標準の配布スクリプトは使用されず、初期化を行う単一の rcS ファイルのみが使用されます。
/dev/hda1 と /dev/hda2 の 2 つのパーティションを持つ IDE フラッシュ ディスクがあります。
これは固定システム用の最小限の組み込みディストリビューションであるため、/dev/hda1 と /dev/hda2 を含む静的な /dev ディレクトリがあり、UDEV はありません。
init が rcS を呼び出す時点では、/dev/hda1 エントリは存在しなくなります。この時点では、他のスクリプト、ユーザー アプリケーション、デーモンは実行されていません。/dev/hda1登場カーネルによって削除された(?)
開発プロセス中に NFS ルート ファイルシステム経由でターゲットを起動すると、同じ問題は発生しません。
Buildrootを使用して、device_table_dev.txtファイル経由で/devディレクトリを作成します。例：
# IDE Devices
/dev/hda b 640 0 0 3 0 0 0 -
/dev/hda b 640 0 0 3 1 1 1 4
Buildroot の出力/images から rootfs.tar.gz を検査しました。/dev ディレクトリには /dev/hda1 が含まれています。
brw-r----- 1 root root 3, 0 Jul 2 13:44 hda
brw-r----- 1 root root 3, 1 Jul 2 13:44 hda1
brw-r----- 1 root root 3, 2 Jul 2 13:44 hda2
brw-r----- 1 root root 3, 3 Jul 2 13:44 hda3
brw-r----- 1 root root 3, 4 Jul 2 13:44 hda4
ターゲット上のブート後のディレクトリ リスト (rcS 内からスクリプトの先頭で実行) は次のようになります。
brw-r----- 1 root root 3, 0 Jul 2 12:44 hda
brw-r----- 1 root root 3, 2 Jul 2 12:44 hda2
brw-r----- 1 root root 3, 3 Jul 2 12:44 hda3
brw-r----- 1 root root 3, 4 Jul 2 12:44 hda4
/dev/hda1 がありません。/dev/hda2 は同じディスク上のパーティションですが、まだ存在しています。奇妙ですね。
Busyboxユーティリティ「mdev -s」を実行すると、ターゲット上の/dev/hda1が復元され、正常に動作します。たとえば、マウントできます。
これまでにこのような行動を見たことがある人はいますか?
カーネルは /dev からエントリを削除しますか?
答え1
サブシステムは、起動時にファイルシステムudevを作成してマウントします。デバイスが検出されると、カーネルによってコンテンツが設定されます。 は仮想メモリに存在するため永続的ではなく、変更は再起動すると保持されません。 がすでに存在する場合でも、新しいファイルシステムをマウントするとディレクトリが非表示になり、すべてのデバイス スペシャルが削除されたように見えます。実際には削除されていませんが、最終結果は同じです。スペシャルは期待どおりの場所には存在しません。tmpfs/devtmpfs/dev
hdaおよびエントリがおよびエントリhdaXに置き換えられていることに気付くと思います。 または、 および をチェックして、がドライブに割り当てた名前を取得してください。sdasdaX/proc/devices/proc/partitionsudev
場合によっては、次のような簡単な解決策がfdisk -l /dev/[sh]d[a-z]役立つことがあります (各タイプのディスクが 26 個未満の場合はより適切に機能します)。
ちなみに、 が使用する命名規則はudev標準化されており、静的メソッドで/devはこの規則に従うのがベストです。udevが だと考えている場合は/dev/sda、それに従ってください。そうすれば、将来的に生じる可能性のある奇妙な事態や誤解を回避できるかもしれません。