FileVault Broken in Sequoia??

Ich hatte das Gegenteil: FileVault ließ sich am Anfang nicht nicht Installieren, sozusagen eine Zwangsverschlüsselung..

War nen hartes Stück Arbeit an meinem kleinen Z390itx.

Hattest Du FileVault bisher nicht aktiv?

Ich hatte das Problem mit 15.1 Beta 1 auch. Workarround war erst Sonoma installiert, früheres Sequoia ging wohl auch, FV2 aktiviert und 15.1 Beta 1 per Softwareupdate gezogen.

Unter 15.1 geht so manches Standart-Werkzeug nicht mehr: der Migrations-Assistent ist auch noch nicht gefixt..

Oder aber wegen OCLP Root Patche ist das Siegel gebrochen?

diskutil info disk...

...

FileVault: Yes

Sealed: Broken

Locked: No

Wenn dann kann man den Kernel Patch einsetzen

Das hat damit nichts zu tun. Der Patch wird ja nur benötigt wenn OCLP am Werke war. schrup21

FV2 geht auch nicht wenn mit Intel gearbeitet wird und kein OCLP dabei ist.

Hab das jetzt schon ne Weile am Elitebook nicht mehr aktiv eben weil ich da auf den OCLP angewiesen bin (FENVI) und der Patcher den Dienst verweigert wenn die Platte verschlüsselt ist aber wenn ich es denn aktivieren wollen würde dann könnte ich das (eben getestet)...

Laufen habe ich auf der Kiste die letzte Beta von 15.1 mit dem OCLP WIFI Patch und sonst allem Bums den es dazu braucht.

EDIT: Eben getestet ist gut die Kiste ist nun unbeirrt dabei die Platte zu verschlüsseln ein riesen Spaß aber nun gut dann werden die nächsten Betas halt geskipped und erst bei Release wieder entschlüsselt und geupdated *humpf*

Zitat von ozw00d

Moin zusammen,

hat sich unter Sequoia FV /oder OC seitig irgendwas geändert?
Eine Aktivierung scheint unmöglich egal ob über GUI oder Terminal.

Konnte bisher jemand eruieren woran das liegt?

hackintosh-forum.de/attachment/219014/

Alles anzeigen

welche Version von macOS?

Wichtig zu erwähnen wäre noch das ich natürlich die Kernel Patches am Start haben eben wegen des OCLP Einsatzes denn andernfalls würde das natürlich aufgrund des gebrochenen Sigels auf dem Snapshot nicht funktionieren...

Im Wesentlichen aktiv sind:

1. Force FileVault on Broken Seal (_apfs_filevault_allowed)
2. Disable Root Hash Validation (_authenticate_root_hash)

wenn das frisch installiert ist, kann es nicht Broken sein - OCLP Root Patche würden das Siegel natürlich brechen, daher mein Hinweis.

aber mit

diskutil list um den IDENTIFIER zu ermitteln und dann

diskutil info [IDENTIFIER des APFS Volume, z.B. disk1s4]

Ich check das mal mit 15.1 gegen, in 15.0 konnte ich FV aktivieren.

Muss nur noch "kurz" Entschlüsseln...

Also, hab mein Dienst Laptop (*) von 15.0 nach 15.1 Beta (24B5055e) aktualisiert, und FileVault kann ich da aktivieren (Verschlüsselt gerade). Das Volume ist Sealed (zu meiner Überraschung war es vor Update Broken, obwohl keine Root Patche). Den Force FileVault on broken Seal Kernel Patch hab ich da nicht aktiviert.

(*) ein Fujitsu Lifebook U7510 mit I5 10210U CPU und Intel AX201 WLAN (also Itlwm / Heliport und Intel Bluetooth). Sequoia von USB SSD (die eingebaute SSD ist Windows).

ich habe nochmals eine Check gemacht und muss einräumen, dass es weder Probleme mit Aktivierung von FV2 noch dem Migrationsassistent mehr gibt. Ich habe den Installer vom 04.09. Version 20.0.09 verwendet, also nicht aktuell und es funktioniert beide bestens. Ich vermute dass es an aktuelleren kexten in der EFI liegt, weshalb die Probleme nicht mehr auftreten, insbesondere Amfi.kext 1.4.1 Andere Erklärung habe ich nicht dazu.

Nur so eine Idee aber mag das vielleicht (auch) am verwendeten SMBIOS liegen?

ich meine es könnte ja durchaus sein das ein SMBIOS von einer Maschine die einen T-Chip hat hier problematisch ist weil der T-Chip bei den echten Mac's die SecureEnclave enthält die unter anderem ja auch bei der FileVault Verschlüsselung einen Rolle spielt? Am Elitebook habe ich RestrictEvents im Einsatz mit dem revpatch=sbvmm ARG was ja am langen Ende dafür sorgt das macOS denkt es würde in einer virtuellen Maschine laufen interessant wäre es nun also zu wissen ob ihr den auch am Start habt (zumindest die beiden bei denen es funktioniert) bzw. ob hier ein SMBIOS mit T-Chip im Einsatz ist oder nicht zudem natürlich auch ob Du ozw00d ein T-Chip SMBIOS nutzt und ob Du RestrictEvents verwendest oder nicht...

Schon richtig und gut so dennoch kann es ja sein das Apple hier mit Sequoia die Zügel angezogen hat und nun FileVault verweigert wenn der T-Chip fehlt? Hau Dir testweise mal den RestrictEvents.kext mit rein und das BootArg revpatch=sbvmm wenn die Maßnahme dazu führt das FileVault anschließend läuft liegt es am SMBIOS wenn nicht liegt der Fehler an anderer Stelle...