Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

arsradu
arsradu
Posted
Posted

I am on the public beta 2 build, the issues are identical to DP4. 

Thanks for the info. :)

 

I know it doesn't help solve the issue, but for anyone interested in going back to DP3, without a fresh install of DP1, you can do that by installing just the DP3 combo update from Yosemite (assuming you didn't replace it with El Capitan, which is never recommended for beta softwares). I just tried it and it works. You just have to be careful to choose the right destination, of course. Not sure about going from Public Beta 2 to DP 3... But I guess there is only one way to find out. :)

Link to comment
Share on other sites
joe75
joe75
Posted
Posted

My 10.11 recovery HD didn't boot here as I get some invalid message.. (can't remember exactly what it was). I haven't tested it since. Will try again though..

 

I was referring only to the SIP enable in Recovery. I assumed it wasn't working at all yet and hadn't seen mention of someone trying it on an actual mac :D

@Pike, DP 3 kernel works if you are going to suggest people replace things

  • Like 1
Link to comment
Share on other sites
WaldMeister
WaldMeister
Posted
Posted

Thanks for the info. :)

 

I know it doesn't help solve the issue, but for anyone interested in going back to DP3, without a fresh install of DP1, you can do that by installing just the DP3 combo update from Yosemite (assuming you didn't replace it with El Capitan, which is never recommended for beta softwares). I just tried it and it works. You just have to be careful to choose the right destination, of course. Not sure about going from Public Beta 2 to DP 3... But I guess there is only one way to find out. :)

Would be easier to just install the kexts from the Clover folder to S/L/E. When updating or testing remove all the (ADDED) kexts except FakeSMC from S/L/E before a reboot. 

If after rebooting the kexts are still not being injected, at least FakeSMC will load, allowing you to boot to the desktop to install the kexts again. 

  • Like 1
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Extract Sandbox.kext from DP3 and give that a try.

This does not seem to make any difference. I still see the 'Not entitled to link kext' message.

I was referring only to the SIP enable in Recovery. I assumed it wasn't working at all yet and hadn't seen mention of someone trying it on an actual mac :D

Ah. Okay :)

Can boot Recovery HD here, i don't think is updated with DP4.

Maybe it's because I messed about with it previously. I will have to re-create it and try again some time.

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

The check is in kernel, so replacing Sandbox should either do nothing or trigger the error for all kexts... anyway, the best approach I still have in my mind is forcing Sandbox to load before injections. It is possible that Sandbox needs to initialize the rootless sandbox first before the kernel allows any kext management. Patching the check for the entitlement results in a kernel trap.

 

Edit: boot.efi no longer uses 'Driver-' entires. It's only a matter of time till the kernel kicks support for it in my opinion. :(

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

The check is in kernel, so replacing Sandbox should either do nothing or trigger the error for all kexts... 

I should have said it made no difference to the 'Not entitled to link kext' error.
 
What it did do is this:
post-331032-0-05263200-1437717687_thumb.jpg
 
And for ref, that 0x67 does not seem to have anything to do with the value of csr-active-config as when changing that I still see 0x67.
 
EDIT: or maybe I just f****d it as I can't seem to boot DP4 even with caches now. hmmm..
 
EDIT2: restored from a back up and tested again. Using DP3 sandbox.kext does still result with 'Not entitled to link kext' message. The messages shown in the screenshot I posted earlier did not appear first time I tried injecting kexts, instead the boot process just went as far as the bluetooth controller message as FakeSMC was not loaded. But I did get to see those messages in the above screenshot again after messing about more... not sure exactly what causes that.
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

The check is in kernel, so replacing Sandbox should either do nothing or trigger the error for all kexts... anyway, the best approach I still have in my mind is forcing Sandbox to load before injections. It is possible that Sandbox needs to initialize the rootless sandbox first before the kernel allows any kext management. Patching the check for the entitlement results in a kernel trap.

 

Edit: boot.efi no longer uses 'Driver-' entires. It's only a matter of time till the kernel kicks support for it in my opinion. :(

The extra kexts are not injected after the kernel cache is loaded?

 

Perhaps you should enable kext logging to see what is really going on.

 

And Apple no longer uses Driver- entries in boot.efi because that is work for the kernel.

 

What happens when you change the bundle ID to com.apple.kec.FakeSMC – so that it loads as an external kernel component?

 

@joe75,

 

Thanks. I was unaware of the fact that replacing the kernel was enough to get it booting.

 

@blackosx,

 

Thanks for testing.

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

And Apple no longer uses Driver- entries in boot.efi because that is work for the kernel.

 

It makes no sense that the kernel adds Driver- entries to DataHub Device Tree when it could store them internally as well - it was always boot.efi creating the entires and the kernel processing them. The processing code is still around, but as the creation code was purged, it will be only a matter of time till former is kicked as well.

  • Like 1
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

I don't know about anyone else or if its a hack thing but the SIP in recovery or the Security Configuration.app don't work for me, both still error.

Just rebuilt my recovery partition and run the security configuration app.

Is this the same error you get?

 

post-331032-0-09030200-1437734960_thumb.jpg

 

EDIT: This reminds me of trying to set csr-active-config nvram var from terminal within 10.10.4 or 10.11

$ sudo nvram csr-active-config="%00%00%00%00"
Password:
nvram: Error setting variable - 'csr-active-config': (iokit/common) general error
Can someone make DumpUefiCall during DP4 boot?

attachicon.gifDumpUefiCalls.efi.zip

 

I've passed a couple of dumps to Slice from my hack.

Can anyone make one a real Mac with DP4? I can't until next week.

  • Like 1
Link to comment
Share on other sites
WaldMeister
WaldMeister
Posted
Posted

Booted in to recovery and disabled SIP, i now have the following entry in my NVRAM: 

P70:~ Lex$ nvram -p
efi-boot-device	<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>89405C34-F6F2-4528-B423-78AF12238763</string></dict></dict></dict></array>
security-mode	none
SystemAudioVolumeDB	%ed
backlight-level	%d8%0a
SystemAudioVolume	7
efi-boot-device-data	%02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%04%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00p%f9o%11%00%00%00%004\@%89%f2%f6(E%b4#x%af%12#%87c%02%02%7f%ff%04%00
csr-active-config	g%00%00%00

Going to remove kexts and reboot now, to test if it works. 

 

Edit: No change. Except when i open the Security Configuration, the checkbox is unchecked. 

  • Like 1
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

Maybe it would be better to put the rather hacky ideas to solve this aside and try to cleanly mod prelinkedkernel. Catching it in-memory would be very hard, but I guess we could overwrite the file protocol, load prelinkedkernel, mod it and then return it already modded to boot.efi. Would save kernel patches, kicks the abandoned kext injection method and works as people are used to till Apple changes the format of prelinkedkernel. :)

  • Like 4
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Booted in to recovery and disabled SIP, i now have the following entry in my NVRAM:

 

 

Great to hear you got it to work without error.. I wonder what's different on your system to allow it to work?

EDIT: I booted in to the recovery HD earlier from Ozmosis without issue but still had the same error once applying the setting.

 

I have one MacBook with El Cap for test how can I help?

How can I use DumpUefiCall from real Mac?

There were instructions on projectosx but I'm thinking you could load it through refind.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...