Error installing High Sierra on Fusion Drive

[cccip]

Thanks. This is very interesting. In my situation fusion drive shows up in Clover (as well as Recovery HD partition) and I can boot OSX or Recovery from it with no issues.
Just can't get a second part of the supplementary to start...

UPDATE:
slosho, I've managed to figure out what was wrong with your guide and successfully applied update
1. You don't have to mount "Recovery HD" partition from your Fusion drive. Mount "Boot OS X" instead to get to "com.apple.boot.P/Library/Preferences/SystemConfiguration", usually it is 3rd partition of your 1st CoreStorage group disk
2. There is no need to boot from USB drive to edit the file, but once you save it & reboot, Clover must be started from another physical disk (here goes your extra USB disk), otherwise 2nd part of update will report "The path /System/Installation/Packages/OSInstall.mpkg appears to be missing or damaged" error (thx 43n79w).

 

[Adam1203]

So with all of this info, do you guys think this is a clover issue, or an issue with the way macOS performs its updates/installs on Fusion drives?

 

[cccip]

So with all of this info, do you guys think this is a clover issue, or an issue with the way macOS performs its updates/installs on Fusion drives?

Guess more related on Clover handling CoreStorage, cause installing same update on a single drive is a piece a cake.

 

[slosho]

Guess more related on Clover handling CoreStorage, cause installing same update on a single drive is a piece a cake.

I agree. My theory is that Clover is looking for the various boot files in their original location and doesn't realize that they are located elsewhere during the update routine.

 

[slosho]

slosho, I've managed to figure out what was wrong with your guide and successfully applied update

Glad you were able to get it to work cccip. For whatever reason, it looks like our hacks are booting from different locations. Sorry for the confusion!

 

[cccip]

Don’t be sorry mate, you’ve made my day

 

[43n79w]

Was anyone able to apply the 10.13.1 update using this approach? I’m getting a kernel panic on startup that referenced a mismatch in UUIDs for libkern.

EDIT:
I was able to get the update to apply by changing the argument auth-root-dmg to just root-dmg in the plist file.

 

[yy0c]

Was anyone able to apply the 10.13.1 update using this approach? I’m getting a kernel panic on startup that referenced a mismatch in UUIDs for libkern.

EDIT:
I was able to get the update to apply by changing the argument auth-root-dmg to just root-dmg in the plist file.

Trying to apply the 10.13.1 update, oddly I found that every time I reboot my hack, the modified "com.apple.Boot.plist" went back to unmodified, any thoughts?

 

[alenchev]

I have solution for this problem. Start install update. After first reboot you have a kernel cache error. Reboot to recovery hd (need cp, mkdir, rm skill) or to working system (install OS to flash or external disk). You must put files from com.apple.boot.* folder to other. Your Boot OS X disk must look like:

Boot OS X

|_com.apple.boot.*

|_ Library -> Preferences -> SystemConfiguration -> com.apple.Boot.plist (key and sting about kernel cache in this plist must be deleted)
|_ System -> Library -> PrelinkedKernels -> prelinkedkernel
|_ usr -> standalone -> i386 -> EfiLoginUI -> Lucida13.efires, disk_passwordUI.efires, recoveryUI.efires, Lucida13White.efires, flag_picker.efires, recovery_user.efires, appleLogo.efires, guest_userUI.efires, sound.efires, battery.efires, loginui.efires, unknown_userUI.efires​

|_System

|_Library -> CoreServices -> .disk_label, .disk_label_2x, .disk_label.contentDetails, .root_uuid, PlatformSupport.plist, SystemVersion.plist, boot.efi​

After do this - reboot.

 

[slosho]

I have solution for this problem. Start install update. After first reboot you have a kernel cache error. Reboot to recovery hd (need cp, mkdir, rm skill) or to working system (install OS to flash or external disk). You must put files from com.apple.boot.* folder to other.

Cool! I think this proves that the error is related to Clover and/or the OS insisting on looking for the boot files in their “normal” locations rather than the directory structure created by the first-stage installer.