Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30963 posts in this topic

Recommended Posts

Badruzeus
Badruzeus
Posted
Posted

OK, next release it will be.

I think, you are right with "Other" folder instead of "10.13" @Slice (I mean with r4243)...

 

Condition:

1. I placed my 3rd party kexts including FakeSMC on "/EFI/CLOVER/kexts/10.13/" dir

2. Updating 17A365 to 17A405 (APFS)

3. softwareupdate created a new "Entry Point" contains Install Datas

4. Booting new "Entry Point" with macOS: (Null) to complete update proccess

5. I got stuck with "kextstall AppleACPICPU, MCHC bla bla bla.." even using KextInject=Yes/Detect

6. I then force re-booting from Clover USB that contains FakeSMC & PS2Controller on "Other" dir

7. Repeat point 4 till Update succeeded.

 

Sorry, for report only. I'm not sure if the only one who got this issue but, it never happened with prev. Legacy HFS+ install (/kexts/10.13/ dir).

Thanks.

fusion71au
fusion71au
Posted
Posted

I think, you are right with "Other" folder instead of "10.13" @Slice (I mean with r4243)...

 

Sorry, for report only. I'm not sure if the only one who got this issue but, it never happened with prev. Legacy HFS+ install (/kexts/10.13/ dir).

Thanks.

 

@Badruzeus,

I don't think you're the only one.  @Matgen84 here and @cecekpawon here found that Clover did not determine correct "GetOSVersion" from boot.efi if booting into 10.13 installer.  Booting into an already fully installed 10.13 volume however is OK since in this scenario, Clover correctly detects 10.13.x is present.

 

Personally, I never had that problem because I always place my "essential" kexts for booting (FaskeSMC, Networking kext and VoodooPS2Controller for laptop) in /Other so these are always injected for all OS's and installer/recovery.  Those that have FakeSMC in /10.xx folders will have problems if Clover doesn't correctly determine the OS version.

 

@cecekpawon's diff patch in post#14841 seems to have fixed it  :).

 

 

 

@Slice,

I can confirm bug reported by @MakAsus in post#14838.  

 

After you escape out of the Kext Inject Management screen (just looking at the contents of the kext folders without selecting anything), then return to the Main Clover Menu, select macOS volume and press <Enter>, kexts not injected.

 

 

post-846696-0-32011700-1507516886_thumb.png

post-846696-0-19687700-1507516955_thumb.png

post-846696-0-94203600-1507516913_thumb.png

post-846696-0-41841800-1507516994_thumb.png

 

 

This does not happen if instead of returning to the Main Clover Menu, you select "Boot macOS with selected options" ---> everything works as expected and kexts are injected.

 

post-846696-0-49830800-1507517037_thumb.png

 

 

Attached preboot.log for r4244 (after performing actions described above) seems OK but boot hangs.

Clover_v2.4k_r4244_cecekpawon_patched.pkg.zip

preboot_r4244.log.zip

  • Like 4
Badruzeus
Badruzeus
Posted
Posted

@Badruzeus,

 

I don't think you're the only one.  @Matgen84 here and @cecekpawon here found that Clover did not determine correct "GetOSVersion" from boot.efi if booting into 10.13 installer.  Booting into an already fully installed 10.13 volume however is OK since in this scenario, Clover correctly detects 10.13.x is present.

 

Personally, I never had that problem because I always place my "essential" kexts for booting (FaskeSMC, Networking kext and VoodooPS2Controller for laptop) in /Other so these are always injected for all OS's and installer/recovery.  Those that have FakeSMC in /10.xx folders will have problems if Clover doesn't correctly determine the OS version.

 

@cecekpawon's diff patch in post#14841 seems to have fixed it  :).

OK, thanks. It seems like I missed this diff patch last night.

  • Like 1
apianti
apianti
Posted
Posted

Source/explaination please?

 

Ah, realistically you probably only need 0x43, with unrestricted NVRAM being most important in this situation. Something to do with the filesystem because of the way unix treats everything as one filesystem. And then unsigned kexts because you have to inject FakeSMC at some point (even if it's only for the installer), which is not signed, but I think that for some reason this also causes problems with locked NVRAM that gets moved. Basically instead of failing to have working NVRAM, it's refusing to even boot without it - I guess that's secure, lol.

mhaeuser
mhaeuser
Posted
Posted

Ah, realistically you probably only need 0x43, with unrestricted NVRAM being most important in this situation. Something to do with the filesystem because of the way unix treats everything as one filesystem. And then unsigned kexts because you have to inject FakeSMC at some point (even if it's only for the installer), which is not signed, but I think that for some reason this also causes problems with locked NVRAM that gets moved. Basically instead of failing to have working NVRAM, it's refusing to even boot without it - I guess that's secure, lol.

I didn't try HS yet, but no previous release needed SIP restrictions lifted for injecting kexts, the validity was always checked when compiling prelinkedkernel... Also idk why one would need unrestricted NVRAM because of AptioFix vs AptioFix2

MakAsrock
MakAsrock
Posted
Posted

@Badruzeus,

I don't think you're the only one.  @Matgen84 here and @cecekpawon here found that Clover did not determine correct "GetOSVersion" from boot.efi if booting into 10.13 installer.  Booting into an already fully installed 10.13 volume however is OK since in this scenario, Clover correctly detects 10.13.x is present.

 

Personally, I never had that problem because I always place my "essential" kexts for booting (FaskeSMC, Networking kext and VoodooPS2Controller for laptop) in /Other so these are always injected for all OS's and installer/recovery.  Those that have FakeSMC in /10.xx folders will have problems if Clover doesn't correctly determine the OS version.

 

@cecekpawon's diff patch in post#14841 seems to have fixed it  :).

 

 

 

@Slice,

I can confirm bug reported by @MakAsus in post#14838.  

 

After you escape out of the Kext Inject Management screen (just looking at the contents of the kext folders without selecting anything), then return to the Main Clover Menu, select macOS volume and press <Enter>, kexts not injected.

 

 

attachicon.gifKext Inject Management.png

attachicon.gifOther.png

attachicon.gifReturn to Main Menu.png

attachicon.gifClover Main Menu.png

 

 

This does not happen if instead of returning to the Main Clover Menu, you select "Boot macOS with selected options" ---> everything works as expected and kexts are injected.

 

attachicon.gifBoot macOS with selected options.png

 

 

Attached preboot.log for r4244 (after performing actions described above) seems OK but boot hangs.

 

A small clarification: This does not happen if  instead immediately boot from selected disk, you select boot from another disk, or entering to shell and type "exit", and only then boot from selected disk.

  • Like 2
mhaeuser
mhaeuser
Posted
Posted

No need to take OSVersion from loaded boot.efi if we already have valid OSVersion grabbed from plist.

We can apply OSVersion value from loaded boot.efi to all OSTYPE_OSX (not just installer) with no OSVersion as a last attempt.

 

Do yourself a favor and use a single value that will never ever lie...

 

instead of guessing maybe just use the kernel version thats available ?

cecekpawon
cecekpawon
Posted
Posted

+1. I totally agree with you and of course lord bs0d (really missed him). I also remember he suggest to convert version string to int for easy compare (in case of micky macos patch filter based on os version). It requires lot of work. To read kernel macho on this project seems on progress (I hope). The problem is, Clover decide to do some kexts filtering right on GUI far before boot.efi being loaded :)

  • Like 2
arsradu
arsradu
Posted
Posted

Hi guys, is Clover supposed to be able to do kext injection with SIP enabled? In other words, should you still be able to boot with SIP enabled?

 

Not complaining. :)) Just wondering. Cause, for as far as I know, in order for kexts to load, you need at least CsrActiveConfig 0x3. Apparently you can boot just fine with CsrActiveConfig 0x0. Which is great, cause otherwise I don't know how the heck I would have been able to install the Nvidia Web Driver with SIP enabled today.

 

Please, forgive my ignorance and correct me if I'm wrong. I just remember that we weren't able to boot with SIP enabled (since FakeSMC wasn't loaded anymore). That's why I found it interesting that somehow I was able to do that now. And also curious if something has changed in the meantime.

MICKHAEL
MICKHAEL
Posted
Posted

Yes, you can boot with sip enabled and fakesmc (and other kexts) are injected (from EFI)

Strange) always use osxaptiofixdrv with csr 0x67, changed to osxaptionfix2drv and csr to 0x3/0x0. On first reboot/boot all ok, but after shutdown - no more, just hanging to crossed circle... any idea?

 

Sent from my Nexus 4 using Tapatalk

apianti
apianti
Posted
Posted

Yeah, don't change SIP restrictions. Change it back to 0x67.


I didn't try HS yet, but no previous release needed SIP restrictions lifted for injecting kexts, the validity was always checked when compiling prelinkedkernel... Also idk why one would need unrestricted NVRAM because of AptioFix vs AptioFix2

 

It's not linking a prelinked kernel... It's pushing them onto the datahub to be loaded by the kernel, it should be checking them, or SIP is not working. AptioFix breaks NVRAM if it is SMM locked.

mhaeuser
mhaeuser
Posted
Posted

It's not linking a prelinked kernel... It's pushing them onto the datahub to be loaded by the kernel,

 

I was talking about macOS, not Clover... as I said, I never heard hat SIP influences kext injection, while it does influence which kexts end up in the prelinkedkernel

 

AptioFix breaks NVRAM if it is SMM locked.

 

Well, it uses the exact same logic as AptioFix2 to prevent that, never heard of it not working but AptioFix2 working.

TheRacerMaster
TheRacerMaster
Posted
Posted

It's effectively like loading a kext from the terminal, which are checked when linked just as when prelinked.

Is this fully accurate? I've been booting with SIP enabled for a while now (on another machine), and haven't had any issues with kext injection working. FakeSMC/etc are still loading (with kext injection and with SIP enabled).

  • Like 3
Ramalama
Ramalama
Posted
Posted

Hi guys, can we fix this:

 

https://www.youtube.com/watch?v=tf4HkjaiOi8

 

look at second 2... there are messages...

 

Happens on all my Hackintoshes with apfs...

 

Im hoping its not already answered :-)

 

Cheers :-)

Badruzeus
Badruzeus
Posted
Posted

Hello, after installed 10.13.1 Beta 2 (17B35a) with APFS I always get this messages on verbose logs:

1. "considerRebuildOfPrelinkedKernel org.netkas.FakeSMC triggered rebuild (I placed FakeSMC v3.5.0 on /kexts/10.13 dir)

2. "kextd stall(0), (60s): 'NVDAHal', 'NVDAgl', 'NVDA,Display-A' (I patched my DSDT - GFX0 using this)

3. (this one appears before verbose; I'm not sure related to Clover or not, sorry):

RegisterRestartDataProtocol called. 0x12345678
RestartData protocol installed successfully.
++++++++++++++++++++++++++++++++++++++++++++++

FYi, I'm using Legacy r4244 (with @cecekpawon patch). Thanks.

bootlog.log_a43sj_r4244.txt.zip

EFI_r4244_boot7.zip

SavageAUS
SavageAUS
Posted
Posted

Hi guys, can we fix this:

 

https://www.youtube.com/watch?v=tf4HkjaiOi8

 

look at second 2... there are messages...

 

Happens on all my Hackintoshes with apfs...

 

Im hoping its not already answered :-)

 

Cheers :-)

It's just a debug log of such for apfs. There is a modded apfs floating around from cecekpawon that gets rid of / reduces the lines that you see.

 

Sent from my SM-G930F using Tapatalk

  • Like 1
 Share
Go to topic listing
×
×
  • Create New...