dtidmore

MacPro said:

No but running Terminal from the 10.3 partition you'd  still be left with the 10.13 recovery partition and in the particular situation I was trying to explore that would surely be problematic wouldn't it as I was wanting to have a virgin SSD to initialize for 10.12 and ..... oh heck I don't know lol.  Let me know how it went.

As to CCC being up to speed, it can as of my last reading still not make a bootable clone off of a 10.3/APFS disk on an HFS+, but I may have read that incorrectly.  I'll have to go back and re read the notes.  I haven't even tried so perhaps I should.  My entertainment was deleting the damn boot APFS SSD and re using the same SSD as HFS+.

Ok, first off, CCC's latest beta CAN read APFS and create a bootable clone of an APFS volume to an external HFS+ volume (I just did IT!)

Second, the terminal command diskutil apfs deleteContainer disk# works perfectly.  You have to use diskutil apfs list to determine the disk# assigned to the APFS container.  It leaves you with an HFS+ formatted volume (or two if you start with a Fusion Drive).  Yes, EVERYTHING on the APFS volume is GONE, so a clone becomes essential unless you want to just start with nothing more than a vanilla macOS install.

I am now running my High Sierra environment that was on an AFPS Fusion volume on a HFS+ Fusion Volume.  Took most of the day to compete the steps.

So, I started with a so-so working APFS 10.13 PB2 environment.
After loading up the 30 day trial of CCC (latest beta), I was able to make a clone to an external FW drive.  Presently while CCC beta can READ APFS, it can ONLY write HFS+, so the clone IS HFS+ but this is what I wanted anyway.

Then I rebooted into the clone and verified that while slow (FW800) it was fully operational.

Then I opened up terminal mode (remember I am in 10.13 at this point) and issued the diskutil apfs deleteContainer command, which removed the APFS container as well as the Fusion drive linkages

Then I recreated my Fusion drive (4 additional terminal commands) formatted as HFS+

Then I downloaded a fresh copy of the HS PB2 and had it install to the newly reconsitituted Fusion Drive.

Then I did a migration of the CCC cloned data over to the Fusion drive

After I allowed the kernel extensions to load (SIP has been tightened up in HS), everything came up.

Of course the majority of time was spent in making the CCC clone (about 2.3 hours) and then the migration back of my data once I had a clean HS install.  The actual APFS container deletion and Fusion Drive recreation took maybe 15 minutes total.  

I could have just as easily restored my 10.12.5 clone rather than installing a fresh copy of 10.13 and migrating my 10.13 data.  I wanted to give 10.13 a chance as the issues I was starting to see were all APFS related.  

Yes, the key to this is to start with a clone or clean install of 10.13 so that you can boot into it and then remove the APFS mess on your normal boot drive.

First, by design, each partition IS its own world and High Sierra still supports HFS+ completely.  On my machine I have a DIY Fusion Drive and the HDD is partitioned such that most of it belongs to the Fusion Drive but I also have a sandbox partition that I use for whatever.  In addition there is the recovery boot EFI partition that is actually an MS-DOS FAT32 partition!  I used the inline APFS conversion during the install of High Sierra and had no issues.  The Fusion Drive converted over to APFS and the sandbox partition remained HFS+.   How you format any given partition is separate from the partition itself.  

wiggin said:
As I understand it Apple will not certify a device that would bridge to other technology standards. 

This is NOT correct.  Phillips Hue and Insteon BOTH have Apple approved bridges that connect their respective non-homekit networks of devices into a HomeKit environment. What Apple has forbidden is the bridging of any "entry" devices such as garage door openers or door locks via bridges.  Light switches, motion sensors, environment sensors, etc CAN be bridged and participate in a HomeKit HA environment.  Allowed non-HK native products participate just as fully in a HK environment as native ones (I know because I am doing it already).  But what ONLY HK brings to the table presently is insane good security.  Apple adopted a key length in excess of 3000 bits running against an elliptical curve algorithm while most current HA products on the market offer weak security at best.  I will gladly pay to replace, perfectly functional, non-HK devices with native HK equivalents as they come to market, even if they come in at a higher price as I simply take security very seriously.