Hackintosh-Info.de stelle mal auf public seed um ;).
In der Efi finde ich nichts auffälliges.
Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenHackintosh-Info.de stelle mal auf public seed um ;).
In der Efi finde ich nichts auffälliges.
Danke, genau das war es..
für alle die nicht wissen wie man auf Public seed umstellt
Hackintosh-Info.de keine Ursache. Hatte gerade das selbe Problem
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!
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
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.
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:
ZitatThis 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!
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.
Mit dem Update von OC 0.6.5 auf 0.6.6 wurde Bootstrap entfernt und LauncherOption eingeführt. Bei diesem Update war es wichtig Bootstrap vorher zu deaktivieren:
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?
Alles anzeigenMit dem neuesten commit kann man Trim wieder ausschalten bei Platten die das nicht unterstützen, wenn man SetApfsTrimTimeout auf 0 stellt.
Funktioniert wunderbar.
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
Aber solche Bootzeiten hatte ich noch nie..........so schnell startete mein System noch nie.
Kann ich bestätigen, hab SetApfsTrimTimeout
auf 0 gesetzt und nun bootet der Hack mit aktivierten TRIM wieder schneller.
SetApfsTrimTimeout
auf 0 gesetzt und nun bootet der Hack mit aktivierten TRIM wieder schneller.
Also mit deaktiviertem TRIM