Ich bin nicht sicher undrestand (aus die Verzeichnisse Beschreibung in Buildroot Handbuch):
Buildroot, ein Werkzeug für einen Kernel und root-Dateisystem zu erzeugen, auf dem Host-System als normaler Benutzer ohne die Notwendigkeit ausgeführt wird Superuser-Privilegien.
Warum Wurzel buildroot müssen, um die/dev
Buildroot nicht Superuser-Privilegien nutzen zu erstellen.
, was ich weiß ist, dass buildroot Ziel verwendet images/rootfs.tar zu erzeugen; ist es eine einfache Komprimierung mit taror ...?
Die .tar ist ein gewöhnliches Archiv ohne Komprimierung.
Sie können die Komprimierung konfigurieren (und/oder Dateisystembilder auswählen), indem Sie die Prozedur make menuconfig verwenden.
könnten Sie mir bitte helfen, das Make Ziel zu finden, die Bilder/rootfs.tar generieren?
Sie geben dies nicht im Shell-Befehl make ein.
Sie können tar- und/oder cpio-Archive mit optionaler Komprimierung konfigurieren (und/oder Dateisystemimages auswählen), indem Sie die Prozedur make menuconfig verwenden.
Bei NFS, warum können wir nicht direkt den Zielordner als rootfs verwenden
Denn es ist nicht geeignet als Dächer ist.
Dateibesitzer & Gruppen sind falsch (dies könnte für die NFS-Verwendung irrelevant sein).
Dateiberechtigungen sind möglicherweise nicht korrekt (z. B. setuid für die Binärdatei busybox).
Das Verzeichnis/dev verfügt nicht über die minimalen Geräteknoten, die der Zielkernel benötigt.
Statt des erforderlichen minimalen Geräteknoten (z console), hat das Zielverzeichnis gewöhnliche Dateien in dev:
buildroot-2015.05/output/target$ ls -l dev
total 4
-rw--w--w- 1 me swdev 0 Sep 15 16:34 console
lrwxrwxrwx 1 me swdev 10 Aug 14 2015 log -> ../tmp/log
drwxrwxr-x 2 me swdev 4096 May 31 2015 pts
$
Das Ziel Kernel diese Dateien nicht verwenden kann, wenn sie Geräteknoten erwartet. Anstelle von E/A, die über Geräteknoten ausgeführt werden, werden normale Dateiübertragungen mit diesen Dateien versucht.
Die tatsächliche dev Verzeichnis sollte sein:
crw--w--w- 1 root root 5, 1 Sep 15 16:34 console
lrwxrwxrwx 1 root root 10 Aug 14 2015 log -> ../tmp/log
drwxr-xr-x 2 root root 4096 May 31 2015 pts
was "untaring" images/rootfs.tar anders als Ziel
Buildroot für geschickt erstellen Einträge macht Das Gerät knotet und weist jedem Dateinamen beim Erstellen des Archivs (oder Dateisystemimages) den richtigen Besitzer und die richtige Gruppe zu.
Dies erzeugt einfach binäre Daten in dem entsprechenden Format, das mit tatsächlichen Archiveinträgen (oder dem fs-Bild) eingefügt wird, die in eine Datei geschrieben werden.
Nur wenn es nicht archiviert wird (oder das Dateisystemimage eingehängt wird), werden die "Daten" ordnungsgemäß wie für Geräteknoten interpretiert.
(1) Buildroot, ein Tool zum Generieren eines Kernel- und Root-Dateisystems, wird auf Ihrem Host-System als normaler Benutzer ohne die Notwendigkeit von Superuser-Privilegien ausgeführt. (2) Die .tar ist ein gewöhnliches Archiv ohne Komprimierung. Sie können die Komprimierung (und/oder Dateisystemimages) mit der Prozedur 'make menuconfig' konfigurieren/angeben. Sie geben dies nicht im Shell-Befehl 'make' an. – sawdust
@sawdust, danke für das Feedback, vielleicht war meine Frage nicht direkt. was ich wissen muss ist, warum wir 'target' nicht als rootfs in buildroot manual verwenden können. Es heißt, dass es' dev' nicht enthält, da Buildroot nicht als root läuft, also warum es root-Rechte benötigt, um es zu erstellen – Mouin