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)
[Sammelthread] MacOS BigSur 11.0 DEV-Beta Erfahrungen
- Mocca55
- Erledigt
-
-
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.
-
-
Von alleine angezeigt, unbeaufsichtigt installiert und weiter geht es zur nächsten Beta
-
-
-
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
-
-
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
OrdnerDrivers - 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
-
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:
Setting Wert in Hex Bedeutung CSR_ALLOW_UNTRUSTED_KEXTS 0x1 Erlaubt das Laden von nicht signierten Kernelextensions CSR_ALLOW_UNRESTRICTED_FS 0x2 Ermöglicht den Zugriff auf eigentlich geschützte Systemverzeichnisse (/System/Library) CSR_ALLOW_TASK_FOR_PID 0x4 Erlaubt Code Injects CSR_ALLOW_KERNEL_DEBUGGER 0x8 Erlaubt das ausführen von Kernel Debuggern CSR_ALLOW_APPLE_INTERNAL 0x10 Eine weitere Prüfinstanz, welche unsignierte Kexte blocken kann CSR_ALLOW_UNRESTRICTED_DTRACE 0x20 Erlaubt das Ausführen von dtrace-basierenden Monitoring & Reporting Tools CSR_ALLOW_UNRESTRICTED_NVRAM 0x40 Erlaubt das Bearbeiten oder Ändern des NVRAM's aus dem Userland CSR_ALLOW_DEVICE_CONFIGURATION 0x80 Erlaubt die externe Konfiguration des Systems/Verhindert Updates über Apples SWSCAN wenn aktivert CSR_ALLOW_ANY_RECOVERY_OS 0x100 Erlaubt "Downgrades des OS" CSR_ALLOW_UNAPPROVED_KEXTS 0x200 Erlaubt das Laden von Extensions die zwar signiert aber nicht beglaubigt sind CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE 0x400 Erlaubt das uneingeschränkte Ausführen von ausführbaren Dateien 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.
-
-
-
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
