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 erstellen
Bei mir genau das selbe Problem, auch mit iMacPro1,1.
//Edit: Hab das Update jetzt über den App Store gemacht. Einfach nach Big Sur suchen und dann auf "Laden" gehen, dann wird das 11.1 Update runtergeladen. Ist dann aber leider 12gb groß, aber zumindest funktioniert es... Installation lief aber ohne Probleme.
Das ist dann kein Update sondern der ganze Installer. Und dieser lässt sich aber auch ganz leicht (und vermutlich auch schneller) via ANYmacOS laden. 
Kannst du einfach ändern, aber da du mal Probleme damit hattest, hab noch eine safety EFI irgendwo auf einem Stick z.b.
Damit die Änderung wirkt muss du den nvram reseten oder csr-active-config unter delete in der config eintragen.
Bei mir kann ich Big Sur auch nicht mit csr-active-config 00000000 booten. Der Balken bewegt sich grad mal 1mm und der Rechner startet neu. Catalina booted aber problemlos. Mit 77080000 booted auch Big Sur.
SabineT Danke. Das ist auch echt schräg.
JimSalabim entschuldige wenn ich Dich hier tagge. Du fährst auf Deinem z390 doch auch mit SIP enabled (sprich 00000000), oder?
Wie es aussieht muss das wohl enabled werden um das Update von 11.0.1 auf 11.1 angeboten zu bekommen, aber so bleibt das Bild schwarz 
Eine Idee?
Ja, ist merkwürdig. Wir könnten uns der Sache nähern indem wie den Rest der EFI mal anschauen.
Ich nehme an du hast deine USBports per SSDT gemappt? Wenn ja, kannst du eigentlich die SSDT-USBX.aml deaktivieren. Bei den Treibern brauchst du den OpenUsbKbDxe.efi auch nicht.
Wofür brauchst du die SSDT-DTGP.aml ?
SabineT Der richtige Wert, um SIP unter Big Sur zu deaktivieren, lautet FF0F0000. Aber wie dem auch sei, maybeageek , ja, ich habe SIP aktiviert (00000000) und alle Big-Sur-Updates haben bei mir damit funktioniert. DmgLoading steht bei mir auf "Any", SecureBootModel auf "Disabled" (beides unter Misc -> Security in der OpenCore-config.plist), falls dir das was hilft.
hackmac004 Wieso kann er die SSDT-USBX deaktivieren, wenn die USB-Ports per SSDT gemappt sind? Die Einträge aus der SSDT-USBX (für die richtigen Einstellungen zur Stromversorgung über USB) sind standardmäßig eigentlich nicht in einer SSDT-UIAC enthalten. Man kann das zwar auch dort durchaus eintragen, aber solange das nicht der Fall ist, sollte man die SSDT-USBX schon aktiviert lassen, würde ich denken. Genau, die SSDT-DTGP braucht maybeageek nicht, die DTGP-Methode ist nämlich schon genau so in seiner SSDT-PLUG mit eingetragen.
Der OpenUsbKbDxe.efi ist eine Alternative zu KeySupport und funktioniert mal besser, mal schlechter, mal genauso gut. Man sollte aber nicht beides gleichzeitig verwenden (siehe OpenCore-Configuration.pdf). Für maybeageek heißt das, entweder KeySupport deaktivieren (unter UEFI -> Input) ODER OpenUsbKbDxe.efi entfernen und in der config.plist unter UEFI -> Drivers deaktivieren.
JimSalabim Ich kannte das bisher nur so, dass die SSDT-EC.aml & SSDT-UIAC.aml + UsbInjectAll eine zeitlang so zusammen genutzt wurde. Mittlerweile exportiert das Hackintool eine SSDT-EC-USBX.aml
EC und USBX hatte ich so getrennt noch nicht gesehen. Wenn das passt, ist alles gut und kann dann aktiviert bleiben.
Da OC mit dem Quirk XhciPortLimit die USBinjectAll.kext eigentlich nicht mehr braucht, hätte ich noch die Frage, ob es reicht XhciPortLimit auf Yes zu stellen ohne USBinjectAll.kext oder andersherum ?
Da mir das nicht ganz klar ist, benutze ich lieber einfach die USBports.kext
hackmac004 Den XhciPortLimit-Quirk braucht man bei Verwendung der USBInjectAll.kext nicht (und natürlich auch nicht mehr, wenn man seine USBPorts.kext fertig hat). Allerdings braucht man durchaus die USBInjectAll.kext für die Verwendung der SSDT-UIAC.aml.
Ich hatte das Problem auch. Allerdings hatte ich zu dieser Zeit ne Public Beta von Big Sur. csr-active config ändern hat nichts gebracht. Es kam immer 'ne Fehlermeldung, dass das Prüfen nach Updates fehlgeschlagen wäre.
Habe dann mit AnyMacOS die aktuellste Version von BigSur runter geladen und einen clean install gemacht und jetzt ist alles wieder normal, soweit ich das beurteilen kann.
Ich seh schon JimSalabim und hackmac004 ich muss da nochmal ran und einiges verbessern
Mal sehen wann ich die Zeit dazu finde 
Danke erstmal.
SabineT Der richtige Wert, um SIP unter Big Sur zu deaktivieren, lautet FF0F0000. Aber wie dem auch sei, maybeageek , ja, ich habe SIP aktiviert (00000000) und alle Big-Sur-Updates haben bei mir damit funktioniert. DmgLoading steht bei mir auf "Any", SecureBootModel auf "Disabled" (beides unter Misc -> Security in der OpenCore-config.plist), falls dir das was hilft.
JimSalabim das von mir verwendete 77080000 funktioniert auch Problemlos (Apple Internal ist dann enabled), nur 00000000 (also SIP enabled) macht mit Big Sur Probleme.
Ich werde aber wohl in den sauren Apfel beissen und den Full-Installer mit AnyMacOS über meine 2Mb/s Internetanbindung runterladen.
SabineT Siehe hier:
https://dortania.github.io/Ope…issues.html#disabling-sip
Aber klar, es gibt ja nicht nur komplett an und komplett aus, insofern sind ja auch andere Werte möglich.
Laut Dortania Guide hängt es damit zusammen, dass keine Updates angeboten werden https://dortania.github.io/Ope…newer-versions-of-big-sur
Bei mir siehts jedenfalls danach aus: diskutil apfs list
Werde jetzt mal mit FullInstaller drüber bügeln und sehen, ob sich das ändert. Wäre doch ziemlich doof, wenn man jedesmal den kompletten Installer laden müsste, weil kein Update mehr angeboten wird.
Ansonsten hilft nur ein Roll back über die Recovery Partition, wie es im Guide beschrieben wird.
