Könnte es sein, dass ....?

Ich geh mal sehr stark davon aus das dein Problem darinn lieg das dein verwendetes SMBIOS nicht mehr von macOS unterstützt wird & du daher auch nicht weiter updaten kannst.

Da hilft es entweder ein anderes noch unterstütztes SMBIOS zu nutzen oder den Board Seriel Check Patch zu verwenden. Mit dem die Prüfung der Borad Serial Nr abgeschaltet wird. Der Patch wird bei OCLP auch für echte Macs verwendet.

Nio82 Deine Vermutung ist in den meisten Fällen korrekt. Da der Kollege aber Sonoma 14.3.1 schon drauf hat, sollte das smbios auch noch für spätere Sonoma Updates passen. Daher auch hier wieder mein Tipp an BioMac , bei seinem Kumpel in der WG den RestrictEvents.kext und den AmfiPass.kext mal einzubinden und das bootarg revpatch=sbvmm hinzuzufügen, falls noch nicht vorhanden. Und dann, wenn Updates angezeigt werden, nich direkt auf Installieren klicken, sondern auswählen, was installiert werden soll. Kann nämlich passieren, dass wenn der Kollege ein passendes smbios benutzt, er dann auch Tahoe angeboten bekommt, was dann zu 100% in die Hose geht wenn er es installiert.

Der eigentliche Hintergrund ist komplexer als hier bisher geschildert.

Ab macOS 14.4 wird von Apple Update Servern gecheckt, ob man einen Mac bzw. ein SMBIOS eines Macs mit T2 Chip nutzt. Und dieser T2 Chip hat einen co-processor. Und wenn der nicht gefunden wird, dann gibt'ss keine Update-Benachrichtigungen.

Um das Problem auf Wintel Systemen – die diesen T2 chip natürlich nicht besitzen – zu umgehen, gibt es 2 Methoden:

1. Methode (besteht aus 2 Schritten!): Update-Servern vorgaukeltn, dass macOS in einer VM läuft

• Board-ID-check skip Booter Patch in config einbinden, um die Abfrage der Board-Id zu überspringen
• RestrictEvents.kext mit revpatch=sbvmm boot-arg hinzufügen. Das boot-arg triggert Kernel Patches, die die eine speielle baord-id aktivieren, die dem Update server mittetilt: hey, ich laufe in einer VM, ich kann nicht sagen, ob ein T2 chip vorhanden ist, das kann nur das Host-System. Bitte gib mir trotzdem updates"
• Das hat auf meinem Hackintosh zu Problemen beim Download von Apple Logic Pro aus dem App store geführt. Ich glaube, es hat die ARM version runtergeladen und die Installation ist dann jedes Mal gescheitert. Nach Umstellen auf iBridged (Methode 2) war das Problem weg.

2. Methode (neu): Präsenz von T2 Co-Prozessor simulieren.

• iBridged.kext verwenden. Simuliert das Vorhandensein des T2-Co-prozessors
• SIP und SecureBootModel müssen enabled sein
• Kein board-id skip verwenden
• Keine OCLP Root Patches anwenden

Mehr details: https://github.com/5T33Z0/OC-L…em_Updates/OTA_Updates.md

Ich denke diese Liste ist vollständig. https://support.apple.com/de-de/103265

BioMac grundsätzlich vielleicht auch nochmal zur Terminologie: T1 und T2 Chips gibt es nur und ausschließlich in Apple Hardware. Diese beiden sogn. Bridge Chips sind eine Eigenentwicklung von Apple und quasi ein Computer (ein sogn. System on a Chip) im Computer. Sowohl der T1 als auch der T2 besitzen ihr eigenes, von macOS unabhängiges, Betriebssystem und übernehmen diverse Aufgaben rund um die Systemsicherheit (Secure Enclave, FileVault2) sowie dazu passend Hardware nahe Funktionen (SSD Controller im Falle des T2, Sound Ausgabe, Hardware En- bzw. Decoding von Video Material, DRM usw.). Die etablierte Methode (und zumindest wenn man auf den OCLP angewiesen ist auch einzige) ist halt der Weg über RestrictEvents.kext und bootarg (revpatch=sbvmm)...

Löse Dich bitte auch von der Idee das Apple bewusst irgendwas gezielt gegen Hackintoshes tut denn das machen sie nicht in Fact kümmern die sich null Komma gar nicht um uns...

Quote from karacho

RestrictEvents.kext und den AmfiPass.kext mal einzubinden und das bootarg revpatch=sbvmm hinzuzufügen, falls noch nicht vorhanden.

Nur mal so...weil es noch 2 mal nach meinem Post erwähnt wurde.

Das Halteverbot kann nun alles und nichts zur Ursache haben ziemlich wahrscheinlich aber einfach eine unpassende config bzw. fehlender Skip BoardID Patch...