Ich möchte hier einen Reservelaptop vorhalten, der "immer" auf aktuellem Stand ist: Wenn der Rechner eines Kollegen abraucht, etc., soll er besagten nehmen können.
- Der eine ist ein 13" M1, der andere ein 13" aus 2017
- Auf beiden Rechnern läuft Big Sur
- Beide sind bislang zu 99% identisch, da das MBP 2017 mittels Migrationsassistenten vom M1 eingerichtet wurde.

Würde es jetzt klappen, wenn ich
- Beide Computer mit thunderbolt-Kabel verbinde
- MBP 2017 im Festplattenmodus starte
- Mit CCC das M1 auf das MBP 2017 klone, so dass user-accounts und (ggf.) Fremdprogramme im Programme-Ordner aktualisiert werden?

(Mir ist bewußt (mehr aber auch nicht ), dass CCC das Betriebssystem irgendwie nicht mehr updaten kann, aber das könnte ich dann ja sporadisch auf dem MBP 2017 nachziehen)

Ich vermute nicht, denn macOS auf dem M1 ist für Apple Silicon (ARM) kompiliert und macOS auf dem 2017er für Intel (x86).
Aber brauchst du für dein Problem das wirklich? Würde hier nicht ein Merge der Daten reichen.

Das geht wohl nur so, wenn du regelmäßig mit TimeMachine Backup machst und ggf. fehlende Daten darüber holst.

Wie schon geschrieben wurde, ist das Big Sur auf dem M1 ein ganz anderer Code (oder auch Binaries genannt) , als der für Intel. Zwar sieht auf dem Bildschirm alle gleich aus, aber die CPUs, die den Code ausführen sind völlig anders und benötigen völlig anderen Code. Nur Programme/Apps enthalten entweder beide Binareis, den für M1 und Intel, sofern es diese Apps für beide CPUs schon gibt, oder nur aus Intel-Code. Apps, die nur aus Intel-Code bestehen, müssen während der Laufzeit "on the fly" von Intel auf M1 übersetzt werden. Das macht Rosetta2. Das aber klappt mit dem System selbst!

U.U. ist das Auslagern und Bearbeiten von Dokumente auf einem Server oder NAS sinnvoll, so wie es letztlich in jedem Unternehmen seien sollte. Dann kann jeder, der die Berechnung hat, Dokumente anderer öffnen.

Nein, das stimmt alles nicht. Zum einen wird das Betriebssystem ja hier überhaupt nicht mitkopiert (weil Apple das nicht mehr zulässt), zum anderen werden alle Versionen von macOS, die für mehrere Prozessortypen veröffentlicht wurden, immer mit "fetten" Binärdateien ausgeliefert. Das ist seit 20 Jahren unverändert.

Wenn mit CCC nur das Daten-Volume geklont wird, sollte das problemlos funktionieren. Ausnahme sind nur die Dienste, die direkt an den Rechner gekoppelt sind, also "Wo ist", FaceTime, Nachrichten und alle Einträge im Bereich "Internet-Accounts" der Benutzer.

Du liegst falsch mein Freund. Du kannst die Probe aufs Exempel machen. Installiere auf einer Intel Mac ein macOS auf eine externe Platte. Versuche dann einen M1 Mac von diese Platte zu starten. Geht nicht weil dort keine M1 Binaries des System vorliegen:

Nein.

Nein, das geht deshalb nicht, weil standardmäßig die Sicherheitseinstellung des M1 nicht zulässt, ein Betriebssystem zu starten, das nicht für diesen Computer personalisiert wurde. Du kannst auch zwischen zwei M1-Macs im Normalfall kein Betriebssystem austauschen.

Dann mach doch dem Test anders herum. Bei ner Intel Kiste kannst du das ausschalten.

Ich glaube du verwechselst das mit den Dev Tools und Libraries. Die müssen Universal sein damit ich auch auf nen Intel Mac ne UB meiner App bauen kann.

deus-ex
Ich fürchte, Du selbst irrst Dich. Marcel Bresink ist der Entwickler der Tinkertool-Apps. Ich gehe schwer davon aus, dass er weiß, wovon er spricht!

Noch mal ich rede nicht von Binärdaten die zum Entwickeln und Bauen von Universal-Apps notwendig sind. Die müssen selbst Universal sein. Ich rede von Kernel Erweiterungen, Treibern usw. also allen Bestandteilen die notwendig sind um das OS auf der Hardware auszuführen.
Kleines Beispiel. Der Grafiktreiber für Apple Silicon gibt es bestimmt nicht in einer x86 Version genau so wenig wie es eine ATI Treiber für ARM gibt.

Habe vergessen, mein erstes Fazit hier einzustellen:

* **Klonen von MBP M1 auf MBP 2020** am 21.09.2021, um Reserverechner verfügbar zu halten:
- MBP 2020 bereits Big Sur drauf und mittels Migrationsassistent einmal ein user installiert.
- Verbinden mit thunderbolt-Kabel, Starten des MBP 2020 mit Festplattenmodus, Freigabe mit Passwort
- Klonen mit neuem Backupplan unter CCC meldet nach 55:52 "okay" 271,81 GB kopiert. Es wurde lediglich ein Quellvolume und ein Zielvolume gewählt; HV hat sich nicht darum gekümmert, ob das das Datenvolume ist, etc.
- Starten des MBP 2020 endet in kernel panic
- Starten des MBP 2020 mit Cmd-R und dann "Big Sur neu installieren" gewählt.
- Rechner hat zwei Stunden gebraucht, ziemlich am Ende gab es auch eine kernel-panic, aber jetzt hat der Rechner durchgebootet und man kann mit dem user "Heiner" wohl arbeiten.
- Erneutes Klonen: Im Backupplan von CCC einige Ordner ausgeschlossen und eine Vorschau gemacht: 37 GB seien neu zu schreiben, davon wohl 35 GB das neue xcode 13. HV startet den Klonversuch.
- Nach 24:23 und 41,5 GB meldet CCC "okay". Neustart funktioniert ohne besondere Vorkommnisse.

Die kernel pancis hatten mich stutzig gemacht, aber (dennoch) läuft es

Bei einem solchen Anwendungsfall bei dem der Rechner gegen eine „andere Sorte“ im Bedarfsfall getauscht wird würde ich ja das Systen mal frisch auf eine externe Platte die installieren und den M1 von dort booten. Ggf einen neuen Benutzer (ich bevorzuge ja je einen Adminbenutzer und einen „Arbeitsaccount“, andere mögen das als überflüssig sehen).
Dann für den Test die Platte an den Intelrechner stecken und versuchen, dort von der externen Platte zu booten. So ist die Ausfallzeiten nochmals kürzer weil das Klonen entfällt.
Außerdem würde man so mal sehen, ob der Installer, wenn auf den M1 ausgeführt, auch alles „für Intel“ mit installiert.
Da man oft aber auch Programme, die nicht von Apple oder dem AppStore stammen, für die tägliche Arbeit braucht, sollten auch diese mal „auf den M1 installiert werden und anschließend auf dem Intel getestet werden.

Theoretisch sollte der Inhalt der Benutzerordner keinerlei Einfluss auf diesen Test haben. Außer man installiert Programme „nur für einen Benutzer in dessen Account“.