Löscht der Kernel Einträge in /dev auf einem Initramfs?

Löscht der Kernel Einträge in /dev auf einem Initramfs?

Ich habe ein vollständig angepasstes, minimales, eingebettetes Linux-System (Vanilla, 3.3.8, i486, Vortex86dx), das von einem Initramfs-Image bootet. Es werden keine Standardverteilungsskripte verwendet, sondern nur eine einzelne rcS-Datei, die die Initialisierung durchführt.

Ich habe eine IDE-Flash-Disk mit zwei Partitionen unter /dev/hda1 und /dev/hda2.

Da dies eine minimale eingebettete Distribution für ein festes System ist, verfügt sie über ein statisches /dev-Verzeichnis, das /dev/hda1 und /dev/hda2 enthält, und es gibt kein UDEV.

An dem Punkt, an dem init rcS aufruft, ist der Eintrag /dev/hda1 nicht mehr vorhanden. Zu diesem Zeitpunkt wurden keine anderen Skripte, Benutzeranwendungen oder Daemons ausgeführt. /dev/hda1erscheintvom Kernel gelöscht worden sein(?)

Dieses Problem tritt bei mir nicht auf, wenn ich mein Ziel während meines Entwicklungsprozesses über ein NFS-Root-Dateisystem boote.

Ich verwende Buildroot, um das Verzeichnis /dev über die Datei device_table_dev.txt zu erstellen. zB

# IDE Devices
/dev/hda    b   640 0   0   3   0   0   0   -
/dev/hda    b   640 0   0   3   1   1   1   4

Ich habe mir die rootfs.tar.gz-Datei aus Buildroot-Ausgabe/-Bildern angesehen. Das Verzeichnis /dev enthält /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

Meine Verzeichnisliste nach dem Booten (erstellt innerhalb von rcS, oben im Skript) auf dem Ziel sieht folgendermaßen aus:

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 fehlt. /dev/hda2 ist eine Partition auf derselben Festplatte, aber sie ist immer noch da. Seltsam.

Wenn ich das Busybox-Dienstprogramm "mdev -s" ausführe, wird /dev/hda1 auf dem Ziel wiederhergestellt und es funktioniert normal. Beispielsweise kann ich es mounten

Hat jemand dieses Verhalten schon einmal beobachtet?

Löscht der Kernel Einträge aus /dev?

Antwort1

Das udevSubsystem erstellt und mountet beim Booten ein tmpfsDateisystem /dev. Der Inhalt wird vom Kernel gefüllt, sobald Geräte erkannt werden. Da tmpfses sich im virtuellen Speicher befindet, ist es nicht persistent, sodass Ihre Änderungen bei Neustarts nicht erhalten bleiben. Selbst wenn Sie /devbereits ein haben, wird durch das Mounten des neuen Dateisystems das Verzeichnis ausgeblendet und es sieht so aus, als wären alle Ihre Geräte-Specials gelöscht worden. Das ist nicht der Fall, aber das Endergebnis ist dasselbe: Die Specials sind nicht dort, wo Sie sie erwarten.

Ich vermute, Sie werden feststellen, dass Ihre hdaund Einträge durch und Einträge hdaXersetzt wurden . Alternativ können Sie und überprüfen, um den dem Laufwerk zugewiesenen Namen abzurufen .sdasdaX/proc/devices/proc/partitionsudev

Manchmal fdisk -l /dev/[sh]d[a-z]kann eine schnelle und einfache Lösung wie hilfreich sein (funktioniert besser, wenn Sie weniger als 26 Festplatten jedes Typs haben).

Übrigens udevist das von verwendete Benennungsschema standardisiert, und Ihre statischen Angaben /devkönnten schlechter sein, als den Konventionen zu folgen. Wenn Sie udevmeinen, es sei /dev/sda, dann halten Sie sich daran. So vermeiden Sie spätere Merkwürdigkeiten und Missverständnisse.

verwandte Informationen