[Sammelthread] MacOS BigSur 11.0 DEV-Beta Erfahrungen
- Mocca55
- Erledigt
-
-
-
Hi Freunde, ich habe auf meinem Hackintosh die letzte aktuelle Beta am laufen (siehe Signatur). Alles läuft soweit sehr gut.. Allerdings bekomme ich das mit den Schreibrechten bzgl Systemfiles (SIP deaktivieren) nicht hin. Bin zur Zeit mit Open Core 0.6.0 unterwegs und habe unter nvram das csr-active-config die 77080000 eingetragen.. Funktioniert trotzdem nicht. Habe bestimmt etwas ausgelassen..!?! oder falsch verstanden..?? Hat jemanden ein kleine Anleitung für mich? Herzlichen Dank im Voraus.. Gr. sv
-
badbrain Gute frage. Hast du es denn probiert?
-
Allerdings bekomme ich das mit den Schreibrechten bzgl Systemfiles (SIP deaktivieren) nicht hin.
Kannste vergessen. Klappt unter BS nicht mehr weil das Systemlaufwerk 'gesealt' wird. Was haste denn vor?
-
badbrain Danke für den Hinweis, diesen Workaround würde ich aber im macOS gerne lösen - denn was machst Du denn auf einem aktuellen originalen MAC ? Abgesehen davon ist es Bug (oder Feature ) im aktuellen Big Sur.
-
Servus karacho,
ich hatte vor einiger Zeit via Hackintool das Display EDID Patching für höhere Auflösungen des Displays vorgenommen und muss den entsprechenden VendorID-Ordner in folgenden Systemordner einfügen: /System/Library/Displays/Contents/Resources/Overrides
Geht aber nicht. . Irgend eine Idee?
-
Wenn du beide Systeme im gleichen Rechner hast, sprich Catalina 10.15.6 und Big Sur) und per Dualboot startest, dann kannst du die Prozedur von Catalina aus probieren. SIP hast du ja schon disabled. Dann gib dir Schreibrechte wie gehabt mit 'sudo mount -uw /' Dann navigiere zu /Volumes/Big Sur - Daten - oder wie es bei dir heißen mag - und versuche die änderungen dort vorzunehmen.
-
Es gibt da schon eine Möglichkeit, die ist aber etwas umfangreicher...
Dafür muss aber auch im Recovery Mode der csrutil authenticated-root disable ausgeführt worden sein.
Hier die einzelnen Befehle zum Mounten des BS-Root, damit man Zeuch machen kann.
(*) = Der Befehl mount wird benötigt, um die Partition zu finden, die letztendlich geändert werden soll.
Das Ergebnis bei meinem MBP sieht so aus:
Code- al6042@al6042-MBP13 ~ % mount
- /dev/disk1s5s1 on / (apfs, sealed, local, read-only, journaled)
- devfs on /dev (devfs, local, nobrowse)
- /dev/disk1s4 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime, nobrowse)
- /dev/disk1s2 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse)
- /dev/disk1s6 on /System/Volumes/Update (apfs, local, journaled, nobrowse)
- /dev/disk1s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse)
- map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse)
Hier ist /dev/disk1s5s1 on / (apfs, sealed, local, read-only, journaled) die spannende Partition, die dann als /dev/disk1s5 zu /Volume/Test gemounted wird.
Wenn du deine Änderungen alle erledigt hast, musst mit folgendem Befehl die Änderungen auch nach dem nächsten Booten noch vorhanden sind:
Quelle: https://eclecticlight.co/2020/…dded-security-protection/
-
-
Heureka, das ich das noch erleben durfte
Nach viel Bastelei und Recherche ist es mir endlich gelungen meine Kiste davon zu überzeugen das BigSur Updates durchaus etwas sind das man auch über die Betriebssystemeigene Update Funktion laden kann daher kann ich nun auch für das Thinkpad Vollzug melden. Vielleicht interessant für alle die das Problem haben das BigSur und ggf. auch Catalina keine Updates anbietet das Problem/der Fehler hängt mit der Konfiguration der SIP zusammen. Setzt man den empfohlenen von 0x3E7 was folgenden Einstellungen entspricht:
belohnt macOS die Aktion unter BigSur recht humorlos mit dieser Meldung:
Wobei direkt auffällt das hier keinerlei Angabe dazu gemacht wird woher macOS die Updates beziehen würde (Der Info Bereich unter dem Wort Softwareupdate ist leer). Hierfür verantwortlich ist folgender Teil der SIP:
Ist dieser Part der SIP deaktiviert funktioniert Softwareupdate nicht mehr und wirft nach einiger Zeit des vergebenen Suchens eben die obige Fehlermeldung aus. Grundsätzlich sollte man ja auch eigentlich die SIP nicht deaktivieren und es gibt auch nur wenig Gründe dafür das zu tun denn in der Mehrzahl der Fälle kann man macOS auch auf dem Hackintosh ganz prima mit aktiver SIP verwenden will oder muss man die SIP dennoch matt setzen dann empfiehlt es sich nicht mit dem Holzhammer (0x3E7) zu Werke zu gehen sondern sich zu überlegen welche Features man wirklich braucht und davon ausgehend den für einen selbst passenden Wert errechnen. Ein Nützlicher Helfer für das Unterfangen ist das CsrDecode.command (https://github.com/corpnewt/CsrDecode) von @corptnewt. Einmal richtig eingestellt gibt es dann zur Belohnung
folgendes zu sehen:
Unter OpenCore wird das ganze in die config in den Bereich NVRAM eingetragen:
Wobei ich hier am Desktop zusätzlich zum ADD Eintrag auch den Delete Eintrag aufgenommen habe weil ein alleiniges ADD nicht den gewünschten Erfolg gebracht hatte was aber wohl der Tatsache geschuldet ist das OpenCore meines Wissens nach den Eintrag nur dann hinzufügt wenn die Variable nicht schon im NVRAM vorhanden ist. Alternativ zu dem Delete Eintrag kann man die Variable auch manuell via Terminal vor dem Reboot löschen. Probiert es mal aus bei mir hat es die Probleme mit den Updates gelöst.
-
-
Du solltest auf jeden Fall schon mal vmscgen=1 und -lilubetaall aus den bootargs entfernen, weil diese nicht mehr benötigt werden.
Deine config.plist müsstest du auch nochmal mit der sample.plist der 0.6.1 OC Version vergleichen und entsprechend anpassen. Auf den ersten Blick sind mir z. B. die fehlenden, neu hinzugekommenen Einträge im Bereich Kernel aufgefallen.
-
So, die beiden Argumente habe ich entfernt ... Ändert nichts an dem Bootfreeze.
Dann werde ich mir das mal anschauen, wobei mich aber wundert das genau die 0.6.1 die ich hier gepostet habe die Beta 5 ohne Probleme gebootet hat und jetzt plötzlich nicht mehr. Sollte das wirklich an den Einträgen liegen?
-
-
NVRAM-Reset nach den Änderungen gemacht?
-
genau an dieser Stelle macht mein Asus auch immer einen Reset oder bleibt hängen.
ich denke das hat was mit Opencore zu tun
-
-
-
Wenn "jede" Installation streikt, dann war vermutlich vorher schon etwas, in der Konfiguration nicht korrekt.