Beiträge von griven

    Spannend wäre es in dem Zusammenhang auch mal die EFI zu sehen die hier verwendet wird (ich will auf ScanPolicy usw. hinaus es kann nämlich durchaus sein das hier was nicht passt). Die Vermutung das es an der Konfiguration von OC liegt liegt nämlich nahe denn Clover scheint ja die Recovery zu finden...

    Wichtig ist vielleicht auch zu verstehen das eine EFI aus dem Netz nicht zwingend auch mit einem Recovery Image funktioniert denn vielfach verwenden die Leute eben volle Installer (was auch deutlich einfacher ist) anstelle von dem Recovery Image...

    Das Utility erstellt eine Recovery und keinen vollen Installer demnach kann es sein (je nachdem wie Deine EFI aussieht) das diese im Standard ausgeblendet ist. Drück mal im Bootpicker die Space Taste anstelle von der 1 und schau ob Du dann im Menu die Recovery auswählen kannst. Wenn das nicht klappt ist beim erstellen des Sticks was schief gelaufen so, dass OC den nicht als gültiges Medium erkennt. In dem Fall würde ich dazu raten dem Dortania Guide zu folgen (https://dortania.github.io/Ope…html#making-the-installer) wobei Du Dich an den RUFUS Weg halten kannst auch dann wenn Du keinen Stick größer 8GB hast ;)

    Okay das ist ein Detail das erwähnenswert ist :)


    Ja es kann nicht nur an der AppleID liegen sondern in dem Fall wird genau das das Problem sein. Neue AppleID's oder solche die keine weiteren Geräte hinterlegt haben, keine Zahlungsmittel und auch sonst keine "Historie" brauchen erfahrungsgemäß 1-2 Wochen bis die I-Services mit denen zuverlässig funktionieren. Keine Ahnung warum Apple das so handhabt aber das war schon immer ein "Problem" es scheint fast so als müsse sich die ID erst ein gewisses Trustlevel verdienen bevor alle Dienste aktiviert werden (merkwürdigerweise nicht bei iOS Geräten der Fall wobei hier vielleicht die SIM auch eine Rolle spielt)...

    Wie gesagt eigentlich kein bekanntes Problem mit dem OCLP schon gerade bei dem Modell nicht weil hier ja eigentlich nur die WLAN Patches wirklich Anwendung finden der Rest ist ja nach wie vor mehr oder weniger nativ unterstützt. Hast du ggf. irgendwelche VPN/DNS/Firewall oder sonstigen Einstellungen aktiv die möglicherweise die Kommunikation mit den Diensten behindern? Die Dienste brauchen beide Kontakt zu diversen Apple Servern um korrekt aktiviert zu werden wenn in der Kette irgendwas fehlt kann es ggf. auch zu Problemen mit der Aktivierung der Dienste kommen...


    Um Fehler mit den Netzwerk/der WLAN Verbindung auszuschließen kannst Du testweise auch mal mittels LAN verbinden oder ggf. auch mal ein WLAN Netzwerk verwenden das nicht "versteckt" ist. Es ist halt auch immer zu bedenken das der Patcher den WLAN Stack und einige dazu gehörende App's auf einen älteren Stand zurückdreht es ist somit nicht ausgeschlossen das Sonderfälle wie eben Netze mit ausgeblendeter SSID zu unvorhergesehenem Verhalten führen. Am langen Ende hilft hier nur probieren (Ausschlussprinzip)...

    Eigentlich ist das kein OCLP spezifisches Problem bzw. ist nichts bekannt in diese Richtung...


    Die beiden I-Services sind aber dennoch berühmt/berüchtigt dafür sehr anfällig zu sein was sich dann in dem von Dir beschriebenen Verhalten äußert. Bei Hackintosh Maschinen ist hier oft ein nicht komplettes oder korruptes SMBIOS die Ursache bei einem Mac kann das aber eigentlich ausgeschlossen werden dennoch gibt es einige Stellschrauben an denen man drehen kann. In Deinem Fall würde ich zu allererst mal einen P-RAM/NVRAM reset machen (BootStick im OC dabei zur Hand haben da dabei möglicherweise der bestehende BootEintrag verloren geht) zudem stell bitte auch sicher das OC und das Patchset auf den aktuellsten Stand ist (Der Patcher in der neuesten Version und dann Build and Install OpenCore und ggf. auch die Patches nochmal neu ausführen). Wenn das alles nicht zum Erfolg führt könnte auch eine saubere Neuinstallation hilfreich sein (Vorsicht bei Migrationsassistenten das geht in 99% aller Fälle schief und führt zu allerhand merkwürdigem Verhalten, Ask me how I know)...

    Soweit ich herausfinden konnte hat die Kiste einen H57 Chipsatz wobei halt nicht ganz klar ist welche Devices da genau drin stecken (ggf. mal Hackintool laufen lassen und da mal in den Bereich PCI Devices gucken bzw. eben auch USB). Wenn man mal nach dem Modell explizit sucht haben sich an dem USB Thema schon diverse Leute die Zähne ausgebissen allerdings ohne Erfolg. Leider sind auch die Informationen die man findet widersprüchlich denn einmal ist die Rede von 2 USB 3.0 Ports und 2 USB 2 Ports dann wieder nur von USB2. Die DSDT sieht ziemlich nach "nur" USB2 aus wobei das nichts heißen muss denn es kann gut sein das da noch ein ASMEDIA oder Reneas Controller oder der gleichen werkelt und ggf. die USB Ports vom Intel Chipsatz gar nicht verwendet werden bzw. gar nicht nach außen geführt sind...

    Mit Portmappinmg musst Du Dich bei der Kiste eigentlich nicht befassen denn der Chipsatz kann ohnehin nur USB-2 und ein maximum von 14 Ports damit ist das Portlimit in Deinem Fall kein Thema...

    Ich denke eher das Dein Laptop nicht den Intel USB verwendet sondern der Hersteller da noch irgendwas anderes "reingezaubert" hat. Um welches Notebook geht es denn eigentlich genau (Hersteller, Bezeichnung) ?!?

    Öffnen kannst Du die .aml Dateien mit MacIASL (https://github.com/acidanthera/MaciASL/releases) unter macOS. In Deinem Fall heißen die USB Devices in der DSDT EHCI und EHC2. Ich habe Deine DSDT mal Fehlerbereinigt und die beiden Devices umbenannt in EH01 und EH02. Zieh die DSDT mal in den Ordner ACPI (EFI->OC->ACPI) und trage die DSDT in die confgi.plist im Bereich ACPI -> ADD ein (wenn Du die config mit OCAT bearbeitest dann öffne die config.plist vor dem Ablegen der DSDT in dem Ordner da OCAT den entsprechenden Eintrag in der config dann selbst erstellt).

    Dateien

    • DSDT.aml

      (40,54 kB, 26 Mal heruntergeladen, zuletzt: )

    Naja je nach Bios sind die durchaus auch mal anders benannt anstelle von EHC1 und EHC2 könnten die auch USB1 und USB2 heißen oder eben auch ganz anders. Um da genaueres sagen zu können müsste man in den ACPI Tabellen Satz von der Kiste gucken. Du kannst die Tabellen mit OC (HWINFO) extrahieren und hochladen wenn Du magst dann kann man sich mal ein Bild davon machen...

    Naja er bezieht sich hier auf die Stamps des OC Logs und das ist ja der Status nach dem Einschalten und vor dem Hochfahren...

    Wenn die Kiste am Internet hängt synchronisiert macOS ja die RTC beim boot und wenn das OS dann Arbeitsfähig ist geht auch die Uhr wieder richtig...

    Oder die Backup EFI ist halt auf einem alten Stand es kann nämlich auch sein das die einfach inzwischen so veraltet ist das die aktuelle installierte macOS Version damit nicht mehr startet...

    Ansonsten wäre es aber auch ein einfaches die "normale" EFI zu reparieren zumindest wen Windows auf der Maschine parallel läuft denn was hält Dich denn davon ab entweder den OpenUsbKbDxe.efi entweder in der config zu deaktivieren (UEFI -> Drivers) oder eben das File wieder an Ort und stelle zu legen?

    Wenn es rot leuchtet bedeutet das das der Eintrag in der config.plist zwar vorhanden ist das File unter dem angegebenen Pfad aber nicht. Überprüfe halt ob unter dem angegeben Pfad das Tool auch vorhanden ist...


    Was die Timestamps angeht scheint Dein Rechner im sleep seine Uhr zu verstellen (passiert bei macOS gerne wenn das nicht sauber implementiert ist). MacOS schreibt beim einleiten des Sleep einige Dinge in verschiedene Speicherbereiche des NVRAM's wobei es vorkommen kann das auf PC Hardware diese Bereiche reserviert sind und vom UEFI selbst genutzt werden. Im besten Fall geht dann halt die Uhr falsch im schlimmsten Fall stürzt die ganze Laube ab und meckert dann beim Neustart das die Bios Settings verloren gegangen sind oder deren Checksum nicht mehr stimmt...