OpenCore Sammelthread (Hilfe und Diskussion)

  • Danke, genau das war es..:top:


    für alle die nicht wissen wie man auf Public seed umstellt


    1. Terminal öffnen
    2. sudo /System/Library/PrivateFrameworks/Seeding.framework/Versions/A/Resources/seedutil enroll PublicSeed
    3. Softwareupdate starten: softwareupdate -i -a
  • Moin zusammen!

    Ich habe jetzt mein System mal aktualisiert, die neue Hardware ist im Profil. Monterey läuft ohne weiteres mit dem neuen config.plist, bei Windows 11 (neuinstalliert) habe ich folgende Fehlermeldung im Gerätemanager:


    Eingebetteter, Microsoft ACPI-konformer Controller auf Intel(R) LPC Controller/eSPI Controller (Z690) - 7A84

    Das Gerät kann nicht gestartet werden. (Code 10)


    Wenn man ein wenig in den Eigenschaften rumklickt, findet man heraus dass Geräteinstanzpfad ACPI\PNP0C09\1 ist und unter dem BIOS-Gerätenamen \_SB.PC00.LPCB.H_EC zu finden.


    Verstehe ich es richtig dass auf meinen Mainboard ein PNP0C09 Controller verbaut ist, den man eigentlich im SSDT-EC-USBX deklarieren muss?

    Wenn ich nach der Anleitung zum SSDT-EC-USBX.dml von acidanthera gehe und das Teil vom Code mit External (_SB_.PCI00.LPCB.H_EC, DeviceObj) unkommentiere, bleibt Monterey beim booten kurz nach dem DSMOS has arrived hängen.


    Ansonsten booten Win11 und Monterey über OpenCore. Habe meine EFI mal mit angehängt, vielleicht mag jemand reinschauen und mir helfen.

    Danke!

    efi.zip

  • Ich bin grade von 074 auf 077 gesprungen aber einiges ist Strange :

    Bootmenü Picker zeigt kein NVRAM Reset an.(obwohl Aktiv in der Config)

    MacOS hat angeblich keine Plattform Info bekommen

    Ich kann im Bios unter Secureboot nicht Opencore.efi verifizieren obwohl es mit 074 ging ... ( EDIT: Das ging jetzt auf einmal , who knows why aber das erledigt)

    Im Anhang mal meine Config (achtung hab SN etc rausgenommen.)


    Edit :


    NVRAM reset konnte ich über OC74 aufm stick mal machen , dachte es liegt daran aber hat nix geholfen :(

    edit 02:


    Problem für PlattformInfo gefunden , musste bei UpdateSMBIOSMode von Create auf Custom gehen ( so wars auch in der alten Config.)

    jetzt wird alles angezeigt , das Problem das NVRAM Reset nicht angezeigt wird bleibt aber leider

    Dateien

    • config.plist

      (34,39 kB, 72 Mal heruntergeladen, zuletzt: )


    KEIN SUPPORT PER PN!

    julian2_pic.png

    Einmal editiert, zuletzt von julian91 ()

  • Lilu.kext is loaded at Kernel->Add[0], but DisableLinkeditJettison is not enabled at Kernel->Quirks!

    Kernel->Quirks->CustomSMBIOSGuid is enabled, but PlatformInfo->UpdateSMBIOSMode is not set to Custom!


    Du drückst aber schon die Space-Taste...wegen HideAuxiliary.

  • badbrain


    grade erst editiert ,


    Custom hatte ich selber grade rausgefunden nachdem ich nochmal mit der 074 gegengecheckt hatte ...

    punkt 1 verursacht welche Probleme ? weil das war bisher immer aus bei mir.


    KEIN SUPPORT PER PN!

    julian2_pic.png

  • Auch gerade editiert :):

    Du drückst aber schon die Space-Taste...wegen HideAuxiliary.

    Punkt 1 hat jetzt nichts mit dem NVRAM-Reset-Problem zu tun, aber:

    Zitat

    This option lets Lilu.kext, and possibly other kexts, function in macOS Big Sur at their best performance levels without requiring the keepsyms=1 boot argument.


  • Hallo an alle,

    könnte mir vielleicht kurz jemand sagen, wo in der config.plist (OC 7.7) ich einstellen kann, dass OC die Finger vom UEFI lässt? Ich möchte Windows nicht über OC booten und macOS nur noch als Notfall-System von einer zweiten Platte booten, falls mein M1 Mac ausfallen sollte. Leider überschreibt OC jedes Mal die Bootreihenfolge im UEFI, wenn ich von der Mac-Platte starte und ich muss ein NVRAM Reset machen, um den Windows Bootloader wieder zu defaulten. Ich suche mir schon seit Tagen nen Wolf, aber finde immer nur Lösungen für den umgekehrten Weg (also Windows über OC). Hab meine config mal angehängt. Vielen herzlichen Dank!

    Dateien

    • config.plist

      (23,39 kB, 128 Mal heruntergeladen, zuletzt: )

    Intel Core i5 11500, Gigabyte Z590i Vision D, 64GB RAM, XFX Radeon RX 6600, macOS 12 (OpenCore 0.7.7 / iMacPro SMBIOS)

    Original MacBook Air M1 (2020), MacBook Pro 15 (Late 2013)

  • Ich denke macinsane das es eher ein bios setting ist. Wenn du, wie du schreibst kein macOS als default boot haben möchtest, deaktiviere den Bootloader (UEFI XXX) einfach im Bios. Solltest du macOS benötigen starte einfach via f12 oder welche taste auch immer das in deinem BIOS ist (Manual Boot).


    Wenn ich es bei mir umstelle auf Windows Only, dann startet auch nur windows und die UEFI von OC sehe ich nie.

  • ozw00d  karacho Ja, danke. Disabled hat keinen Effekt. Es geht darum, dass OC die UEFI Einstellungen jedes Mal beim Booten überschreibt. Also sobald ich OC einmal starte, schmeißt es den Windows Bootloader raus und setzt sich selbst auf die eins.

    Intel Core i5 11500, Gigabyte Z590i Vision D, 64GB RAM, XFX Radeon RX 6600, macOS 12 (OpenCore 0.7.7 / iMacPro SMBIOS)

    Original MacBook Air M1 (2020), MacBook Pro 15 (Late 2013)

  • Danke badbrain , ist bekannt. Habe kein Update gemacht, OC 7 ist frisch auf den Hack gekommen, vorher war es ne reine Windows-Maschine.


    Hat niemand ne Idee? Es muss doch möglich sein, OC mitzuteilen, die Finger von der UEFI zu lassen?

    Intel Core i5 11500, Gigabyte Z590i Vision D, 64GB RAM, XFX Radeon RX 6600, macOS 12 (OpenCore 0.7.7 / iMacPro SMBIOS)

    Original MacBook Air M1 (2020), MacBook Pro 15 (Late 2013)

  • hackmac004


    Des is jetzt der Oberhammer...... Habe den Hacki seit Mai 2019.


    Aber solche Bootzeiten hatte ich noch nie..........so schnell startete mein System noch nie.


    Und Tim ist auch da. MEGA


    Danke dem Open-Core Team........ und dem Hackintosh Forum.....



    Schönes WE

  • DerTschnig Ja, find ich auch gut, dass es die Funktion wieder gibt. Trim wird dann aber nicht ausgeführt da komplett deaktiviert, was nach einer Weile zu Geschwindigkeitseinbußen führt, wenn viele Daten geschrieben und gelöscht wurden. Dann kann man den wert aber für einen boot auf -1 stellen und dann wird mal eben getrimmt.

    Hiermit kannst du die Trimzeiten im terminal auslesen.

    log show --debug --last boot --predicate "processID == 0" | grep spaceman

  • SetApfsTrimTimeout auf 0 gesetzt und nun bootet der Hack mit aktivierten TRIM wieder schneller.

    Also mit deaktiviertem TRIM

    • Apple Mac Studio | M1 Ultra | 64GB RAM | 1TB
    • PowerMac G5 | Dual 2GHz | 8GB RAM | GeForce 6800 Ultra DDL
    • AMD Ryzen 9 3950X | ASUS Strix X570-I Gaming | 64GB DDR4-3600 CL16 RAM | Corsair MP600 M.2 NVMe | Radeon RX 6900 XT | Phanteks Enthoo Evolv Shift | Custom Loop | MacOS 12 | OpenCore
      Ryzen MacPro | EFI | RadeonSensor | Aureal