Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

macOS 10.15.5: Fehler im System verhindert bootfähige Backups von APFS-Volumes

Mit Time Machine verfügt macOS über eine komfortable Datensicherungsfunktion. Viele Mac-Nutzer setzen darüber hinaus jedoch auch Backup-Software von Drittanbietern ein, weil diese zum Teil erheblich mehr Möglichkeiten bietet, etwa das Erstellen von bootfähigen 1:1-Kopien eines System-Volumes. Mit macOS Catalina 10.15.5 ist das offenbar nicht mehr in jedem Fall möglich, wenn APFS zum Einsatz kommt.


Fehler in essentieller Systemfunktion
Die Ursache des Problems beschreibt Mike Bombich, Gründer und Chefentwickler von Carbon Copy Cloner (CCC) in einem Blogbeitrag. Das Programm nutzt eigene Kopierroutinen, um etwa bootbare Klone von System-Volumes anzulegen. Ein Fehler in einer hierfür benötigten Systemfunktion namens chflags() sorgt nun in macOS 10.15.5 dafür, dass Ordner auf einem APFS-Volume nicht mehr mit einem benötigten Flag versehen werden, welches für die Erstellung eines bootfähigen Klons erforderlich ist. Die Funktion liefert allerdings keine Fehlermeldung, so dass Programme wie CCC davon ausgehen, alles sei wie vorgesehen abgelaufen. Die Folge: Es wird zwar ein Backup angefertigt, dieses ist jedoch scheinbar leer und das enthaltene macOS lässt sich nicht booten.

Bug bereits in Beta bemerkt und gemeldet
Der Fehler trat bereits in einer der letzten Betas von macOS 10.15.5 auf, Bombich meldete ihn auch an Apple. Allerdings wurde der Bug in der finalen Version, welche am vergangenen Dienstag erschien, nicht behoben. Betroffen ist nach derzeitigem Stand ausschließlich die Erstellung neuer Backups von APFS-Volumes. Vor einem Update mit Carbon Copy Cloner angefertigte bootfähige Sicherungen sind laut dem Blogeintrag nicht beeinträchtigt. Die aktuelle Betaversion 5.1.18 von CCC behebt das Problem. In dieser kommt bei der Ersterstellung eines startfähigen Klons nicht mehr die hauseigene Kopierroutine zum Einsatz, vielmehr wird die von Apple seit einigen Monaten empfohlene Methode "Apple Software Restore" (ASR) genutzt. Die genaue Vorgehensweise beschreibt Bombich in einem weiteren Blogbeitrag.

Absichtliche Änderung ist wenig wahrscheinlich
Bombich zufolge ist nicht vollständig auszuschließen, dass Apple die Änderung absichtlich vorgenommen hat. Der CCC-Entwickler hält das allerdings nicht für sehr wahrscheinlich, da das aktuelle Verhalten der Systemfunktion chflags() grundlegenden Programmiergepflogenheiten widerspricht. Darüber hinaus hätte Apple wohl die Entwickler über eine solche einschneidende Maßnahme vorab informiert, um ihnen Zeit für entsprechende Reaktionen zu geben.

Kommentare

wolf2
wolf228.05.20 18:28
apple ist halt kleingeistig und perfide. natürlich ist das ein versuch noch mehr kontrolle zu erlangen und man schaut, wie weit man es treiben kann. t2 detto.
aber solange die leute für mehr ram das 5fache des marktpreises zahlen und sich dieser nicht mal erweitern lässt, wird sich nichts ändern.
raunzen, mosern, sumpern, sudern, was uns bleibt.
-12
Franz Audiowerk
Franz Audiowerk28.05.20 19:16
Wenn du schon Behauptungen hier einstellst, dann bitte in entsprechender Form...
0
albertyy28.05.20 19:26
Dast ja ein Ding und sehr ärgerlich.
Was heißt das jetzt ?
In der Überschrift steht: es geht nicht
und weiter unten im Text: "Die aktuelle Betaversion 5.1.18 von CCC behebt das Problem."

WAS GILT DENN JETZT ?
0
sierkb28.05.20 20:16
albertyy
Was heißt das jetzt ?
In der Überschrift steht: es geht nicht
und weiter unten im Text: "Die aktuelle Betaversion 5.1.18 von CCC behebt das Problem."

WAS GILT DENN JETZT ?

Beides gilt.

Carbon Copy Cloner Knowledge Base (ccc5), 28.05.2020: macOS Catalina Known Issues: Apple introduced a bug in 10.15.5 that prevents the creation of firmlinks
Carbon Copy Cloner
macOS Catalina Known Issues

Apple introduced a bug in 10.15.5 that prevents the creation of firmlinks

The chflags system call no longer works correctly on 10.15.5 with regard to setting the special "firmlink" flag that establishes links betweent the System and Data volume group members. If you're establishing a new backup of macOS 10.15.5 or later, CCC 5.1.17 (and earlier) will be unable to create a correctly-functioning APFS volume group. Many folders on the destination volume will appear empty, and the volume will not be bootable.

Solution: Update to CCC 5.1.18 to establish a bootable backup of 10.15.5 or later. See this blog post for more details.

We have reported this issue to Apple (FB7706647) and we are currently awaiting a response.

[…]

Carbon Copy Cloner (27.05.2020): APFS: A bug in macOS 10.15.5 impacts bootable backups, but we've got you covered
[…]

Last Monday (May 18) I filed a bug report with Apple on this subject (FB7706647). I also opened an incident with Apple's Developer Technical Support. I got a sympathetic ear, and someone to advocate my case with Apple Engineering – which I greatly appreciate. However, it was for naught. The last 10.15.5 beta shipped last Wednesday (May 20) – without a fix. Then today, Apple shipped 10.15.5 with this nasty little bug, and here we are, creating whole, but slightly less functional backups.

[…]

Carbon Copy Cloner 5.1.18-b1 (6002) Release Notes:
[…]

Fixed
Addressed an issue that Apple is introducing in 10.15.5 (FB7706647) that will prevent CCC from creating a valid APFS volume group when creating an initial backup of a Catalina. Our solution will be disabled in the final release of 5.1.18 if Apple fixes this macOS bug prior to shipping 10.15.5.

New
Starting in 10.15.5, CCC will no longer back up a macOS Catalina System volume to a disk image destination. We're making this change reluctantly, unfortunately we just can't get reliable results when using Apple's proprietary utility with disk images.

[…]
+7
[ezi0n]29.05.20 00:55
na klasse - die news kommt etwas zu spaet - waere nett gewesen wenn sowas vorher bekannt gemacht wuerde besonders wenn es in der beta schon erkannt war ... gestern aktualisiert

edit: wieder umsonst erschrocken, scheint ja bereits ne loesung zu geben und mein altes backup tuts wohl auch ...
+1
Warp
Warp29.05.20 01:03
Hast du ein bestehendes aktualisiert? Bestehende, die VOR dem Update erstellt sind, sind da nicht von betroffen. Der Fehler kommt yum Tragen wenn du ein komplett neues NACH dem Update erstellst. Das ist dann nicht bootfähig.
0
Chrigu4129.05.20 07:52
Wie zuverlässig ist die neue Beta von CCC? Hat schon jemand Erfahrung?
Danke für einen Hinweis!
0
Marcel_75@work
Marcel_75@work29.05.20 12:26
Chrigu41
Wie zuverlässig ist die neue Beta von CCC? Hat schon jemand Erfahrung?
Danke für einen Hinweis!

Gestern aktualsiert, Clone lief durch, Start von externer SSD problemlos. Konnte keine Probleme feststellen mit der Beta.
+1
Chrigu4130.05.20 08:17
Danke Marcel. Heute Samstag früh ist das offizielle Update von CCC erschienen! Darin wird der Bug behoben.
0
Papierlos31.05.20 18:40
Ist ChronoSync oder SuperDuper auch betroffen?
0
Guy Incognito31.05.20 19:59
Papierlos
Ist ChronoSync oder SuperDuper auch betroffen?

SuperDuper auch, ja.
+2
jmh
jmh01.06.20 15:04
ich denke, dass hier generell alle backup-programme betroffen sind, die bootfaehige 1:1-klons auf in- oder externen laufwerken anlegen koennen.

ich benutze suerduper! und bin heilfroh, dass ich mit inkrementellen backups abwarten kann, bis apple diesen fehler behoben hat.

ich habe noch ein anderes kuriosum: nach einem der letzten catalina-updates (ich glaube es war 10.15.3), wurde ich in superduper! aufgefordert, auch das backup-laufwerk in apfs zu formatieren ("mandatory"). zuvor war es kein problem, auf ein hfs+-formatiertes laufwerk zu sichern. beide laufwerke sind, was fabrikat und groesse betrifft, identische ssds.

ich habe superduper! so konfiguriert, dass das backup abends durchlaeuft und der mac danach abschaltet. wenn ich am naechsten tag den mac wieder anschalte, startet der mac erst mal vom backup-laufwerk, obwohl das bootlaufwerk eindeutig anders festgelegt ist.

nach einem veranlassten neustart wird ohne mein weiteres zutun dann vom richtigen laufwerk gestartet.

halte ich beim start nach einem vorabendlichen backup gleich die opt-taste gedrueckt, ist im aufgerufenen boot screen das richtige laufwerk ausgewaehlt. nach "enter" startet der mac dann wie vorgesehen.

mache ich abends kein backup, startet der mac – wie in den voreinstellungen angegeben.

wie gesagt, ein kuriosum. und ich finde keinen grund, warum das passiert.
wir schreiben alles klein, denn wir sparen damit zeit.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.