Originally Posted By: artie505
In OSs prior to Catalina, CCC could create a bootable clone of your boot volume in another volume in the same container if SIP was disabled, and a complete, but non-bootable, one if it was enabled. In Catalina, because of a negative interaction between SIP and Apple's new System/Data scheme, even a complete non-bootable clone is impossible. (Mike Bombich is hoping it's a bug that Apple will take care of, but he's not certain). And even if it's possible to turn the trick with SIP disabled, I'd bet that there aren't enough users running in that state to justify the time investment.

In my case it is not CCC that is the culprit, rather it is the T2 chip which has a setting that prevents booting the computer from ANY external drive. That setting can be changed by booting into the Recovery Drive and launching Utilities from the menu bar.

FYI I am running CCC 5.1.15b1 (5890) which offers a completely new cloning methodology called a "Full Clone" and is based on APFS, Snapshots, and a command in Catalina. It does not use any of CCC's old technology and the target drive is erased every time. I tried it for the first time today and to my amazement it took somewhere between three (3) and five (5) minutes to clone the recovery drive, the system volume and the data volume to an external TB3 connected SSD. (admittedly the external SSD is really fast but less than five minutes!!!!)

Originally Posted By: artie505
I can't argue with that, but do you think Apple's locking down /Apps & /Apps/Utilities so unnecessary ones can't be culled really contributes to security? (I'd love to get rid of 19 + at least 3, respectively.)

I am not sure what you are referring to. Other than some Apple Apps and Utilities that are used elsewhere in MacOS and/or other Apps I have no problem deleting apps and utilities such as Mail in MacOS 10.15.3. All that takes is entering an admin password when prompted which I take as an "are you sure" step. That is unchanged from OS X 10.0. If you are referring to Catalina's write only system volume it contains the actual system kernel and support code that has never been deletable in the past. Putting it in a read only volume simply adds an additional layer to hide the code from hackers and the ignorant and make it much more difficult for them to damage. Applications, preference files, application support, users, etc are all in the DATA volume.

Last edited by joemikeb; 12/21/19 05:26 PM. Reason: add CCC comment
If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein