Suchergebnisse

Wenn Du da eine Fenvi drin hast Arkturus warum dann BT über ein externes Dongle?

Prof. Rowan anbei meine EFI. Meine Kiste ist ein Coffee Lake (Intel(R) Core(TM) i7-8565U)...

Seher merkwürdig aber gut das es nun funktioniert Wenn Du Dir RestrictEvents.kext mit reinpackst und das Arg revpatch=sbvmm dann bekommst Du die Updates eigentlich auch so angeboten vorausgesetzt natürlich Du hast Deine AppleID für das Developer Program registriert (kann man ja kostenfrei einfach machen)...

Eher nicht weil die Patches ja nach wie vor unsigned sind sprich die Binaries die der Patcher einbringt (Apps, Deamons und Frameworks) werden bei aktiver SIP schlicht und ergreifend nicht mehr geladen...

BT ist ja auch unabhängig vom WLAN und benötigt unter Sonoma in aller Regel keine Patches...Das ganze betrifft ja "nur" das WLAN. Auf der anderen Seite klar die SIP abschalten ist ein gewisses Risiko aber ein, wie ich finde, kalkulierbares. Damit wirklich was am RootFS geändert werden kann muss es erstmal RW eingebunden werden und das geht unter macOS nunmal nicht ohne mithilfe des Users. Was ich damit sagen möchte? Ganz einfach wir Hackintosher sind ja in aller Regel keine einfachen, unbedarfte…

Das hängt eher damit zusammen das der Spoof die Kabylake Framebuffer verwendet und die wiederum sind Metal3 kompatibel Rein von der Generation her gehören die iGPU's der Skylake und die der Kabylake Prozessoren zur gleichen Generation (9. Generation) wobei die KabyLake gegenüber den Skylake iGPU's um einige Funktionen im Bereich der Hardware De/Encodierung (4K HVEC und DRM Funktionen) sowie den Support von Thunderbolt 3 erweitert wurden abgesehen davon sind beide aber identisch.

Update am Elitebook und am M1 ohne Probleme gelaufen

Phoenix85 wurde hier schon mehrfach geschrieben wie es geht hier nochmal kurz:1. RestrictEvents.kext hinzufügen2. BootArg revpatch=sbvmm hinzufügenDamit werden die OTA Updates trotz der vorgenommenen Änderungen für den WLAN Patch wieder angezeigt.

Nur um Missverständnissen vorzubeugen RestrictEvents.kext und das BootArg haben keinen Einfluss darauf welche Form von Update (Delta oder Full) angeboten wird die Kombi sorgt "nur" dafür das überhaupt was angeboten wird. Ähnlich wie die boot.efi beim Systemstart prüft auch der SoftwareUpdate Dienst zur Laufzeit ob der Rechner berechtigt ist bestimmte Updates zu empfangen (hier wird unter anderem die BoardID als Referenz benutzt) und bietet diese im Erfolgsfall dann über Systemsteuerung -> Allgem…

Wichtig ist auch das nach jeder Anwendung des Patchers direkt ein Reboot erfolgt und zwar noch bevor man irgendwas anderes im oder am System macht. Der Patcher erstellt nach erfolgreichem einbringen der Patches und neu erstellen der KernelCollection einen neuen Systemsnapshot und markiert diesen als aktiven Snapshot so, dass das System fortan davon bootet. Die gezeigte Meldung lässt darauf schließen das der Patcher zwar erfolgreich ausgeführt wurde der dann notwendige Reboot aber unterdrückt wur…

Install war auf meinen Maschinen (M1 MacBook und Das Elitebook) unkompliziert und ohne besondere Vorkommnisse.

Im Grunde ist das Vorgehen dasselbe wie in der Anleitung von MacGrummel beschrieben ozw00d nur halt ohne den Step eine Device und VendorID für die Karten faken zu müssen oder eine "spezielle" Version vom OCLP bauen zu müssen Wird also alles in allem einfacher nun...

Du nutzt aber schon den letzten Nigthly Build vom OCLP aus dem Sonoma-Development Repo? Weil dann sollte der Patcher eigentlich auch patchen wollen...

Die Installation der gestern verteilten ersten Beta von 14.1 ist auf meinen Systemen unauffällig verlaufen. OCLP tut für WiFI weiterhin klaglos seinen Dienst

Mir ist ein einigermaßen nerviges Detail/Bug in der 14.1 Beta 1 und 2 aufgefallen und zwar fragt die "Home App" reproduzierbar bei jedem Start ob es den Standort verwenden darf. Ich habe erst den Verdacht gehabt das es ggf. an der WLAN Patch Geschichte liegen könnte aber das Problem besteht auch am M1 MBP demnach kann der Patch ausgeschlossen werden. Hat einer von Euch ein ähnliches Verhalten beobachtet oder ggf. einen Kniff gefunden wie man das unterbinden kann?

Die ist kurz und knapp die Steuerzentrale für HomeKit Krams Arkturus

Meckert auf alle Fälle irgendwas in Richtung Lilu an bzw. bezieht sich die Meldung auf IntelGraphicsDVMTFixup.kext...Wenn Du den aktiv hast dann bitte deaktivieren oder alternativ sicherstellen das Lilu mindestens in Version 1.2.4 vorliegt (wobei der IntelGraphicsDVMTFixup bei einem iMacPro SMBIOS einigermaßen sinnfrei ist weil iGPU ja eh deaktiviert)...

DVMTGraphicsFixup Dingenskirchen ist Teil von WhatEverGreen wenn ich das richtig verstehe/im Blick habe...Ich bin im Büro kann hier also leider nicht in die EFI gucken aber stell bitte sicher das alles auf dem letzten (ggf. nightly Build) Stand ist denn hier scheint was in dem Bereich nicht zusammen zu passen bzw. nicht zu den Anforderungen vom Patcher zu passen (ggf. mal testweise die Kexte vom OCLP Github laden und verwenden?)....

Update auf die Beta2 hat hier am Elitebook im übrigen ohne Probleme geklappt (RestrictEvents nebst seiner BoorArgs sind aktiv) inkl. der anschließenden Installation von OCLP um die Fenvi wieder an den Start zu bringen.

Hat inzwischen den AmfiPass mal jemand ausserhalb des OCLP Repositories gesichtet? Ich kenne den bisher nur als Teil von OCLP...Ansonsten Install auch hier ohne Probleme auf dem Elitebook