Hallo zusammen, für mein Zynqberry Board verwende ich eine Virtual Box VM, in der ich meine Petalinux Images baue. Das klappt wunderbar, solange ich im Dateisystem der VM arbeite. Leider scheitert das Bauen, sobald mein Build Verzeichnis in einem Virtual Box Shared Folder liegt. Auch ein NFS Ordner meiner NAS eignet sich nicht als Ziel. Gibt es eine Möglichkeit, mein Build Verzeichnis außerhalb der VM zu haben und auf irgend einem Weg dann in die VM einzubinden? Gibt es alternativ eine Möglichkeit, vom Windows Host auf das Dateisystem der VM zuzugreifen? Der erste weg wäre mir lieber, da ich dann VM (Build System) und Daten (Petalinux Projekt) separat betrachten könnte und beispielsweise eine VM für mehrere Projekte verwenden könnte. Ach ja, noch einige Infos zum System: Host: Windows 7 VM: Ubuntu 16.04 Virtual Box 6.xx Synology NAS verfügbar Ich freue mich auf Eure Ideen! Viele Grüße Martin
Fpga I. schrieb: > Leider scheitert das Bauen, sobald mein Build Verzeichnis in einem Virtual Box Shared Folder liegt. Gibt es eine Fehlermeldung, oder startet das Image dann einfach nicht? Zunächst müsste man herausfinden, was genau schief läuft. Ich kenne Petalinux nicht. Bootstrappt das ein vollständiges Rootfs im Build Verzeichnis? Falls ja, muss dieses ebenfalls extern liegen? Es gibt viele Dinge, die schief laufen könnten. Wenn ich z.B. ein Debian System bootstrappe, muss das Verzeichnis in dem ich das mache als Executable gemountet sein. Je nach System muss man auch mit mknod device files erstellen können. Und dann sollten auch noch die Benutzer, Gruppen und xattrs beibehalten werden. Bei NFS sind noch locking Probleme oder Race Conditios denkbar. Und bei speziellen Dateisystemen, z.B. 9p, hab ich schon gesehen dass bei richtigen Permissions gewisse aktionen trotzdem ein Permission denied generiert haben, weil dem Emulator die nötigen Berechtigungen fehlten, das ist dan recht aufwendig all die diversen Absicherungen zu überprüfen und jenachdem auszuschalten. Falls ein vollständiges Rootfs im Build Verzeichnis erstellt wird, und das nachdem das Image erstellt wurde nicht gelöscht wird, dann builde es einmal Lokal in der VM, und kopieren den build folder dann mit "cp -a" aufs externe Laufwerk. Dann versuche mal zu vergleichen, stimmen die Benutzer mit "ls -la" überein, gibt es bei beiden Dateien eines einem anderen Benutzer oder einer anderen Gruppe als der rest (find . -not -user 123 -or -not -group 234), oder gibt es plötzlich mehr Dateien mit User nobody oder gruppe nogroup, kann ich ein device File erstellen (mknod test) und ein Program erstellen und ausführen (touch testprog; chmod +x testprog; ./testprog), kann ich den Besitzer einer Datei ändern (touch testfile; stat testfile; chown 3:4 testfile; stat testfile), etc. Sobald du weist, was das Problem ist, kannst du es beheben (z.B. exporteinstellungen beim NAS anpassen, lokale mkount optionen ändern, etc.)
Problematisch dürften Softlinks (ln -s) und Zugriffsrechte (chmod) sein. Ein Lösung dafür kenne ich auch (noch) nicht. Weiß jemand ob und wie das bei Docker funktioniert? Duke
In Docker funktionieren solche Spässe, solange man einen Linux-Host hat, ansonsten ist mit boot2docker das Problem mit der VM wieder da. Fpga I. schrieb: > Gibt es alternativ eine Möglichkeit, vom Windows Host auf das > Dateisystem der VM zuzugreifen? Samba-Server, und die Build-Verzeichnisse exportieren. Dann in Windows mounten...
Die Synology NAS verwendet ja nen Samba Server. Nun muss ich erst mal sehen, wie ich meine UIDs und Gruppen angleiche, um die erforderlichen Rechte zu erhalten. Aktuell erhalte ich noch Fehlermeldungen wie z.B. diese hier: rsync: chgrp "/home/zynqberry/vmShare/petalinux/build/misc/config/data" failed: Permission denied (13) Ich melde mich, wenn es läuft.
sshfs. Auf dem Host (dort wo der Ordner liegen soll) einen SSH Server starten (z.B. ubuntu und debian: apt-get install openssh-server). Benutzer nehme ich mal "user" an und IP des hosts 192.168.0.10. Dann in der VM sshfs installieren (fuse-sshfs oder sshfs heisst das Paket in der Regel, bei debian usw heisst es schlicht sshfs). Dann das in der VM ausführen: mkdir /mnt/sshfs sshfs user@192.168.0.10:/dein/Ordner/auf/dem/host /mnt/sshfs So konnte ich schon bauen, wo NFS ausgestiegen ist und SMB gar nicht erst wollte.
Ich persönlich behandele ausgewachsene VMs als wärs ein komplett anderer Arbeitsplatz mit eigener Lokaler Platte, sprich: ich klone das Repository und verwende git pull/push zum Austausch von Codeänderungen. Ausnahme: Docker, das ist ja gerade dafür gemacht auf dem selben Rechner nur schnell temporär eine andere Inneneinrichtung einzublenden, da mounte ich direkt den ganzen Ordner in dem ich mich gerade befinde (bau mir dafür enstprechende Helperscripte die das auf Zuruf schnell machen).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.