Upgrade failure from 10.14.6+ to 10.15.3 SOLVED!!

[exquirentibus]

I have a working 10.14.6+ system and am attempting to directly upgrade to 10.15.3.

I'm using 5104 CloverHacky and have 10.14.6+ running on a bootable Crucial SATA SSD.

A Samsung 960 Pro NVMe is also visible (no way to disable with GA=Z270XP-SLI).

Kexts in /L/E

very latest AppleALC, WEG, Lilu, FakeSMC installed into /L/E. USBInjectAll, XHCI-unsupported, IntelMausi are also installed in /L/E.

Kexts in Clover Kext Other (InjectKexts=Detect)

AppleALC, WEG, Lilu, FakeSMC

UEFI drivers

from OcQuirks Rev 17:
FwRuntimeServices.efi
OcQuirks.efi
OcQuirks.plist

from 5104 CloverHacky
UEFI\FileSystem\ApfsDriverLoader.efi

ACPI/patched

custom SSDT-USB.aml created when getting 10.12.x running.

What happens during upgrade to 10.15.3

After 11 minutes, it restarted. I selected the 'Install' choice

After 3 minutes, it restarted, chose 'Install' choice

After 1.5 minutes got white Apple dialog saying it was installing on the SSD

When it finally restarted (and no longer showed the 'Install' choice), I then got the appleNVMe Assert failed when using -v

appleNVMe Assert failed: (0 != DATA) panic(cpu 4 caller 0xffffff8811a652fa): Kernel trap at 0xffffff7f93ff23d0, type 14=page fault

even though I'm not booting from the NVMe drive.

I know the exact same hardware I'm using works with 10.15.x as another user I'd worked with previously has 10.15.x working fine (but I can't reach him for his EFI).

As I believe the EFI folder is setup correctly with kexts and drivers, and 10.14.6+ has no issues booting from the same EFI, possibly my config.plist has something that 10.15.x doesn't like (as I tried a month ago to upgrade the NVMe directly with 10.15.2 and also tried formatting the NVMe and installing from scratch).

The 3 images include all of the -v output.

The 2nd image shows the appleNVMe Assert failed and I'm including my entire EFI.

I've been searching around for hours, but ... haven't come up with a solution. I'm thinking something in the config.plist is not compatible with 10.15.3?

 

[donw35]

maybe you should remove the kexts from /L/E reduce the redundancy

try putting SSDT-EC.asml in ACPI/patched and see what happens.

 

[exquirentibus]

maybe you should remove the kexts from /L/E reduce the redundancy

try putting SSDT-EC.asml in ACPI/patched and see what happens.

There shouldn't be any redundancy. With (InjectKexts=Detect), no kexts will be injected if they exist in /L/E. Or, am I misunderstanding you?

There's definitely movement towards ONLY having kexts in Clover/other (if that's what you mean) - but I'm unclear on whether the final verdict is in yet?

That becomes more of a problem with 10.15.4 - but with the right settings, it may not be a problem at all - as developers have to have a way to run unsigned kexts and apps when testing?

I did locate a detailed 'tech note' on steps for creating SSDT-EC.aml that's specific to one's computer (not sure if the 'powers that be' like links to other sites, so I won't post it). I'll have to read up on what exactly that does, but at the moment I'm unclear on why that's needed? It does seem to require generating it for a specific motherboard.

What about my setup indicates that I need a custom SSDT-EC.aml - and is this a change specific to 10.15.x?

 

[donw35]

of course its my opinion, I like to keep it a simple as possible, I have put kexts in the EFI kexts/other folder, been doing this since CLOVER started being the boot loader of choice (many years).

SSDT-EC.aml was need in 10.15.2 and up if I remember correctly. I have had to use it on all my systems in the sig. will not boot without it.

for me, I keep all my drivers and kexts in the EFI Folder, this enables troubleshooting without tampering with the OS partition.

 

[exquirentibus]

Interesting about the SSDT-EC.aml being needed for 10.15.2. Did you generate it for each machine specifically? I'll definitely have to try that sometime today - I generally prefer to have the source code on Github somewhere that I can look at.

I guess I've been in the Installing 3rd Party Kexts in /Library/Extensions camp as there seem to be a number of benefits - and of course, drawbacks such as making it less easy to deal with. I think I actually moved them into /L/E from Clover/other to get 10.14.6 to install, but ... I could be confused?

I have no idea of how many clueless mistakes I'm making as Hackintoshes are a very complex problem. Sometimes you just have to sacrifice a chicken to the Gods and hope for the best!

The developers of Hackintool, WEG, Lilu, etc. - and the new Clover app I've been reading about - have really made things a lot easier but it's definitely not a painless procedure ... yet.

 

[exquirentibus]

i just tried your SSDT-EC.aml. There was no effect.

Upon more research, SSDT-EC.aml is related to USB power and the steps to take to see if you need it are outlined on TonyMacx86 here.

I already have SSDT-USB.aml in my Clover/ACPI/patched (compiled specifically for my motherboard a few years ago which sets up the USB ports properly and also gives them power) whereas these settings below do show up in System Information (step 6 in the above link):

• Current Available (mA):
• Current Required (mA):
• Extra Operating Current (mA):
• Sleep current (mA):

If you want to read up on how to do that, I think the definitive guide is here.

So, unfortunately - SSDT-EC.aml isn't a universal fix for 10.15.x - and you are probably better off generating your own custom .aml specific to your motherboard that really sets things up properly.

And, unfortunately, I'm still unable to upgrade. My best guess is the config.plist contains something 10.15.x doesn't like (as I have no issues in 10.14.6+). But, how to figure that out?

 

[P1LGRIM]

So, unfortunately - SSDT-EC.aml isn't a universal fix for 10.15.x

Catalina interacts with the EC device.
If your system does not have an EC device (named as EC) then SSDT-EC.aml will provide one for you.
Failure to 'find' the EC device often results in a stall at apfs_module_start;1683.
If your system has an EC device that is not named as EC then all that is required is a simple rename patch in the config.plist.

 

[exquirentibus]

Catalina interacts with the EC device.
If your system does not have an EC device (named as EC) then SSDT-EC.aml will provide one for you.
Failure to 'find' the EC device often results in a stall at apfs_module_start;1683.

I agree - I've seen that 1683 error in many threads.

However, I have a custom SSDT-USB.aml compiled for my motherboard (included in the zipped EFI in post #1).

I'm including an image of the IORegistryExplorer that seems to indicate I have an EC device, unless I'm missing something basic (which is often the case, unfortunately!!).

If that is the EC device that I need (and that's not the issue), do you have another suggestion? My gut tells me that something about my config.plist is causing the problem, as it gets all the way thru the upgrade and fails at the very end from a working 10.14.6+ upgrade to 10.15.3.

I'm unclear on how to determine the cause - and am reading thru the docs on SourceForge Clover docs.

Do you think if I used clover-genconfig to generate a new config.plist this would clear out the accumulated detritus (orginally setup for Sierra and updated for Mojave)? I really don't know how to correctly generate a new config.plist or which plain vanilla config.plist I should start with?

 

[P1LGRIM]

I have a custom SSDT-USB.aml compiled for my motherboard

You seem to have missed the point completely.
In this case the SSDT-EC.aml has nothing to do with USB, it simply provides a named EC device.
Your SSDT-USB.aml does not do this.
However, you do not appear to be afflicted with the apfs_module_start;1683 problem.
Post #7 was my attempt to explain the function of SSDT-EC.aml to you as you appeared to be labouring under a misapprehension, clearly I failed in this respect.

 

[exquirentibus]

Ok, I now understand the purpose. If there was no EC device to begin with , my custom .aml would be useless, and the only want to deal with that is with that specific .aml that provides a named EC device.

Thanks for clarifying that, no sense having me confuse someone who might read this thread and get pointed in the wrong direction by my lack of knowledge.