Beiträge von griven

    Bob-Schmu Du musst Dich nicht rechtfertigen und Du musst hier auch nicht nochmal "Nachtreten" es ist wie es ist und gut...


    Es gibt halt beide Lager und ein jeder ist von seinem Lager überzeugt das war immer so und das wird immer so sein. In meinen Augen ist es wichtig ist das man den Wunsch des Fragesteller respektiert und möglichst zielgerichtet hilft bzw. sich zurückhält wenn man sich mit der gewünschten Lösung nicht auskennt oder nicht identifiziert. Natürlich kann man Alternativen aufzeigen oder, wo sinnvoll und nur da, doch zu was anderem raten generell sollte das aber niemals zu Glaubenskriegen führen und Diskussionen auslösen die nichts (mehr) mit der Fragestellung des Hilfesuchenden zu tun haben. Diese Diskussionen führen am ende nämlich nur zu Threads die niemanden mehr interessieren und die nur noch am Rande was mit der eigentlichen Fragestellung zu tun haben...


    Also, wie schon gesagt, sachlich bleiben das Anliegen des Fragestellers respektieren und im Auge behalten dann klappt es auch mit dem friedlichen Miteinander im Thread und im Forum...

    Leute bitte sachlich bleiben und nicht wieder eine Clover vs. OC Grundsatzdiskussion vom Zaun brechen, danke.


    Es gab diese Diskussionen in der Vergangenheit zur Genüge und am langen Ende führt das alles zu nichts anderem als bösem Blut und das muss echt nicht sein. Wenn jemand Clover verwenden möchte ist das ein legitimes Anliegen. Möglicherweise hat sich der Fragesteller dabei etwas gedacht oder es ist halt seine persönliche Präferenz und das sollte man einfach aktzeptieren. Wenn man an der Stelle dann nicht helfen kann oder möchte dann lässt man es einfach und versucht nicht den Fragesteller zu OpenCore zu überreden. Die Pro und Cons beider Loader sind inzwischen hinreichend diskutiert worden das muss nicht weiterhin an jeder Ecke passieren an der jemand nach Clover fragt. Danke Euch für Euer Verständnis in der Sache.

    Soweit ich das in Deiner config.plist sehen kann hast Du kein USBPortMapping gemacht sondern verlässt Dich nach wie vor auf USBInjectAll und das dürfte dann auch schon Dein Problem sein. Du solltest wirklich dringend eine USBPortMap erstellen und USBInjectAll und den XHCI Portlimit Quirk deaktivieren beides ist seit einiger Zeit "deprected" und funktioniert daher nicht mehr richtig (und unter 14.4 offenbar auch gar nicht mehr).

    Nein ist nicht identisch Arkturus.


    Das Safari Plugin ist vergleichbar mit Adblock+ oder ähnlichem die App Version geht weit darüber hinaus und filtert schon auf Netzwerkebene. Die App Version ist deutlich effektiver ist als das Plugin und ist nicht auf einen bestimmten Browser beschränkt sondern funktioniert überall (auch in Apps zum Beispiel) anders als das Plugin ist sie allerdings kostenpflichtig. Ich nutze das jetzt schon seit Jahren und meine das die Lizenz damals auch gar nicht so teuer war (jedenfalls deutlich günstiger als die 72€ die sie jetzt dafür aufrufen denn zu dem Preis hätte ich das nicht gekauft). Es gibt die App auch in einer Trial Version ausprobieren lohnt sich an der Stelle würde ich meinen :)

    Schon richtig und sinnvoll MPC561 allerdings filtert das "nur" auf DNS Ebene. Das schöne an der App Lösung ist das hier auch Werbung gefiltert wird die von der selben Domain ausgeliefert wird wie der Content. AdGuard for Mac ist (noch?) sehr effektiv zum Beispiel im Filtern von Werbung in YouTube was das Tool für mich sehr wertvoll macht. Wenn es eine zentrale Lösung gibt die das ebenfalls bewerkstelligt (AdGuard Home habe ich bereits getestet ebenfalls als Docker Container) dann hätte ich gar keinen Schmerz damit umzusteigen.

    Hier auch sauber gelaufen allerdings gibt es eine "Merkwürdigkeit"...

    Ich nutze AdGuard for Mac und während AdGuard auf dem Elitebook auch weiterhin klaglos funktioniert hat es auf dem M1 MacBook mit der aktuellen Beta den Dienst eingestellt. Der Support von AdGuard schreibt man sei an dem Problem dran und schiebt den Fehler selbstverständlich auf Apple...


    Generell klar es kann sein das Dinge in einem Beta Zyklus nicht (mehr) funktionieren allerdings finde ich es einigermaßen merkwürdig warum nur Apple Silicon betroffen ist aber Intel nicht...


    Für den Moment also am M1 Rollback auf die Beta2 *seufz*

    Nur mal so am Rande Dein Probook und mein Elitebook sind aus technischer Sicht quasi direkte Zwillinge und unterscheiden sich ja eigentlich nur in Nuancen von einander. Ich könnte mir vorstellen das das Probook ziemlich sicher mit der EFI von meinem Elitebook (dat rennt aktuell auf Sonoma 14.5 Beta 2) laufen würde. Also wenn da Bedarf besteht das mal zu testen gerne melden dann werfe ich die ins Rennen. Mache ich aber nicht ungefragt weil ich will apfel-baum bzw. Euch da jetzt auch nicht reinfunken...

    Ich hätte ja mal in Deine EFI geschaut allerdings kann ich die config.plist nicht öffnen (beschädigt, die Editoren sagen das .plist File sei invalid)...


    Generell aber der POST Error den Du siehst hat nichts mit dem AKKU zu tun sondern entsteht durch einen CMOS Reset der in Folge der Panik in macOS passiert. Der Grund dafür ist im Normalfall das hier von macOS Speicherbereiche im NVRAM überschrieben werden die die Firmware des Geräts für andere Dinge benötigt in der Folge stellt das UEFI dann fest das der NVRAM korrumpiert wurde und schmeißt den POST Fehler. Ganz ähnliche Probleme hatte ich auch am EliteBook hier hat der RTCMemoryFixup.kext geholfen. Beim Elitebook muss der Bereich 30-32 mittel rtcfx_exclude Bootarg ausgeklammert werden um diese Fehler zu beheben. Beim Probook kann das ein anderer Bereich sein allerdings wäre es auch Denkbar das der Bereich identisch ist einfach weil beide Geräte doch recht nah miteinander verwandt sind...

    Das wird so sein ist ja eine Kette die da greift...

    Also SecureBoot im Bios -> Fault in OC -> SecureBoot macOS wenn da ein Glied fehlt ist es ja nicht mehr sicher im Sinne von SecureBoot...


    Der Gedanke ist halt der Zeitpunkt an dem das Reboot Verhalten auftritt. Das Ganze passiert in der letzten Phase der Installation also eigentlich an der Stelle an der der Snapshot von dem gestartet werden soll sein Siegel erhalten soll. Wenn da jetzt ein SMBIOS mit T2 Chip und aktivem SecureBootModel im Einsatz ist könnte es zumindest theoretisch sein das das scheitert weil der zur Versieglung des Snapshot nötige T2 Chip nicht präsent ist...

    julian91 falls nicht schon probiert SecureBootModel auf Disabled und NVRAM Reset machen. Das SecureBootModel scheint hier essentiell zu sein nach allem was ich bisher sehe. Alternativ SMBIOS vom 2019er iMac nehmen und SecureBootModel auf Default lassen (Hintergrund der 2019er iMac hat keinen T2 Chip ist aber von Sonoma unterstützt)...

    Heile wieder daheim angekommen auch wenn Komot trotz allem wieder abenteuerliche Wege für mich parat hatte :)

    War wieder ein guter Stammtisch hat Spaß gemacht mit Euch auch wenn es nur eine kleine Runde war (an die Cosplayer im Haus werde ich mich trotzdem wohl nie gewöhnen)...


    ...mache Dinge sind übrigens noch immer in Zustellung *gg*

    So das Z97 Sorgenkind ist jetzt auch der 14.4 angekommen leider weiß ich nicht wirklich warum...


    Am langen Ende habe ich "nur" das SMBIOS von iMacPro auf MacPro umgestellt,SecureBootModel ausgestellt und den NVMEFixup.kext deaktiviert und einen NVRAM reset durchgeführt und dann ging es. Welche der Aktionen letztlich zum Erfolg geführt hat kann ich nicht wirklich sagen da es nicht mein Rechner ist und ich auch nicht selbst davor gesessen habe...