[Guide] Intel Kaby Lake NUC7 using Clover UEFI (NUC7i7BNH, NUC7i5BNK, NUC7i3BNH, etc)

[jukes]

But you wrote "Edit 1: extracted the Problem Reporting files for the three configurations using the recovery terminal, and attached here."

What do you mean by "using the recovery terminal".

I mean that I can no longer boot into OSX on the system so I used the recovery terminal in order to copy the results onto a USB drive and post them here. This is probably irrelevant to the discussion, so ignore it. No results were produced during recovery.

What experiment?

What do you mean by "them"?

What was unstable?

You asked for the Problem Reporting files for the three configurations. Thus three (requested) experiments.

1. Boot with HDMI monitor attached.

This works fine, results generated and attached as HDMI.zip.

2. Hot-plug USB-C monitor.

This works fine, results generated and attached as HDMI_USB-C.zip.

3. Re-boot with only USB-C monitor attached.

This is totally unstable. Max OSX seems to think that there are two monitors (under Display Preferences) even though I've only got the USB-C connected. Every 30-ish seconds the monitor goes into auto-sleep mode, and needs to be power-cycled in order to get back to the OSX desktop. I generated the requested results for this configuration and attached them as USB_C.zip.

4. Hot-plug HDMI monitor.

You didn't ask for this one, but I was trying to see if hotplugging the other way would fix the instability. This has no effect. The HDMI monitor never gets output from OSX (just black screen) and also goes into sleep mode. No results were collected or uploaded.

"Waiting for DSMOS" without a corresponding "DSMOS has arrived" implies that FakeSMC is missing or not loading.

Yes, but I did not do anything w.r.t. FakeSMC during the experiments. I have been unable to reboot since collecting the USB-C results in #3 above due to the error. I do not know why performing #3 above would have any impact on FakeSMC.

Note that my request was for "Problem Reporting" files with three different ioreg captures.
No need to run full problem reporting procedures for each ioreg... (kextcache, EFI/Clover, other data would remain the same).

Oh, okay. I didn't know if there was something in Clover that would generate different results during a USB-C boot.

The ioreg you attached for the USB-C only case looks to have had HDMI connected as well. ?! Also, note that in that case it seems to have changed the connector-type to <00 04 00 00> for the HDMI, where as the one for HDMI_USB-C did not.

Well, these are the results that I got when I disabled the patches as suggested. The HDMI cable was connected but the monitor was powered off, which is how I've always hotplugged in the past. OSX Display Preferences did behave like there were two displays connected during the USB-C boot, even though there was not. Hotplugging the HDMI monitor in this configuration did not result in both monitors becoming active... OSX does not communicate with the hotplugged HDMI monitor. Presumably because it already thinks there's another monitor somewhere?

I don't know why the patch you recommended results in the above behavior for USB-C, and I don't understand why the DSMOS error is now occurring. I'll investigate a little more, but I may just have to do a clean re-installation.

 

[star-affinity]

No "Problem Reporting" files attached.
Read FAQ, "Problem Reporting" again. Carefully. Attach all requested files/output.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
Use the tool mentioned in the FAQ, that way it is less likely you'll omit something.

Yes, will do so when I find a time slot.

Booting without caches does not help. Is there a thread dedicated to fixing this problem? (I made no changes to anything, was just switching monitors and running the Problem Reporting commands. Could "sudo touch /System/Library/Extensions && sudo kextcache -u /" have caused a problem when run from the unstable USB-C configuration?)

Try to do in the Terminal.app touch /System/Library/Extensions
I also got boot problems after simply trying to clear the kext cache and the command above (omitting ”kextcache”) seems to have fixed it. I tried this because I read in the ”man page” for kextcache:

Caution: Incorrect use of kextcache can render a volume incapable of
startup. Installers and administrators should not use this program to
update system kext caches. Instead they should run touch(1) on the
/System/Library/Extensions/ directory of the installation target volume
after they have finished, which invalidates the existing caches and
causes the system to update all necessary kext caches.

 

[RehabMan]

3. Re-boot with only USB-C monitor attached.

This is totally unstable. Max OSX seems to think that there are two monitors (under Display Preferences) even though I've only got the USB-C connected. Every 30-ish seconds the monitor goes into auto-sleep mode, and needs to be power-cycled in order to get back to the OSX desktop. I generated the requested results for this configuration and attached them as USB_C.zip.

Same result with the original 2xDP patches enabled?

4. Hot-plug HDMI monitor.

You didn't ask for this one, but I was trying to see if hotplugging the other way would fix the instability. This has no effect. The HDMI monitor never gets output from OSX (just black screen) and also goes into sleep mode. No results were collected or uploaded.

Same question as above...
Sounds like your earlier conclusion that those two patches were causing instability with hotplug may be a bit inaccurate.

Yes, but I did not do anything w.r.t. FakeSMC during the experiments. I have been unable to reboot since collecting the USB-C results in #3 above due to the error. I do not know why performing #3 above would have any impact on FakeSMC.

Corrupt system volume?
Check in disk utility from recovery../

I don't know why the patch you recommended results in the above behavior for USB-C,

I don't know which patch you are referring to.

 

[RehabMan]

Yes, will do so when I find a time slot.



Try to do in the Terminal.app touch /System/Library/Extensions
I also got boot problems after simply trying to clear the kext cache and the command above (omitting ”kextcache”) seems to have fixed it. I tried this because I read in the ”man page” for kextcache:

Caution: Incorrect use of kextcache can render a volume incapable of
startup. Installers and administrators should not use this program to
update system kext caches. Instead they should run touch(1) on the
/System/Library/Extensions/ directory of the installation target volume
after they have finished, which invalidates the existing caches and
causes the system to update all necessary kext caches.

I have no problem using "kextcache -i /"... ever.

 

[jukes]

Same result with the original 2xDP patches enabled?

I don't know, I can no longer boot. Still working on that.

Same question as above...
Sounds like your earlier conclusion that those two patches were causing instability with hotplug may be a bit inaccurate.

To make sure we're on the same page, the thread for this issue comes through this post.

The problem that I was dealing with was that booting HDMI and hotplugging USB-C was working after a clean high sierra (apfs) installation. After running Post Installation from this thread hotplugging didn't work at all. You referred me to your post suggesting that I disable those two patches, which I did. This allowed me to again boot HDMI and hotplug USB-C (yay!).

Then you asked if I would send you the results from the different configurations (I assumed you wanted to see what happens when those patches are disabled).

I did this and those are the results that I uploaded.
- Booting HDMI and hotplugging USB-C seems fine.
- Booting USB-C was unstable.

You also suggested some alternative patches to test, which I will happily do, your work has been wonderfully helpful. My problem is that after the USB-C attempt I can no longer boot at all due to DSMOS. Repairing volumes/containers/disks makes no difference.

I'll probably just end up clean-booting again to get back to a working state. At that point I can see if booting USB-C is unstable prior to Post Install instructions, and if the other proposed patches work.

Thanks for working on this.

 

[jukes]

Try to do in the Terminal.app touch /System/Library/Extensions
I also got boot problems after simply trying to clear the kext cache and the command above (omitting ”kextcache”) seems to have fixed it.

I would love to try this, but I can't seem to boot, so I can't run Terminal.app. I can get into the terminal in the Recovery boot, but that loads the volume read-only so I can't touch that file. I'll probably end up re-installing, unless I can figure out how to deal with this problem. It's an apfs filesystem so I don't think my debian live boot can mount it.

Probably I should have picked HFS+.

 

[RehabMan]

To make sure we're on the same page, the thread for this issue comes through this post.

Yup. So far, I remember, which is what prompted my last question regarding re-confirmation of that result.
Because it seems at this point, there are still problems with your hotplug (this is not surprising) without that patch.

The problem that I was dealing with was that booting HDMI and hotplugging USB-C was working after a clean high sierra (apfs) installation. After running Post Installation from this thread hotplugging didn't work at all. You referred me to your post suggesting that I disable those two patches, which I did. This allowed me to again boot HDMI and hotplug USB-C (yay!).

Then you asked if I would send you the results from the different configurations (I assumed you wanted to see what happens when those patches are disabled).

I wanted to see what connector-type was doing with those patches disabled, and see if the results were the same as what I recorded here.

- Booting USB-C was unstable.

I guess you previously didn't test booting with USB-C (eg. your previous "normal scenario" was boot with HDMI, hotplug USB-C?).

You also suggested some alternative patches to test, which I will happily do, your work has been wonderfully helpful. My problem is that after the USB-C attempt I can no longer boot at all due to DSMOS. Repairing volumes/containers/disks makes no difference.

A fresh install may be in your future.
Suggest you avoid APFS.

 

[jukes]

Try to do in the Terminal.app touch /System/Library/Extensions
I also got boot problems after simply trying to clear the kext cache and the command above (omitting ”kextcache”) seems to have fixed it.

Worked!

I boot into recovery, started the terminal, unmounted the install disk, and remounted it as writable, then touched the SLE directory. Reboot and selected "without caches" in Clover. Boot process took quite some time, did not get stuck at DSMOS, but did restart back to Clover. Booted once again without any extra flags and started fine.

Thank you for this help.

 

[jukes]

Also, here is a few alternative patches. For these tests, disable the two patches: "0x59260002 0x59270004 2xDP, #1 of 2", "0x59260002 0x59270004 2xDP, #2 of 2"

alt#1 (this is the same as repo patches, but 0105 and 0204 reversed):
Comment: 0x59260002 0x59270004 2xDP, #1 of 2
Find: <01030303 00009003>
Replace: <01030202 00009003>

Comment: 0x59260002 0x59270004 2xDP, #2 of 2 (alt#1)
Find: <00000800 02000000 98040000 01050900 00040000 c7030000 02040a00 00040000 c7030000>
Replace: <02040a00 00040000 c7030000 01050900 00040000 c7030000 ff000000 01000000 20000000>

alt#2 (this keeps the connector counts same, but still moves 0105/0204 to @0, @1):
Comment: 0x59260002 0x59270004 2xDP, #1 of 1 (alt#2)
Find: <00000800 02000000 98040000 01050900 00040000 c7030000 02040a00 00040000 c7030000>
Replace: <01050900 00040000 c7030000 02040a00 00040000 c7030000 ff000000 01000000 20000000>

alt#3 (same as above, but reversed 0105/0204)
Comment: 0x59260002 0x59270004 2xDP, #1 of 1 (alt#3)
Find: <00000800 02000000 98040000 01050900 00040000 c7030000 02040a00 00040000 c7030000>
Replace: <02040a00 00040000 c7030000 01050900 00040000 c7030000 ff000000 01000000 20000000>

alt#4 (keeping 0105 in @1 @2, but nullify LVDS @0)
Comment: 0x59260002 0x59270004 2xDP, #1 of 1 (alt#4)
Find: <00000800 02000000 98040000 01050900 00040000 c7030000 02040a00 00040000 c7030000>
Replace: <ff000000 01000000 20000000 02040a00 00040000 c7030000 01050900 00040000 c7030000>

Okay, now that I can boot again I'll try these out. Quick question.

In emacs, my config.plist as Find/Replace as <data>...</data> where "..." is a sequence of letters (not hex) and `/` characters. you're listing hex values. Do I need to perform some sort of transformation of your values to paste them in using emacs?

 

[RehabMan]

Okay, now that I can boot again I'll try these out. Quick question.

In emacs, my config.plist as Find/Replace as <data>...</data> where "..." is a sequence of letters (not hex) and `/` characters. you're listing hex values. Do I need to perform some sort of transformation of your values to paste them in using emacs?

<data> in a plist is specified in base64.
My suggestion: DO NOT use a text editor to edit your config.plist. Use a plist editor only... such as Xcode or PlistEdit Pro.