Posts by griven

  • Dualboot-Problem Windows Bluescreen "Kernel_Security_check_Failure"

    Dann muss an der Stelle logischerweise irgendwas ganz anderes im argen liegen denn wie gesagt wenn Du über das Bios Bootmenü auswählst ist nichts von den Hackintosh spezifischen Dingen aktiv (wie auch bzw. wo soll es auch herkommen). Einen Zusammenhang mit dem NVRAM kann es ebenfalls nicht geben denn der hätte ebenfalls bestand wenn die anderen Platten ausgebaut sind (der NVRAM ist ja nicht Plattenspezifisch). Zusammenfassend das Problem hat eher nichts mit OpenCore oder den vorhandenen macOS Installationen zu tun sondern ist eher ein Windows spezifisches Problem das nur zufällig in dem Kontext auftaucht. Ich würde an der Stelle also mal da ansetzen und vielleicht für den ersten Aufschlage den SATA Anschluss an dem die Windows Platte hängt tauschen denn wenn die allein läuft aber nicht mit anderen Platten zusammen läßt sich der Fehler doch eigentlich in die Richtung eingrenzen. Die Windows Platte demnach an SATA-0 (ersten Anschluss) und die anderen Platten dann dahinter wäre in dem Fall mein erster Schritt.

  • Dualboot-Problem Windows Bluescreen "Kernel_Security_check_Failure"

    Es kann ja eigentlich schwerlich mit OC zusammenhängen wenn das Problem auch auftritt wenn man Windows an OC vorbei über das Startmenü vom BIOS aus starten will würde ich meinen. Mir scheint es eher so zu sein das auf einer der EFI Partitionen der anderen Platten noch ein Stummel der Windows UEFI Installation vorhanden ist der gestartet werden soll wenn übers UEFI Menu gewählt wird was dann natürlich nicht gehen kann oder was denkt Ihr? Ich meine sonst würde es ja auch nicht funktionieren wenn alle bis auf die Windows Platte raus sind?

  • Dualboot-Problem Windows Bluescreen "Kernel_Security_check_Failure"

    Naja wenn das Problem auch auftritt wenn Du über die UEFI/BIOS Boot Auswahl gehst kann es schwerlich irgendwas mit OpenCore oder Co zu tun haben denn der wird ja in dem Fall gar nicht erst geladen ;) Wenn Windows allerdings im MBR Modus installiert ist dann wird es zumindest mal nicht über UEFI starten wobei dann aber eigentlich auch kein ACPI Error erscheinen sollte wobei bei den Windows Fehlermeldungen weiß man nie...


    In Deinem Bios BootMenu müssten sich bei einer MBR Installation ggf. zwei Einträge finden lassen vermutlich einmal mit dem Zusatz UEFI und einmal halt nur der Name des Datenträgers auf dem Windows installiert ist (irgendwas mit kryptisches halt) ich denke mal wenn Du den Eintrag ohne UEFI auswählst wird Windows auch dann starten wenn die anderen Platten zusätzlich im System sind. Grundsätzlich sollte man bei einem UEFI Motherboard aber auch kein MBR Windows mehr fahren es gibt da absolut ganz und gar keinen Grund mehr für. Ein MBR Windows lässt sich mit Bordmitteln auf GPT konvertieren (UEFI) sollte man schon machen...

  • Open Core Windows Blue Screen

    Grundsätzlich übernimmt OpenCore alle Änderungen die an den ACPI Tabellen vorgenommen werden für alle Betriebssysteme die über OpenCore gestartet werden und damit ist eigentlich schon die Erklärung für den BlueScreen von Windows gefunden. Viele Tutorials, die so im Netz rumschwirren, sind leider oftmals ein gutes Beispiel dafür wie man ACPI Patches nicht macht. Schaut man mal in Deinen EFI Ordner finden sich dort zwei ACPI Dateien einmal eine DSDT.aml und eine SSDT-EC0.aml bei der DSDT kann ich natürlich nicht sagen was daran verändert wurde hier kenne ich das Original nicht daher lassen wir die mal außen vor (vermutlich wird sie eh nicht gebraucht) aber anhand der SSDT-EC0.aml kann man schön aufzeigen wie man so etwas so gestalten kann das es sich nur auf macOS auswirkt und alle anderen Betriebssysteme ignoriert, was es im vorliegenden Fall auch tut. Die von Dir eingesetzte Version sieht wie folgt aus:


    auffällig dabei ist der folgende Block:

    Code
    1. If (_OSI ("Darwin"))
    2. {
    3. Return (Zero)
    4. }
    5. Else
    6. {
    7. Return (0x0F)
    8. }

    Die IF Bedingung unterscheidet in dem Fall ob das Betriebssystem macOS (Darwin) ist oder nicht und im Falle von macOS gibt die Methode den Wert NULL zurück andernfalls den Wert 0x0F wobei der "andernfalls" Wert dem entspricht was auch zurückgegeben würde wenn es die SSDT nicht geben würde. Das Beispiel zeigt wie man ACPI Patches so anfertigt das sie sich nur auf ein bestimmtes Betriebssystem auswirken. Wie wir sehen entspricht die SSDT-EC0.aml den notwendigen Standards und kann daher nicht der Grund für den ACPI Fehler sein den Windows anmeckert. Das Problem ist also irgendwo in der DSDT zu suchen und hier ist es leider nahezu unmöglich einen Diagnose zu stellen ohne die originale DSDT zu kennen. Wie auch immer ich würde an Deiner Stelle die DSDT erstmal aus dem Rennen nehmen und gucken ob Windows damit zufrieden ist und falls das der Fall ist (ich gehe davon aus) dann würde ich im nächsten Step gucken ob auch macOS ohne die DSDT auskommt und wenn auch das der Fall sein sollte (ehrlich gesagt gehe ich auch davon aus) dann kannst Du Dich langsam ran tasten und ausprobieren was unter macOS mit der DSDT funktioniert hat und ohne nicht mehr und gezielt diese Dinge adressieren. Heute braucht man eigentlich so gut wie gar nicht mehr an der DSDT rum schrauben weil vieles von dem was man da mal geregelt hat sich viel eleganter anderweitig regeln lässt (Stichwort IOREG bzw. Lilu.kext und Co.)...

  • WWDC 2020 - ARM Macs?

    Und gerade hier haben wir doch den springenden Punkt die "Standards" sind unter macOS doch längst definiert und werden benutzt und daran wird sich doch auch in Zukunft nichts ändern. Den Entwicklern kann es schlicht und ergreifend egal sein ob ein ARM SoC oder ein Intel Core Prozessor unter der Haube werkelt denn die coden gegen die vom OS bereitgestellten API's und Frameworks und an denen wird sich durch den Wechsel unter der Haube zunächst nichts signifikantes ändern. MacOS Big Sur macht es doch schon vor die Frameworks und API's die in BigSur enthalten sind bedienen schon jetzt gleichermaßen X86_64 und AppleSilicon (defacto tun sie das schon eine ganze Weile da iOS, iPadOS und macOS auf ein und der selben Plattform basieren und sich daher seit jeher schon einen ganzen Haufen API's und Frameworks teilen). Ich habe den Eindruck das hier Probleme diskutiert werden die de facto gar nicht vorhanden sind denn Hardware nah gibt es bei macOS und Apple schon sehr lange nicht mehr...

  • WWDC 2020 - ARM Macs?

    Was mit bei der ganzen Debatte um ARM Macs oder nicht ARM Macs deutlich zu kurz kommt ist eine ganzheitliche Betrachtung der Sache. Wenn ich das richtig sehe dreht sich doch die Debatte im Moment darum ob ein ARM Prozessor es leistungstechnisch mit einem X86_64 aufnehmen kann oder nicht und ob sich damit ein macPro oder ähnliches Konstrukt stricken lässt oder nicht richtig?


    In meinen Augen ist das zu kurz gegriffen denn Apple Silicon ist ja nicht nur ein ARM Prozessor die Dinger sind ein SoC und somit genau genommen schon gar nicht mit einem X86_64 Prozessor zu vergleichen. Rein von der Rechenleistung mag das vielleicht noch vergleichbar sein aber das war es dann auch schon. Ihr lasst bei Eurer Betrachtung ein kleines aber entscheidendes Detail komplett ausser acht und das ist die Tatsache das der Entwickler des OS und damit auch der API's und Frameworks auf die eventuelle Anwendersoftware aufsetzt (ist im übrigen auch jetzt schon der Fall bsp. Metal, CoreAudio, AppleGVAFramework etc.) in dem Fall dann auch die Entwicklung der Hardware selbst in Händen hält. Wo sich im Moment das Design der Frameworks, API's und Co. daran orientieren muß was mit der am Markt erhältlichen Hardware (CPU, GPU und Co.) möglich und machbar ist sieht das in Zukunft komplett anders aus. Apple ist künftig in der Lage seine Chips so zu designen das sie optimal an die Anforderungen der Software angepasst sind. Es gibt überhaupt keinen Grund zu glauben das das was jetzt schon für iPhone und iPad praktikabel ist und gut funktioniert nicht auch in einem größeren Maßstab gut funktionieren wird.


    Bestimmte Aufgaben lassen sich eben mit darauf spezialisierten Schaltkreisen sehr viel effizienter erledigen als das mit einer CPU je gehen kann und im Grunde ist ja auch das in Teilen schon jetzt der Fall (QuickSync, Hardware De- und Encoding via GPU). Im Unterschied zum Status Quo hat Apple es aber zukünftig selbst in der Hand zu entscheiden für welche Dinge "Spezialisten" eingesetzt werden und was weiterhin flexibel von der CPU bedient werden soll/muss. Für den Anwender aber auch für die Software Entwickler ist es am langen Ende vollkommen irrelevant ob die Programmfunktionen von der CPU/GPU abgearbeitet werden oder ob sich ein darauf spezialisierter Schaltkreis darum kümmert zumindest solange sich das Framework/die API darum kümmert die Befehle an die richtigen Empfänger innerhalb des SoC zu schicken. Klar das Ganze geht zu lasten der Flexibilität aber auch das ist sowohl aus Sicht der Anwender als auch aus Sicht der Entwickler nicht relevant solange sich alle gewünschten Funktionen so realisieren lassen das am Ende eine akzeptable Geschwindigkeit erzielt wird.

  • Open Core Update

    Und vielleicht als allgemeine Umstieg/Updatehilfe...

    Immer die mitgelieferte Sample.plist mit den Werten aus der bestehenden config.plist befüllen und nicht umgekehrt auf die Weise vermeidet man die oben gezeigten Probleme.


    Punkte die in der alten config.plist enthalten sind in der neuen aber nicht (mehr) können ignoriert werden (sind nicht mehr vorhanden in OpenCore). Punkte die in der neuen enthalten sind und in der alten fehlen sind entweder wirklich neu (Voreinstellung belassen es sei denn man weiß wozu es gut ist und benötigt eine andere Funktionalität) oder umbenannte, alte, Optionen (im Zweifel mal in die Release Notes gucken und dann ggf. die vorherige Einstellung übernehmen).

    Generell ist es sinnvoll ein Update von OC immer auf einem separaten Medium zu testen dazu am besten einen USB Stick vorhalten auf den die komplette neue EFI aus dem OC Paket kopiert wird (Ordner EFI aus dem zip) und entsprechend an die eigenen Gegebenheiten angepasst wird. So lange mit dem Stick konfigurieren und starten bis das System sauber durchbootet und anschließend dann die EFI auf der Platte durch die auf dem Stick ersetzen.

  • Clover Install Backup-Directory

    Die werden auch weiterhin in den Root geschrieben hierzu bindet das Installationspaket von Clover das Root FS mittelssudo mount -uw / lesend/schreibend ein (Eingabe von Kennwort notwendig). Das ganze funktioniert allerdings nur wenn die SIP deaktiviert ist. Sollte sich das RootFS nicht lesend/schreibend einbinden lassen verweigert der Installer von Clover schlicht und ergreifend den Dienst.

  • [Sammelthread] MacOS BigSur 11.0 DEV-Beta Erfahrungen

    Ich denke mal das Absterben im 3 Installationsschritt (letzte Phase der Installation) ist nach wie vor der Tatsache geschuldet das bis dato keiner der bekannten Loader mit den KernelCollections richtig umgehen kann bzw. noch kein Weg gefunden ist denen unsere Kexte unterzujubeln. Die ersten beiden Steps der Installation (Boot in den Installer -> Kopieren der Daten auf das Volume, starten vom Volume und erster Schritt der eigentlichen Installation) kommen ohne FakeSMC/VirtualSMC aus der letzte Step benötigt die SMC Emulation jedoch. In der Installation gibt es noch keinen Prelinked Kernel der verwendet werden könnte und somit läuft die aktuelle Lösung zur KextInjection ins Leere. Fazit keine KextInjection, kein VirtualSMC bzw. FakeSMC und damit eben auch keine erfolgreiche Installation bis zum Ende.

  • [Sammelthread] MacOS BigSur 11.0 DEV-Beta Erfahrungen

    hackmac004 Du musst im Installer die RawDisk (wenn Du die bigsur gennant hast dann diese) schon als Ziel für die Installation von macOS auswählen von sich aus macht der Installer das nämlich nicht. Wenn Du nach meiner Anleitung vorgegangen bist dann hast DU 2 Volumes in der VM einmal die virtuelle Festplatte die VMWare generell erstellt und die in dem Fall Macintosh HD heißt und eben Deine Rawdisk wenn Du nichts weiter wählst installiert der Installer auf die Macintosh HD und Deine Rawdisk bleibt leer. In dem Fall muss Du wohl oder übel noch mal neu installieren :trost:

  • [Sammelthread] MacOS BigSur 11.0 DEV-Beta Erfahrungen

    schmalen nutzt Du in Deinem Rechner eine WLAN Karte von Broadcom wenn ja füg mal den AirportBRCMFixup.kext mit ein hört sich komisch an könnte aber helfen...


    Ich hatte das exakt gleiche Problem mit Big Sur bei meinem Desktop der Rechner startet (verbose boot) und alles sieht gut an dem Punkt an dem Grafiktreiber geladen werden gibt es dann ein paar violette Linien im oberen Bildschirmdrittel und irgendwann später dann einen Blackscreen den mein Monitor alsbald dann mit "Kein Signal" quittiert und sich schlafen legt. Das Verhalten kann ich zuverlässig reproduzieren indem ich den AirportBRCMFixup.kext entferne ist der Kext vorhanden bootet Big Sur sauber durch. Es hat eine Weile gedauert bis ich auf den Zusammenhang gekommen bin und ehrlich gesagt war das auch mehr ein Griff ins Blaue. Meine ersten Gedanken waren auch WEG Thema aber nachdem einige der letzten Meldungen die man sehen kann bevor der Screen schwarz wird sich auf den Airport beziehen habe ich gedacht probiert mal aus schaden kann es nicht und siehe da es war die Lösung. Du kannst es ja auch mal testen und dann Feedback geben ob es bei Dir was bringt. Warum bzw. was dieses Verhalten genau auslöst habe ich allerdings noch nicht ergründen können...

  • [Sammelthread] MacOS BigSur 11.0 DEV-Beta Erfahrungen

    chmeseb man braucht dazu keinen echten Mac es geht genau so gut auch mit einer VM (VMWare oder ähnliche) wichtig ist nur das man für BigSur (im Moment) eine eigene Platte einplant und diese als Raw Disk in die VM einbindet. Folgende Dinge braucht es:


    • VMWare (ich habe VMWare Fusion verwendet es geht aber analog auch mit Parallels, vBox und co)
    • Einen macOS Big Sur Installer Stick (erstellt im Terminal mit dem CreateInstallMedia Command)
    • Eine im HFS+/GUID Format formatierte HDD oder SSD
    • Einen USB Stick. mit OpenCore/Clover um das installierte System anschließend zu booten

    Um zu starten erstellt man zunächst eine neue benutzerdefinierte virtuelle Maschine für macOS 10.15:


    Da ich mich hier auf VMWare Fusion beziehe geht es nun im Terminal weiter denn jetzt müssen wir VMWare sagen welche unserer Festplatten wir der virtuellen Maschine als Rawdisk zuordnen möchten (die VM darf noch nicht gestartet sein wenn sie gestartet sein sollte bitte herunterfahren). Im Terminal geben wir zunächst einmal folgenden Befehl ein diskutil list um uns einen Überblick über die vorhandenen Laufwerke zu verschaffen und um die Disk Nummer unseres gewünschten Laufwerks zu ermitteln.


    Für mein Beispiel muss Disk4 (meine Datenplatte) herhalten da ich BigSur schon laufen habe und den Spaß eigentlich nicht wieder von vorne durchspielen möchte ;) Einmal die Disk Nummer ermittelt geht es nun darum ein VDMK für die raw Disk zu erstellen und diese anschließend in die VM einzubinden. Unter VMWare Fusion gibt es dazu den Befehl vmware-rawdiskCreator der sich innerhalb der VMWare Fusion.app befindet. mit dem Befehl /Applications/VMware\ Fusion.app/Contents/Library/vmware-rawdiskCreator print /dev/disk# lässt sich eine Übersicht der Partitionen auf der zuvor im Diskutil ermittelten Platte anzeigen (das # wird durch die Nummer ersetzt die ermittelt wurde in meinem Fall also Nummer 4):

    Um nun das VDMK File für die Disk tatsächlich zu erstellen geht es mit dem Befehl /Applications/VMware\ Fusion.app/Contents/Library/vmware-rawdiskCreator create /dev/disk# <partNums> <virtDiskPath> sata weiter hierbei wird <partNums> und <virtDiskPath> jeweils an die eigenen Gegebenheiten angepasst.

    • <partNums> muss ersetzt werden durch eine Komma getrennte Liste der zu verwendenden Partitionen (1,2,3..) oder durch fullDevice wenn die gesamte Platte verwendet werden soll (wir benutzen fullDevice).
    • <virtDiskPath> wird ersetzt Durch den Pfad zu Deiner vorher erstellten virtuellen Maschine zum Beispiel so: ~/Virtual\ Machines.localized/BigSur.vmwarevm/rawDiskFile

    Der Komplette Befehl sähe dann zum Beispiel wie folgt aus:

    /Applications/VMware\ Fusion.app/Contents/Library/vmware-rawdiskCreator create /dev/disk4 fullDevice ~/Virtual\ Machines.localized/BigSur.vmwarevm/rawDiskFile sata wenn alles geklappt hat gibt es nun innerhalb unserer erstellten VM eine Datei Namens rawDiskFile.vmdk welches wir zu guter Letzt jetzt noch in das *.vmx File unserer VM eintragen müssen. Um das alles zu sehen/zu prüfen navigieren wir im Finder auf unseren Benutzer Ordner (im Finder Gehe zu Ordner wählen und ~ eingeben als Ziel. Es öffnet sich der Benutzerordner:

    in dem sich ein Ordner Virtuelle Maschinen befindet den wir dann ebenfalls öffnen um uns im Anschluss den Inhalt unserer VM anzeigen zu lassen (Paketinhalt anzeigen im Kontext Menu):



    nun ist es schon fast geschafft denn was jetzt noch zu tun ist ist das *.vmx File mit dem Texteditor zu öffnen und die so eben erstellte Rawdisk dort einzufügen. Zum einfügen suchen wir im Texteditor den Teil indem es um die SATA Devices der VM geht

    und ergänzen direkt unter dem letzten Device folgende Zeilen:

    Code
    1. sata0:X.present = "TRUE"
    2. sata0:X.fileName = "rawDiskFile.vmdk"
    3. sata0:x.deviceType = "rawDisk"
    4. suspend.disabled = "TRUE"

    wobei das x durch eine Zahl zu ersetzten ist die eine Nummer höher ist als die des letzten Device in dem File (in meinem Fall die Nr. 2). Ist das erledigt wird das File gespeichert und wir sind bereit zur Installation. Der USB Stick mit dem Installer wird der VM zugewiesen und die VM gestartet sie bootet daraufhin automatisch in den macOS Installer von dem Punkt an kann dann die macOS Installation wie gewohnt durchgeführt werden. Am Ende habt Ihr dann eine SSD/HDD mit einer installierten BigSur Kopie die sich dann im Hack mit OpenCore oder Clover booten lässt.