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
Hallo,
Kennt zufällig jemand eine Methode, wie man einen Big Sur APFS Systemschnappschuss einfach reparieren kann. Ich weiß, dass ich ich es wieder mit einem Full Installer USB Stick gerade biegen könnte, aber vielleicht gibt es schon eine schnellere bzw. einfachere Lösung.
Viele Dank!
Hier gibt es Aussagen dazu:
https://www.lifewire.com/roll-back-apfs-snapshots-4154969
Find's aber auch nicht zwingend brauchbar, was da steht.
Die Infos zum Schnappschuss kamen gerade richtig, standen auch noch auf meiner Liste der Dinge, die ich mir mal anschauen wollte.
Direkt mal selbst einen erstellt, sicher ist sicher;))
Da dieser aber auf der Bootdisk abgelegt ist, würde ich ihn gern auf ein sep. Volume kopieren, wie kommt man den daran?
Mit CCC oder Timemaschine?
Ich nehme an, wenn man TimeMachine deaktiviert hat, wird der Quatsch nicht angelegt, oder?
Bei Windows kann ich sehr gut nachvollziehen, warum es eine Rollback-Funktion gibt, da man dort mit einem falschen Treiber oder Software Version echt alles ruinieren kann.
Aber beim Mac, wo alles gefühlt auf nur 10 Mac Modellen laufen muss und System-Datein von User-Daten so gut entkoppelt sind, Apps in Sandboxes laufen und es keien Registry gibt? Ich sehe micht die Notwendigkeit für so ne Snapshot-Geschichte. Außer sie vertrauen der Zuverläsisgkeit ihres eigene Betriebssystems nicht mehr.
Ich nutze OSX seit Leopard und ich kann mich nicht erinnern, dass OS schon mal so zerschossen gewesen wäre, dass man es nicht durch drüberbügeln hätte fixen können. Vollkommen überflüssiges Feature.
Schnappschuss und TMB kenne ich noch nicht, mache aber lieber eine Sicherung zuviel als zuwenig.
Ärgerlich nur das man ein TMB Volume exklusiv dafür benötigt. Wollte gerade auf eine Raid-1, auf dem genügend Platz vorhanden ist mit TMB eine Sicherung erstellen. Mitnichten;) will doch glatt das Teil nur für sich.
Einfach eine zusätzliches Volume im Container anlegen, gefällt ihm auch nicht, ist schon sehr eigen;(
LetsGo Das ist ja mal ein sehr stranges Verhalten der Kiste. Werde nachher mal testen, ob das Löschen von LaunchAgents und LaunchDaemons solche Auswirkungen hervorruft bei mir, da Time Machine deaktiviert ist.
Ganz informativ: https://eclecticlight.co/2020/…urs-system-volume-sealed/
Es ist ja auch immer die Frage, ob ihr nach eurem Eingriff ins System das ganze auch wieder abschließt.
Das ist der Befehl mit ich das immer mache, nachdem Änderungen im Read/Write-Modus erfolgt sind.
Achtung: Die Pfad-Angabe zwischen /Volumes und /System kann abweichen,
wie hier nachzulesen ist --> https://eclecticlight.co/2020/…dded-security-protection/
Ich hätte gedacht, dass ein Aktivieren des FileVault das Versiegeln in Ordnung bringt.
Irgendwie fehlt eine gute Doku erstens wozu das gut ist, wie ist die soll-Lage, wiebringt man alles in Ordnung. Keiner der Beiträge im Internet (von dem was ich kenne) liefert bislang eine vollumfängliche Information. Leider!
FileVault dient zur Verschlüsselung des APFS-Containers unter Catalina und BigSur.
Das ist also ein Schutzmechanismus der noch vor dem eigentlichen Boot-Vorgang, bzw. der System-Nutzung zum Tragen kommt.
Hat also auch keinerlei Einfluss auf den Inhalt der APFS-Snapshots selbst.
Das leuchtet ein. Wäre halt schön gewesen, wenn das System von sich aus einen gewissen "All good"-Zustand herbei führen könnte. Wobei wir nicht mal genau wissen, was das in diesem Fall genau ist.
Nobody is perfect! Dafür sieht es halt gut aus... 
So wie ich es eigentlich Linux wünschen würde. Aber das ist ein anderes Thema.
LetsGo war zuerst bei mir auch so, dass ich SIP nicht mehr deaktivieren (auf <00000000> setzten) konnte ohne in eine reboot Schleife zu kommen, aber mit der Info/den sittings für scr-active-config mit "67080000" von al6042
(siehe: BS 11.2 -> 11.2.3 sind erschienen, "Bei mir werden auf den Hackis die neuen Updates nur angeboten, wenn ich entweder SIP aktiv lasse oder den "csr-active-config" auf "67080000" stehen habe.Mit letzterem kann ich zum einen noch die System-Partition im "Read/Write"-Mode mounten und zum anderen weiterhin den TotalFinder einsetzen.")
bootet das System bei mir wieder ganz fein und Updates werden auch wieder angezeigt!
Ich hab nur "Anwenden und Neustarten" im Kextupdater ausgeführt, nachdem ich die Veränderungen vorgenommen habe. Muss ich den von dir beschriebenen Terminal Befehl noch ausführen?
Das Booten funktioniert bei mir auch noch ganz normal, wenn ich SIP auf FF0F0000 stehen lasse. SIP auf 67080000 zu setzen, habe ich noch nicht ausprobiert. Jedoch würde ich auch gerne in der Lage sein, diesen wieder auf <00000000> zu setzen ohne in der Reboootschleife hängen zu bleiben.
