Parallels erstellt / Users / Shared / Parallels beim Booten und blockiert das Mounten von ZFS / Users

Weiß jemand, warum Parallels / Users / Shared / Parallels beim Booten erstellt? Oder was schafft es?

Ich habe ein ZFS-Volume für / Benutzer. Seit der Installation von Parallels 7 kann das ZFS-Volume jedoch nicht gemountet werden, da Parallels bereits zu Beginn des Startvorgangs ein leeres Shared / Parallels / backups-Verzeichnis in / Users abgelegt hat.

Jeder Weg, dies zu deaktivieren oder es zu verzögern, bis ZFS gemountet ist, wäre großartig.

Im Moment muss ich mich bei einer Konsole anmelden, einen Ersatz-Administrator-Benutzer zum Entfernen von / Users verwenden und dann meine / Users per ZFS-Mount bereitstellen. Alles sehr irritierend.

Es gibt mehrere System-LaunchAgents für Parallels, die jedoch nicht sehr aussagekräftig sind.

• OS: 10.8.2
• Parallels: Parallels 7 aktualisiert.
• ZFS: ZFS Community Edition

Updates für Graham:

alex@smiley:~|⇒  ls -lrt /Library/LaunchAgents/*ara* 
-rw-r--r--  1 root  wheel  797 Sep  3 16:12 /Library/LaunchAgents/com.parallels.vm.prl_pcproxy.plist
-rw-r--r--  1 root  wheel  565 Sep  3 16:13 /Library/LaunchAgents/com.parallels.desktop.launch.plist
-rw-r--r--  1 root  wheel  721 Sep  3 16:13 /Library/LaunchAgents/com.parallels.DesktopControlAgent.plist
alex@smiley:~|⇒  sudo launchctl list | grep arallel  
228 -   com.parallels.vm.prl_naptd
78  -   com.parallels.desktop.launchdaemon
alex@smiley:~|⇒  kextstat | grep arallel
  111    0 0xffffff7f8241f000 0x7000     0x7000     com.parallels.kext.prl_usb_connect (7.0 15107.796624) <39 7 5 4 3 1>
  112    1 0xffffff7f82426000 0x5c000    0x5c000    com.parallels.kext.prl_hypervisor (7.0 15107.796624) <10 9 7 5 4 3 1>
  113    0 0xffffff7f82482000 0x4000     0x4000     com.parallels.kext.prl_hid_hook (7.0 15107.796624) <7 5 4 3 1>
  114    0 0xffffff7f82486000 0xc000     0xc000     com.parallels.kext.prl_netbridge (7.0 15107.796624) <112 5 4 3 1>
  115    0 0xffffff7f82492000 0x4000     0x4000     com.parallels.kext.prl_vnic (7.0 15107.796624) <35 5 4 3 1>

Es sieht so aus, als ob DesktopControlAgent nicht geladen ist.

In Anlehnung an Grahams Zeiger auf wait4path habe ich com.parallels.desktop.launchdaemon.plist in / Library / LaunchDaemons folgendermaßen aktualisiert:

<key>ProgramArguments</key>
<array>
    <string>/bin/bash</string>
    <string>-c</string>
    <string>wait4path /Users/Shared/Parallels &amp;&amp; /Library/Parallels/Parallels\ Service.app/Contents/Resources/ParallelsDispatcherService start</string>
</array>

Das scheint es behoben zu haben. Zumindest wird Parallels weiterhin ausgeführt und der Computer wird beim Start ordnungsgemäß geladen.

Die Listenausgabe ist:

alex@smiley:~|⇒  sudo launchctl list com.parallels.desktop.launchdaemon
Password:
{
    "Label" = "com.parallels.desktop.launchdaemon";
    "LimitLoadToSessionType" = "System";
    "OnDemand" = true;
    "LastExitStatus" = 0;
    "PID" = 88;
    "TimeOut" = 30;
    "ProgramArguments" = (
        "/bin/bash";
        "-c";
        "wait4path /Users/Shared/Parallels && /Library/Parallels/Parallels\ Service.app/Contents/Resources/ParallelsDispatcherService start";
    );

Ich bin mir nicht sicher, ob es einen saubereren Weg gibt, die Pliste zu führen.

Zwei Befehle, um mehr über die beiden geladenen Objekte zu erfahren:

sudo launchctl list com.parallels.vm.prl_naptd

sudo launchctl list com.parallels.desktop.launchdaemon

Ich kann nicht die Bedeutung von prl_naptd erraten aber http://duckduckgo.com/?q=%22com.parallels.vm.prl_naptd%22+%22addPaths%22 schlägt eine Beziehung zwischen com.parallels.vm.prl_naptdund addPaths so vielleicht die Aufmerksamkeit auf dieses Startmittel konzentrieren .

Eine frühe Vermutung: Ein Workaround könnte beinhalten wait4path

wait4path (1) OS X Handbuch