Clone (rsync) of 10.14 startup drive fails to boot

Config:

Stock MacBookPro10,1

10.14b11 (18A389)

Terminal added to Full Disk Access


Cloning an APFS FileVault startup volume to a USB3 HDD HFS+J external volume (formatted using DiskUtility) fails to boot. The verbose log has entries like:


"Warning: kextd unavailable"

"com.apple.xpc.launchd[1] <Error> rootless-init: signaled: Segmentation fault: 11"

...

"com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system) <Critical> No task-access server configured! The system will not get very far."

... more setup and then eventually it gets into this infinite loop of:

"AppleKeyStore: operation failed (pid: 241 sel: 7 ret: e00002c2 '-536878286' -100000)"

...Where this pid is incrementing by 1 forever. It will also print a block of:

"Can't get kextd port."

... And then loop into the AppleKeyStore messages again


I have not tried APFS->APFS (generally because APFS is slow and tends to get corrupted on HDDs), nor have I tried HFS->HFS.


But, APFS->HFS worked (and still works) in 10.13.x.


My clone procedure is:


- Format external drive as HFS+J, then

sudo diskutil enableOwnership disk2s2
sudo rsync -xrlptgoEvHS --progress --delete / /Volumes/Clone
sudo bless --folder /Volumes/Clone/System/Startup/CoreServices --bootefi

I then option-boot to the disk picker and select the Clone drive.


Diskutil layout:

$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.1 GB   disk0s2
   3:       Apple_KernelCoreDump                         655.4 MB   disk0s3


/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.1 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            148.1 GB   disk1s1
   2:                APFS Volume Preboot                 53.4 MB    disk1s2
   3:                APFS Volume Recovery                512.1 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4
   5:                APFS Volume CloneTest               2.3 MB     disk1s5


/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS Clone                   999.9 GB   disk2s2


rsync did print a few "operation not permitted" warnings but they were all for folders that were restricted in 10.13 too (generally in "/var/folders/bs/<uuid>/0").


Any ideas on how to fix this?

Replies

I am trying to debug the same problem and I get the same behaviour and verbose boot logging.


In my case the clone was created using a different native macOS utility (that I still maintain) that is able to create bootable clones for 10.13. and earlier without issues.


In addition to the original post I have also gone through the process of testing this with an APFS destination volume (which involves creating a Preboot volume etc), and once I get to the point of being able to bless and boot from this volume, it experiences exactly the same issue.

As such I conclude that HFS/APFS is NOT the issue here.


Unfortunately I could not find any official documentation that would help to determine what is different in the 10.14 boot process and what needs to be taken care of differently in a clone process.


Any hints from engineering would be greatly appreciated!

You mustn't copy ".PKInstallSandboxManager" and ".PKInstallSandboxManager-SystemSoftware", add them to rsync's exclusions, or delete these two from the destination drive and try to boot.

Thanks, but this does NOT resolve the issue.

Further to my last response, I have in the meantime identified the cause for the boot issue.

The reason why it is not booting is because it is not allowed to load any of the copied kernel extensions. This ultimately leads to the kextd logging but there are log lines before that, that say that standard kexts have an "invalid signature".


For a reason I do not quite understand yet, a normal copy of a kernel extension to another volume now gets flagged as suspicious and will not load with SIP enabled.


You will find that the same unchanged system will boot fine with SIP disabled.