Mounten Sie TMPFS anstelle von ro / dev

1245
schiggn

Ich arbeite an einem ARM-basierten Embedded-System mit einem benutzerdefinierten Debian-Linux, das auf dem Kernel 2.6.31 basiert. Im endgültigen System wird das Root-Dateisystem auf Flash als squashfs gespeichert. Nun wird der Ordner / dev von udev erstellt. Da jedoch keine Hot-Plug-Funktionalität erforderlich ist und die Bootzeit kritisch ist, wollte ich udev und "hard code" aus dem / dev-Ordner löschen (lesen Sie hier, Seite 5). da ich noch die parameter der geräte ändern muss (mit ioctl / sysfs), funktioniert das in diesem fall für mich nicht. Also dachte ich daran, ein Tmpfs auf / dev zu installieren und die Parameter dort zu ändern. Ist das möglich? und wie geht es am besten? mein Ansatz wäre:

  • / dev aus RFS löschen
  • Erstellen Sie Teer mit Basisgeräten
  • mount tmpfs / dev
  • tar-Datei in / dev entpacken
  • Parameter ändern

Könnte das funktionieren? Sehen Sie Probleme?

Ich habe herausgefunden, dass Sie auf bereits montierten Mount-Punkt montieren können. Ist es irgendwie möglich, Daten mitzunehmen, während Sie das neue Dateisystem einhängen? wenn ja das wäre sehr bequem!

Vielen Dank

Update: Ich habe es gerade ausprobiert, aber ich stehe an einem bestimmten Punkt fest. Ich habe alle meine Geräte in devices.tar gepackt, in / usr meines Squashfs gepackt und die folgende Zeile zu mountkernfs.sh hinzugefügt, die direkt nach INIT ausgeführt wird.

#mount /dev on tmpfs echo -n "Mounting /dev on tmpfs..." mount -o size=5M,mode=0755 -t tmpfs tmpfs /dev mknod -m 600 /dev/console c 5 1 mknod -m 600 /dev/null c 1 3 echo "done." echo -n "Populating /dev..." tar -xf /usr/devices.tar -C /dev echo "done."

Das funktioniert gut bei der Version über NFS. Wenn ich printf im Code platziere, kann ich sehen, dass es ausgeführt wird, wenn ich den extrahierenden Teil auskommentiere und sich über fehlende Geräte beschwert.

  • Booten OK

    mmc0: new high speed SDHC card at address 0007 mmcblk0: mmc0:0007 SD04G 3.67 GiB  mmcblk0: p1 IP-Config: Unable to set interface netmask (-22). Looking up port of RPC 100003/2 on 192.168.1.234 Looking up port of RPC 100005/1 on 192.168.1.234 VFS: Mounted root (nfs filesystem) on device 0:14. Freeing init memory: 136K INIT: version 2.86 booting Mounting /dev on tmpfs...done. Populating /dev...done. Initializing /var...done. Setting the system clock. System Clock set to: Thu Sep 13 11:26:23 UTC 2012. INIT: Entering runlevel: 2 UBI: attaching mtd8 to ubi0

  • Die Extraktion des Teers auskommentieren

    mmc0: new high speed SDHC card at address 0007 mmcblk0: mmc0:0007 SD04G 3.67 GiB  mmcblk0: p1 IP-Config: Unable to set interface netmask (-22). Looking up port of RPC 100003/2 on 192.168.1.234 Looking up port of RPC 100005/1 on 192.168.1.234 VFS: Mounted root (nfs filesystem) on device 0:14. Freeing init memory: 136K INIT: version 2.86 booting Mounting /dev on tmpfs...done. Populating /dev...done. Initializing /var...done. Setting the system clock. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Unable to set System Clock to: Thu Sep 13 12:24:00 UTC 2012 ... (warning). INIT: Entering runlevel: 2 libubi: error!: cannot open "/dev/ubi_ctrl"

So weit, ist es gut. Aber wenn ich die ganze Geschichte in einen Squash packe und von dort boote, wirkt das seltsam. Es sagt mir beim Booten, dass es nicht möglich ist, eine anfängliche Konsole zu öffnen und Fehler beim Mounten der UBIFS-Geräte zu werfen, aber schließlich einen Login bereitstellt. Darüber werden meine Echos nicht ausgeführt. Wenn ich mich dann einloggen, wird / dev wie gewünscht als TMPFS eingehängt und alle Geräte befinden sich darin. Wenn ich den "mount" -Befehl zum Einhängen der UBIFS-Partitionen wiederhole, wird er ohne Problem ausgeführt und kann verwendet werden.

  • Von Squashfs

    VFS: Mounted root (squashfs filesystem) readonly on device 31:15. Freeing init memory: 136K Warning: unable to open an initial console. mmc0: new high speed SDHC card at address 0007 mmcblk0: mmc0:0007 SD04G 3.67 GiB  mmcblk0: p1 UBIFS error (pid 484): ubifs_get_sb: cannot open "ubi1_0", error -19

Außerdem wird noch ein Teil der restlichen Bootskripte ausgeführt, jedoch nicht alle. Hat jemand eine Ahnung warum? Andere Frage, ist 5MB genug / zu viel für / dev?

3
und um endlich eine Lösung hinzuzufügen, habe ich das Problem gelöst. Ich habe / dev / console nicht für INIT bereitgestellt, deshalb hat es sich beschwert. Die Lösung besteht darin, / dev / null und / dev / console in die Squashfs aufzunehmen. Während des Bootvorgangs geschieht Folgendes: -> Verwenden Sie / dev aus squashfs -> mounten Sie TMPFS / dev über / dev aus squashfs -> füllen Sie aus tar aus. Die Frage nach der Größe von TMPFS bleibt dabei. Ist 5MB viel zu wenig genug? schiggn vor 11 Jahren 0

1 Antwort auf die Frage

0
Ярослав Рахматуллин

Forgetting to create a /proc folder and a /dev/console device are two common pitfalls when creating a boot-ramfs by hand, as you have identified.

As for the size of /dev, I think half a megabyte will go a long way. In your case, since the number of devices will more or less be constant once the system has booted, it is safe to look how much space /dev is using and make the filesystem that size plus five-ten percent for fs overhead (file and folder nodes).

Verwandte Probleme