Petalinux Projekte außerhalb der VM generieren

[Fpga I. (fpga-ing)]

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

[DPA (Gast)]

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.)

[Duke Scarring (Gast)]

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

[Strubi (Gast)]

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...

[Fpga I. (fpga-ing)]

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.

[fusi (Gast)]

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.

[Bernd K. (prof7bit)]

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).