[Sammelthread] MacOS BigSur 11.0 DEV-Beta Erfahrungen

Beta 6 ganz normal durchgelaufen auf dem Optiplex 3020 SFF ohne Probleme.

Wie immer OpenCore Nightly 061 sowie die Nightlys von AppleALC, VirtualSMC, WEG, LILU genommen (alles via KU von heute)

Update auf die Beta 6 über die Systemeinstellungen ist soeben problemlos durchgelaufen. Opencore Version ist die 0.6.0 vom 3. August, die Acidantherakexte sind ebenfalls "nur" die aktuellen Releaseversionen.

Ich möchte hier jetzt niemanden provozieren und auch keine Diskussion vom Zaun brechen, nur als Info.

So furchtbar wichtig und alternativlos ist es wohl doch nicht, immer die superaktuellen nightly-Versionen am Start zu haben.Wünsche allen ein schönes Wochenende und viel Spass beim Testen.

Letzter Stand heute.

Mit dem Asus Board komme ich genau einmal in die DP6 auf einer Sata Festplatte.

Wen ich dann noch mal starten will geht mit Beta 6 und Installer nichts nehr, hängt oder macht Reset bei pciconfiguration begins

Schon verwunderlich aber ich hatte tatsächlich 0 Probleme mit Big Sur. 🙈

Erst auf externer Platte installiert - lief. Update auf Beta 6 wurde auch angezeigt, Update lief auch ohne Probleme durch.

Das ganze dann nochmal auf interner Platte alles gut.

Sogar entsperren mit der Apple Watch geht jetzt wieder was auf Catalina einfach nicht möglich war.

Einzigst Little Switch fehlt mir. Mal schauen wann da die Public Beta kommt oder ib ich noch irgendwie in die closed Beta komme.

Higgins12 Little Snitch gibt es als Technology Preview, für die man sich auf der Website anmelden muss. Keine Ahnung, ob das noch geht, aber ich habe dann einen persönlichen Download-Link bekommen. Leider ist das Ganze noch nicht sehr stabil und hat mir mit der Beta 5 erst mal das Netzwerk zerschossen. War zwar zu reparieren, aber ich habe nach Neustarts noch immer das Problem, dass Little Snitch nicht richtig/vollständig geladen wird und ich die Installation nochmal durchführen muss. Hab’s auch gemeldet, aber kein Feedback erhalten.

Ja das mit der Technology Preview hatte ich schon gesehen krokol na gut wenn das ganze eh noch zicken macht, werde ich es auch ohne überleben die paar Wochen.😁

Von alleine angezeigt, unbeaufsichtigt installiert und weiter geht es zur nächsten Beta

krokol Ich habe das selbe Problem, nach jedem Reboot startet der Hacki nicht mehr ordentlich. Ich hoffe wirklich, dass sie das bald fixen, so ist LS für mich nicht wirklich nutzbar, außer ich entferne die Netzwerkschnittstelle vor jedem Neustart und installiere sie dann wieder neu.

Ich benutze LuLu. Funktioniert unter Big Sur wie gehabt.

Dank dem tollen micropatcher für Big Sur läuft nun auch die Beta 6 auf meinem MBP Mid2012 mit Wifi. Der lange Weg den ich unter "Anleitungen" beschrieben hatte ist somit nichtmehr nötig.

https://github.com/barrykn/big-sur-micropatcher reicht aus und funktioniert

Nicht bei mir RealZac - hatte ich vorher schon probiert.

Adguard macht auch noch diverse Probleme trotz Nightly. Vorher auf der Testplatte hatte es funktioniert jetzt schmiert mir nach der Installation aber regelmässig "Sicherheit" in den Systemeinstellungen ab.

Mir ist aufgefallen das einigen bei den OC config.plist Editieren unnötige Fehler reinschlüpfen.

Hier ist eine Vorgehensweise die dazu beitragen kann diese Fehlerquote zu reduzieren:

1.Verwende den neuen EFI Ordner mit der neuen Sample.plist als das Ziel fuer die folgenden
Schritte, und deine funktionierende config.plist als Quelle.

2.Update alle Orderinhalte des neuen EFI Ordners.

ACPI - Übertrage deine SSDT....aml Dateien von deinen EFI Quell Ordner in den neuen EFI Ziel
Ordner

Drivers - Entferne Treiber in dem neuen EFI Ordner die nicht notwendig sind.

Kexts - Compile dir neue Kexte mit der neuesten vorhandenen source code, oder Lade sie nach
bedarf precompiled vom jeweiligen Internet Archiv runter.

Resources - Kopiere deinen Resources Ordner in den neuen EFI Ordner, wenn erforderlich für
boot chime oder open canopy.

Tools - Entferne was nicht benötigt wird.

Wichtig an dieser Stelle - Änder Sample.plist um nach config.plist

3 Wenn 2, erledigt ist, wie beschrieben, verwende ProperTree mit den 3 Finger + R Salut um einen
snapshot zu generieren der den letzten Stand des EFI Ordners, in der neuen config.plist Datei
reflektiert.

4. Übertrage alles was in der Quelldatei - config.plist - nicht mit den Informationen der Ziel
config.plist Datei übereinstimmt.

Ich bevorzuge diesen Vorgang mit PlistEdit Pro durchzuführen, die beiden Dateien "side by side" auf den Bildschirm zum Editieren Platzieren, dann bekommt mann eine gute Übersicht wo sich die Änderungen befinden und mann kann mit den Datenabgleich beginnen. Die Quelldatei ist bei mir immer an der linken Seite des Bildschirmes, weil ich eben nicht Chinesisch veranlagt bin.

Beim Vergleich starte ich immer von Unten > UEFI und arbeite mich hoch nach > ACPI, und öffne nur den Pfad mit dem ich mich gerade beschäftigen will.

Wenn alles fertig Editiert wurde kommt zu guter letzt und vorsichtshalber nochmal ProperTree an die Reihe mit den 3 Finger Salut + R.

Warum dies alles wenn es doch Beyond Compare gibt oder auch OCCConfigCompare?

Beyond Compare funktioniert nicht unter Big Sur - unter Catalina geht es aber noch.

OCCConfigCompare erwischt nicht alle Unterschiede und hat mir Anfangs viele Stunden Ärger bereitet.

Das scheint alles sehr Umständlich zu sein aber geht bei mir immer mit relativ geringen Zeitaufwand voran.

MFG Henties

Zitat von Higgins12

Nicht bei mir RealZac - hatte ich vorher schon probiert. [...]

Das ist eigenartig. Ich habe 2 Big Sur's am Laufen. Eines zuhause, frisch installiert und eines in Büro, Update von Catalina. Bei beiden keine Probleme.

Jedenfalls bisher nicht aufgefallen. Ich gucken mir das aber nochmal genauer an.

EFI Asus B250M Beta 6 OK

Na dann mal so...

rennt halt, ne?!?

badbrain 0x00000000 oder AAAAAA== als Base64 kann man natürlich auch machen aber ehrlich gesagt braucht man dann auch gar keinen Wert in die config eintragen da der null Wert dem Standard unter macOS entspricht will meinen sie SIP ist vollkommen aktiviert

Der Key csr-active-config dient dazu die SIP ganz oder in Teilen zu deaktivieren hierbei setzt sich der Wert der hier eingetragen wird aus einer Bitmask zusammen wobei jedes Bit in der Maske für einen bestimmten Teil der SIP steht. Folgende Werte stehen zur Verfügung:

Die Werte können beliebig miteinander kombiniert werden wobei jeweils der Hexadezimale Wert für jeden Teil der SIP den man deaktivieren möchte addiert werden muss. Angenommen wir möchten also zum Beispiel erlauben das nicht signierte (0x1,0x10) und nicht beglaubigte (0x200) Extensions geladen werden dürfen zudem möchten wir Debuggen können (0x8,0x20) und am NVRAM möchten wir auch rumspielen dürfen (0x40) es ergibt sich also 0x1+0x10+0x200+0x8+0x20+0x40 = 0x27100000 oder JxAAAA== im Base64 Format. Die SIP kennt also nicht nur die Zustände aktiviert oder deaktiviert sondern kann ganz im Gegenteil seht kleinteilig eingestellt werden nur leider macht das niemand wirklich bzw. nur die wenigsten machen sich Gedanken darüber was der unter csr-active-config eingestellt Wert wirklich bedeutet. Irgendwann hat sich in der Community die Denke etabliert das die SIP was ganz böses ist und daher grundsätzlich und immer deaktiviert gehört und fortan wird das halt so gefressen. Zuerst 0x67 später dann 0x7F und zu guter letzt aktuell halt 0x3E7 wurde zum Standart in jeder config und kaum jemand weiß für was oder warum der Wert da überhaupt gesetzt wird (ich gebe zu ich habe mir da auch nicht wirklich Gedanken zu gemacht bisher).

Ich möchte behaupten das die große Mehrzahl der User mit aktiver SIP (also kein Eintrag für csr-active-config) gut fährt und im normalen Betrieb auch kaum bis keine Einschränkungen bemerken wird dennoch gibt es immer mal wieder Situationen wo man einzelne Teile der SIP deaktivieren möchte/muss bei mir ist das zum Beispiel unter BigSur der Fall weil ich gerne meinen Adblocker (ADGUARD) auch unter BigSur verwenden können möchte was mit komplett aktivierter SIP nicht möglich ist. Die Funktionsweise von ADGUARD macht es nötig das eine Netzwerk Erweiterung installiert wird (Kext) was unter BigSur auf diese Art und Weise nicht mehr erlaubt ist (Stichwort DriverKit vs. KEXT) und von der SIP unterbunden wird so sie denn vollständig aktiv ist.

Dann weiß ich nun, warum bei mir, unter Big sur, nie ein Update angezeigt wurde.

SIP steht bei mir auf 0x67...

0x67 ist in dem Fall aber nicht kritisch das übersetzt sich zu:

Hier dürfte der Fehler also an anderer Stelle zu suchen sein Raptortosh

Probier mal folgendes im Terminal:

• sudo /System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil unenroll

Anschließend reboot und dann:

• sudo /System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil enroll DeveloperSeed
• sudo /System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil fixup

Erneuter reboot und auf Updates prüfen. Wenn alles richtig ist sollte es im Anschluß dann klappen.

Danke, Werde es mal versuchen