Beiträge von QSchneider

    PJH, das mit dem Namen ist ok, ich wusste ja wer gemeint war ;-)


    Was dein noch bestehendes Problem angeht, so würde ein Screenshot vielleicht weiterhelfen und auch die Infos, welche ich in meinem letzten Beitrag angefragt hatte.

    Code
    1. 1. Einstellungen in der config.plist
    2. 2. hast du eine DSDT und/ODER SSDT in CLOVER/ACPI/patched ?
    3. 3. Welche Treiber hast du in "Drivers64UEFI", bzw. "drivers64" eingebunden
    4. 4. Welche Einträge stehen bei dir in CLOVER/kexts/10.10 ?
    5. Des Weiteren müsstest du einmal beschreiben, was du den von dem von mir geposteten Anweisungen auf der Toledo Seite ausgeführt hast und was das Ergebnis im Terminalfenster oder in der EFI Struktur/config.plist ergeben hat.


    Da Bluetooth ja „intern“ über den USB-Bus angebunden ist, kann dein Problem auch mit einem falsch/unvollständig konfiguriertem USB-Stack zusammenhängen.
    Das ist aber mehr eine Vermutung als das ich dies wissen würde.


    Ein Screenshot aus den „Systeminformationen“ wäre toll. Ich habe dir mal die entsprechen Punkte als Grafiken angehängt. Dort siehst du wie es auf meinem originalem MPB ausschaut.


    Für mich als Feedback wäre noch interessant, was du denn jetzt genau gemacht hast, die Methode von toleda mit der wireless_bcm94352-110-v4.0.command.zip, oder den Weg von Rehabman mit FakePCIID for BCM94352 gegangen bist ?

    Ich würde auch erst einmal mit der internen GPU anfangen und schauen ob sie ausreicht.
    Wenn es eine 4160/70 CPU wird, ist dort eine HD4400 eingebaut. Leistungsmäßig reicht die selbst für hohe Ansprüche im Bürobetrieb aus.


    Was zu klären wäre, was das endgültige Board an Anschlüssen mitbringt - HDMI/DVI oder gar DP und was für ein Monitor für den Rechner vorgesehen ist.
    Wenn es ein iTX-Board wird, wäre auch der einzige PCI-Steckplatz belegt, was ebenfalls dagegen sprechen würde.


    Der einzige Grund zum jetzigen Zeitpunkt für eine kleine Nvidia wäre nur die möglicherweise einfachere Installation eines Hacks.

    Hallo MacGrummel, danke für die umfassende Antwort, mein Posting war auch nicht als Kritik wegen der Unvollständigkeit deiner Anleitung gedacht.


    Der Aufhänger war lediglich, das ich über deinen, von mir zitiertem Satz gestoßen bin und vorher auf der englischsprachigen Seite den Post gelesen hatte.
    Mein Beitrag bezieht sich konkret nur auf den Spoilerblock "Bei Clover ..." und dreht sich nur um die Clover-, bzw Clover Configurator spezifischen Einträge


    Der bisherige Satz, "das aus unbekannten Gründen irgend etwas vertauscht werden muss", verwirrt mMn mehr als er in einem "Kochrezept" hilft.
    Vielleicht macht es den Spoiler deutlicher, wenn dort stehen würde, was man nun genau im Clover Configurator eintragen muss und dies sind nach meinem Stand


    - ROM, MLB (in RT Variables)
    - und Custom-UUID + Inject System ID (in System Parameters)
    Der Eintrag SmUUID aus dem Bereich SMBIOS des CloverConfigurator (welcher die Hardware UUID darstellt) muss NICHT gefüllt werden.


    Wäre das so korrekt ausgedrückt ?

    Super Idee, Hobbit,
    ich werde die geplante Beschreibung meines Builds an deinem Gerüst ausrichten und bald posten (verschiebt sich aufgrund des guten Wetters).


    Hier einmal meine subjektiven Erfahrungen mit den drei Bootmöglichkeiten, die ich in der Reihenfolge meiner Hackintosh-Entwicklung aufgelistet habe.


    Chameleon (Chimera bzw. Unibeast/Multibeast)
    pro
    + der Klassiker, für den viele Anleitungen im englischsprachigen Bereich existieren
    + Trennung zwischen Bootloader und nachgelagerter Installation von Erweiterungen (kext)


    contra
    - trotz der Möglichkeit kexte im Extras Ordner während des Bootvorgangs einzufügen, fehlt die Möglichkeit von Clover in kexte zu injecten
    - für mich daher zu statisch und unflexibel


    Ozmosis
    pro
    + super für Einsteiger, die "nur" mit OS X arbeiten wollen!
    + toller Support hier im Forum


    contra
    - mMn nur für Gigabyte Boards optimal einsetzbar.
    - problematisch, sofern der freie Speicher im BIOS nicht ausreicht um alle kexte unterzubringen. Dann brauche ich doch den Extras Ordner mit den Einschränkungen die Chameleon hat.
    - Abhängigkeit von externer Seite zB bei BIOS- oder Ozmosis-Updates, da die Einfachheit natürlich auch mit sich bringt, das der Enduser sich mit den Hintergründen des System nicht beschäftigen kann/will.



    Clover
    pro
    + extrem mächtig und flexibel
    + kann eigenständig Optimierungen vornehmen, zB bei der Wahl einer Systemdefinition oder dem Ersetzen von PCIids
    + kann in kexte injecten, dh. es besteht bei nicht zu exotischen Builds die Möglichkeit, S/L/E komplett unangetastet zu lassen.
    + kann den Kernel on-the-fly patchen, so dass idR kein custom Kernel erstellt und gepflegt werden muss.
    + kann die ACPI-tables patchen, was ansonsten per DSDT oder SSDT statisch erfolgen müsste. (Wobei Letzteres in Maßen vorzuziehen ist)


    contra
    - sehr mächtiges, aber mMn auch ein sehr selbstständig agierendes System, welches das troubleshooting schwerer macht, da zB ein erneuter Reboot den Unterschied zwischen KP oder Systemstart ausmachen kann.
    - auf den ersten Blick verwirrend viele Optionen, die einen in der falschen Kombination zum Wahnsinn treiben können.
    - Notwendigkeit sich tiefer damit zu beschäftigen, wie ein PC zum Mac werden kann.
    - benötigt Planung, welche der oben beschriebenen Features genutzt werden sollen (oder nicht) - hier gilt weniger ist mehr.



    Mein Fazit
    Für den Anfänger Ozmosis, für den Fortgeschrittenen Clover, Chameleon als „Old-school“ Alternative


    Clover ist hier ganz klar mein Favorit, WENN man geplant vorgeht.
    So sollte mMn die Bereiche DSDT, SSDT und Systemdefinition statisch gehandhabt werden, die Bereiche kext-injection mittels Hilfe von Zusätzen wie FakePCIid oder audio_CloverALC durch Clover. Danach bleiben dann nicht mehr viele „Optionen“ übrig, die in Clover eingetragen werden müssen und Clovers „Eigenintelligenz“ ist etwas gebändigt …

    MacGrummel
    Bei meinen aktuellen Recherchen zu Clover bin ich vielleicht auf die Antwort auf deinen Satz in deiner Anleitung gestoßen.

    Zitat

    SmUUID und Custom-UUID müssen aus irgend einem Grund hier aber vertauscht eingetragen werden

    Google bitte einmal "Clover v.2 Instructions". Im post #23 "iCloud fix" ist der Grund für die Vertauschung aus meiner Sicht erklärt.
    Wenn ich es richtig lese, wird aus der Custom-UUID die Hardware UUID errechnet und muss nicht mehr explizit angegeben werden.


    Dies deckt sich mit meiner aktuellen Konfiguration bei der nur ROM, MLB und Custom-UUID (incl. Inject System ID) benötigt werden, die Hardware UUID bzw. SmUUID dagegen leer ist, sie aber trotzdem in der Hardwareübersicht und iMessage Debug auftaucht.


    Dies wäre dann insofern interessant, da dann eine neue Systemdefinition nicht zu Problemen mit iMessage führen dürfte.


    In meinem konkreten Fall hatte ich vorher gar nichts im Bereich SMBIOS angegeben.
    Clover hat für mich daher die Systemdefinition Macmini6,2 beim Booten festgelegt.
    Nachdem ich eine externe GPU eingebaut hatte wurde daraus plötzlich ein iMac13,1.
    Da ich aber verhindern wollte, dass mir Clover meine Systemdefinition mit jeder Hardwareänderung verändert, habe ich im SMBIOS explizit iMac13,1 ausgewählt. Dabei wurde natürlich keine SmUUID angelegt, trotzdem blieb die Hardware UUID gleich.


    Spricht also dafür, das es sich verhält wie im posting von slice erwähnt ... oder liege ich falsch ?

    Moin jaques, gut zu hören, das du was passendes gefunden hast, ich bin bei der gleichen GPU gelandet.
    Ich habe meine ersten Erfahrungen hier gepostet, vielleicht gibt dir das einen Anhaltspunkt was Lautstärke/Stromverbrauch angeht.
    Bei mir ist es zwar eine EVGA mit 4GB geworden, aber dein Preis ist schon unschlagbar ...


    Dein Gehäuse ist ein echt schönes Teil, dagegen wirkt mein Bitfenix Prodigy geradezu riesig.
    Die Bauform und die Größe des Netzteils stelle ich mir aber auch einschränkend vor, eine GTX 980 zusammen mit einem i7 4770k wird das wohl zusammen nicht aushalten, die GTX 960 aber wahrscheinlich schon, oder ?


    Auf der Website des Gehäuseherstellers sieht man auch ein Setup mit Wakü, passt denn deine Noctua da rein ?
    Dazu ein Tipp zum Mainboard - achte beim Kauf darauf, das der Abstand vom Prozessorsockel zum PCIe-Slot groß genug ist um den Kühler auch korrekt eingebaut zu bekommen - bei meinem Asrock ist das genau nicht der Fall, so dass ich ihn quer einbauen musste. Bei meiner CPU ist der Kühler aber Nebensache, bei deinem aber nicht.


    Ausserdem würde ich noch berücksichtigen, ob dir hier für dein Board ein Ozmosis-Bios gebaut werden kann, der alle wichtigen Teile noch im BIOS unterbringen kann. Bei dem Wifi-Board wirst du wahrscheinlich eine neue Mini-Pci-karte brauchen, die kompatibel ist, von daher wäre das noch einzuplanen, oder gleich wegzulassen.

    Gerne, ich bin heute in "Dokumentierlaune", ausserdem sehe ich es genau wie Trainer.
    Speziell die gehäuften Clover-Fragen und die Möglichkeiten, die sich für NICHT-Gigabyte-Board User ergeben, wollte ich mal befriedigen.


    Ich plane heute noch einen "Clover-troubleshooting" Artikel und einen speziell zu meinem Build, der dann alles zusammenbringt und vielleicht als Startpunkt (vielleicht sogar Blaupause) für ähnliche Projekte dienen kann.

    Dies ist eine deutsche kommentierte Anleitung, in der ich versuche, das sehr gute aber englische Original [Google "RehabMan OS-X-Fake-PCI-ID“] zu erläutern.


    A. Kurzanleitung (ohne Erläuterung)


    B. Langanleitung


    C. Troubleshooting


    Sollte mal etwas schief laufen und man zu viel auf einmal gewollt haben, so kann man im Bootmenü von Clover unter (Optionen) auch händisch Einstellungen der config.plist (NUR für den diesen Bootvorgang) setzen oder entfernen.
    Ich dokumentiere dies genauer in einem extra Thema und verlinke es hier sobald es fertig ist.


    Darüber hinaus müsstet ihr einen Thread aufmachen, der sich auf diese Anleitung bezieht und folgendes enthält
    0. Eine vollständige Signatur eures Systems (Ist immer gut)
    1. Screenshots von Apple/Über diesen Mac/Systembericht (speziell Hardware, Hardware/LAN bzw. Netzwerk/WLAN)
    2. Screenshot eures EFI-Ordners (speziell EFI/CLOVER/kexts/10.XX)
    3. Eurer config.plist


    1-3 natürlich vor dem reboot anfertigen und extern speichern …


    ... UND bitte jetzt erst mit dem Durchführen beginnen ;-)

    Dies ist eine deutsche kommentierte Anleitung, welches das sehr gute aber englische Original https://github.com/toleda/audio_CloverALC ergänzt und um ein Bsp. erweitert.


    A. Kurzanleitung (ohne Erläuterung)


    B. Langanleitung


    C. Troubleshooting


    Macht dazu doch bitte einen neues Thema auf, welches sich auf diese Anleitung bezieht und folgendes enthält
    0. Eine vollständige Signatur eures Systems (Ist immer gut)
    1. der Terminalausgabe des obigen Scriptes (bitte vor dem Reboot EXTERN speichern)
    2. Screenshots von Apple/Über diesen Mac/Systembericht (speziell Hardware/Audio UND Hardware/PCI)
    3. Screenshot eures EFI-Ordners (speziell EFI/CLOVER/kexts/10.XX)
    4. optional der config.plist


    ... UND BITTE erst mit dem Durchführen beginnen, wenn es keine Fragen mehr gibt ;-)


    D. FAQ


    F: Ich bekomme folgende Fehlermeldung (Error: no IOReg/HDEF; BIOS/audio/disabled or ACPI problem)
    A: Dies bedeuted, das entweder die Soundkarte im BIOS disabled oder die DeviceID der Soundkarte (noch) nicht bekannt ist.
    Im ersten Fall muss die Soundkarte im BIOS aktiviert werden, im Zweiten in der clover config.plist (manuell der Eintrag ACPI/DSDT/Fixes/FixHDA_8000 auf true) oder via CloverConfigurator in der Section ACPI/FixHDA gesetzt werden.


    F: Das Script bricht ab, da bestimmte Vorraussetzungen nicht erfüllt sind.
    A: rootless=0 und CSRActiveConfig = 0x3 oder 0x67 in config.plist eintragen.
    rootless=0 ist seit 10.11 ohne Funktion wird aber vom Script geprüft, CSRActiveConfig ermöglicht dem Script ab 10.11 unsignierte Kexte in S/L/E und noch mehr zu schreiben. Anschließenden Reboot nicht vergessen :-)


    Edit 26.10.15 - jetzt mit direktem Link...
    Edit 27.10.15 - Erweiterung um rootless/SIP(CSR) und FAQ

    Moin, nein das "on-the-fly" patching ist nicht kompliziert, sondern bietet große Vorteile, da es eben nicht in S/L/E Apple Kexte ersetzt, sondern während des bootens Teile der Kette so verändert, das sie hinterher eben die Definitionen enthält, die zu deiner Device passen.


    Dies ist eine der "Funktionen" von Clover, die über einen reinen Bootloader weit hinausgehen.


    Vielleicht postet du einmal genau, was du bis zum Einbinden der WLAN-Karte alles in Clover konfiguriert hast.
    Vorher EFI_Partition zB über Clover-Configurator einbinden ;-)


    0. Hast du Clover mit der Option "Install for UEFI booting only" oder "Installiere Clover in der ESP" installiert ?
    1. Einstellungen in der config.plist
    2. hast du eine DSDT und/ODER SSDT in CLOVER/ACPI/patched ?
    3. Welche Treiber hast du in "Drivers64UEFI", bzw. "drivers64" eingebunden
    4. Welche Einträge stehen bei dir in CLOVER/kexts/10.10 ?


    Ich füge dir einmal einen Screenshot meines Systems ein, damit du besser siehst wo sich das alles befindet.


    Des Weiteren müsstest du einmal beschreiben, was du den von dem von mir geposteten Anweisungen auf der Toledo Seite ausgeführt hast und was das Ergebnis im Terminalfenster oder in der EFI Struktur/config.plist ergeben hat.


    Danach kommen wir weiter, ansonsten eher nicht. :-)


    EDit:
    Alternativ zur "on-the-fly" Methode, hast du das schon versucht ?

    ok, Lebenszeichen der Karte sind ja schon einmal positiv.


    Was bei der Sache wichtig ist, gerade wenn du mit Clover arbeitest, ist
    Entweder
    1. gepatchte Kexte in S/L/E unterzubringen
    Oder
    2. das on-the-fly patching von Clover zu nutzen.


    Nicht Beides mischen, da 2. darauf aufsetzt, das es einen "vanilla" kext in S/L/E gibt, in das Clover dann injizieren kann.


    Die Script von toleda sind eigentlich super simpel zu benutzen, ich selber nutze es um meine Soundkarte durch Clover patchen zu lassen.
    Wenn man einmal das Prinzip verstanden hat, wird klarer, warum man nicht mixen soll.


    Am Bsp. der Soundkarte beschrieben (dein WLAN-patch müsste ähnlich durchgeführt werden)
    - Mounten der EFi-Partition
    - Aufrufen des Scripts und Beantworten der Fragen
    - Nach Abschluss des Scripts kann in EFI/Clover/kexts/10.X eine neu kext liegen
    und/oder in der config.plist ein/zwei Einträge im Bereich "KextsToPatch" hinzugekommen sein.


    Das wars dann, auf diese Art überlebt man auch Systemupdates und es ist viel robuster als direkt in S/L/E rumzufummeln.

    Wenn ich nach deiner Karte google, dann springt mich die Seite von Toleda "toleda/wireless_half-mini" direkt an.
    Ich habe mir die Beschreibung nur kurz durchgelesen, in diesem Abschnitt ist eigentlich alles beschrieben.



    Vielleicht wäre es ein Versuch es damit zu probieren ?

    Ihr habt beide recht .... nur war das ja auch nicht mein Anliegen ;-)


    Meine derzeitiges System kann jetzt schon (W)QHD sprich 2560x1440@60Hz via DP + 1920x1080 via DVI oder HDMI ansteuern.


    Da aber die Anschaffung eines HD-Monitors eher ein Rückschritt wäre, möchte ist ein/zwei WEITERE WQHD oder 4K Displays anschließen, jeweils mit 60Hz.


    Dazu war die Alternativenbewertung gedacht.


    Unter Windows wäre das alles deutlich einfacher, da man dort via MST auch zwei WQHD Displays via daisy-chain ansprechen kann, sofern Monitor/Graka DP 1.2 unterstützen.
    Dies wäre unter Windows mit Variante 2 so möglich, mit OS X aber nicht - zumindest ist das mein jetziger Stand.


    OS X sieht MST von Haus aus nicht vor, da DP ja über Thunderbolt läuft (und dort nur ein Display pro Bus erlaubt ist).


    Von daher bleibt nur der Weg mit mehreren DP oder HDMI 2.0 Ports mit zB einer GTX 970.


    Oder sehe ich da etwas falsch ?



    Edit 2015-07-24
    Da die Frage entweder zu speziell, oder trivial war, habe ich die letzten Tage einen Selbstversuch unternommen :-)


    Das Ergebnis ... es funktioniert wie von mir gewünscht, allerdings war es natürlich nicht mit Einbau und Installation der Webdriver getan ...
    :party:


    Ich habe mir vorgenommen hierzu noch einen extra Beitrag zu verfassen, daher hier nur etwas über die Gründe und Besonderheiten der von mir ausgewählten Teile.


    Ich wollte ja NUR meine Bildschirmfläche vergrößern und bin daher bei einem Dell P2715Q 4K Monitor und einer EVGA GTX 960 gelandet.


    Die Grafikkarte habe ich ausgewählt, da sie 3 über DP Anschlüsse verfügt, man also auch drei 4K Monitore betreiben könnte.
    Da ich KEINE hohe Grafikleistung für Spiele brauchte, konnte ich gegenüber einer GTX 970 rund 100€ einsparen.
    Diese Summe ist dann in den 4K Monitor geflossen, den ich dem 1440p-Nachfolger meines U2713HM vorgezogen habe.


    Für die alltägliche Arbeit läuft der Monitor trotzdem nur auf den für 27 Zoll optimalen 1440p, welches KEINERLEI Einschränkung der Bildschärfe gegenüber meinem U2713HM erkennen lässt. Hier leistet OSX wirklich Erstaunliches in der Skalierung ...
    Sollte ich einmal mehr "Fläche" benötigen, so kann ich aber auf 3008x1692 oder 3840x2160 umschalten.


    Die Grafikkarte verbraucht im Bürobetrieb ca 20 Watt und arbeitet dabei unhörbar. Die Lüfter schalten sich erst ab 60 Grad überhaupt erst an und regeln sich dann schon fast wieder ab.


    Probleme gab nur dadurch, das ich ein bestehendes optimiertes System so abändern musste, das hinterher wieder alles passte.


    So wurde aus einem MacMini 6,2 ein iMac 13,1 (Facetime/iMessage hat es überlebt!), die DSDT musste um den HD4000 Ballast befreit werden und auch die SSDT musste neu generiert werden.
    Zudem war das System kurzfristig anfälliger gegen Kernelpanics, so das auch dies in Clover berücksichtigt werden musste und der Punkt NVIDIA Inject brachte zwar die EVGA in der Systemdefinition, aber dafür mit 0MB und nur ein Monitor war ansprechbar. (Letzteres wird bestimmt noch abgefangen, wenn die Clover Leute die richtige Systemdefinition (ähnlich wie für die EVGA 970 GTX) einpflegen).


    Dabei habe ich wieder noch mehr über Clover gelernt - das Ding ist mMn im Vergleich zu Ozmosis wie Linux vs OS X -Komfort vs Flexibilität.


    Ich hoffe dies hilft Anderen bei der Entscheidung, wenn es darum geht, das Passende auszuwählen.

    OK, ich habe das Ganze hier sehr gut erläutert gefunden, scheint ein ansonsten sehr emotionales Thema zu sein...


    Hier wird VRAM (Volatile Random Access Memory) und nicht NVRAM (Non-Volatile Random Access Memory) beschrieben, dies nur um Verwirrung vorzubeugen.


    Zu deinen Alternativen, die GTX960 hat "nur" eine 128bit Anbindung an das Speicherinterface, somit also deutlich weniger als die 224bit Anbindung der GTX970 für die 3,5GB Speicher, ist in der EVGA Ausführung mit 4GB Speicher aber 100€ günstiger. Test hier.


    Der Part der mich interessiert, ist die Anzahl an Monitoren in 1440p oder 4K @60Hz, die angesteuert werden können, ohne das ein Chromasubsampling durchgeführt wird. Da die EVGA GTX960 (04G-P4-3966-KR) das zu schaffen scheint, ist sie momentan mein Favorit.


    Da sämtliche Tests die ich finden konnte immer auf Windows basieren und zudem immer Spieltest sind, bleibt die Frage, was einem unter OSX eine GTX 980, bzw 970 mehr bringt als eine 960 ?


    Speziell für den Anwendungsbereich Photobearbeitung oder Videoschnitt.
    Zusatz - Speziell würde mich interessieren wie CUDA auf mehr Speicher anspricht, sprich ob die 3,5GB limit der 970 überhaupt zum tragen kommt.


    Kann dies Jemand (möglicherweise aus eigener Praxis) hier beantworten ?
    :danke:

    Was funktioniert denn nicht, das Erstellen des USB Sticks oder das booten in Parallels ?
    Ich verwende ja Fusion, dort muss man den USB Stick der VM direkt zuordnen (dh. auf nicht Nachfragen stellen ), dann die VM booten und direkt danach den USB-Stick mit der VM verbinden.
    Ggf. noch einmal einen Reset der VM, aber dann klappt es bei mir.


    Geht das nicht kann man ja auch von Yosemite "Upgraden" ... Bei einem CleanInstall von Yosemite sollte das vertretbar sein ...



    Edit
    Eine deutlich bessere und elegantere Lösung ohne USB Disk und Image Erstellung beschreibt Dave Parsons, wenn man nach "daveparsons VMware Fusion Guest" googled.
    Probiere ich gleich mal aus, ob das auch mit ELCap PB1 funktioniert und poste es dann hier ...
    Dave Parsons Artikel sind aber auch so lesenswert, zB wie man die für iMessage benötigten Parameter in Fusion "reinreicht" ...


    Edit2
    Auch das scheint nicht mehr direkt zu funktionieren, aber wozu weiss Google alles ...
    Hier ist der Patch damit das auch mit ElCap durchläuft.


    Aber alles nur für Fusion, vielleicht git es ja etwas ähnliches auch für Paralells ...

    OESIX
    nein da liegst du falsch,das hat sich gerade ab Lion geändert, sprich zu dem Zeitpunkt an dem OSX Server als APP zu installieren und keine eigenständiges Installation mehr ist.
    Wenn du nach kb.vmware 2005793 oder 1000131 suchst, findest du die entsprechenden Dokumente in denen definiert ist, unter welchen Umständen OS X virtualisiert werden darf.


    Kurz gesagt, laut Apple ist Grundlage hierfür eine Virtualisierung auf Apple Hardware - dies liegt in meinem Falle vor !


    Dadurch, das SL als DVD vertrieben wurde, sprich nicht mit einem Mac gebundelt verkauft wurde und alle weiteren Versionen von OSX nur Updates von SL sind, ergibt sich durch eine rechtliche Besonderheit in Deutschland die Legitimation, diese DVD auch auf Fremdhardware einzusetzen.
    Die Besonderheit ist, dass die Softwarevereinbarung, die einen Betrieb nur auf Macs vorsieht erst nach Öffnen der Verpackung (also nach dem Kauf) für den Kunden ersichtlich wird und damit unwirksam ist. Solange Apple dies juristisch nicht klären lässt, gilt dies wohl so.


    Daraus kann man natürlich auch die Ungültigkeit der Virtualisierung auf NUR Apple-Hardware ableiten, usw...
    UND das ist auch der Grund, warum von Jedem, der sich einen Hackintosh bauen möchte, erwartet wird, diese DVD zu erwerben.


    Dies ist zumindest die Erläuterung, welche ich bislang gehört habe. Ich will damit bitte auch keine Diskussion starten ...

    Moin, ich kann dir nur indirekt weiterhelfen, da ich genau den gleichen Effekt bei VMWare Fusion beobachte.
    Das Script, welches mir ein bootfähiges ISO-Image für Yosemite erzeugt, funktioniert bei El Capitan nicht, zumindest bootfähig ist es nicht.


    Ich habe mir damit beholfen, einen USB-Stick via DiskmakerX zu erstellen und diesen dann der VM zuzuweisen... oder eben den normalen Upgradeweg von 10.10.4 zu gehen


    Würde mich aber auch sehr interessieren, was sich hier bei El Capitan geändert hat ...


    Dies ist das Script, was ich verwendet habe ...