Jump to content
ErmaC

Clover General discussion

19,137 posts in this topic

Recommended Posts

Hi guys,

 

trying to determine actual cpu speed in my Sierra. Installed Intel Power Gadget, but that software only crashes and does not run. Any idea how to determine the actual cpu speed?  Wasn't there a kind of fakesmc extension for that?

 

Do I need to enable the XPCM option for my haswell cpu?

 

Background is that my system started to become maybe a bit slow since some time, maybe it's caused by the nvidia web driver or no proper cpu pm. But I have written all values into ssdt using ssdtprgen.

 

I believe there is a kext to go along with ssdtprgen that you load from the terminal, let it go while you do some activities, then come back and unload it. It should have spit out all the different multipliers your CPU reached, which you can then use to determine your frequency (usually times 100MHz)

Also another question:

 

I now for the first time installed clover to the EFI partition and copied my config over there. It boots into the clover menu, but stuck after starting boot at "++++++++++++". All kexts from my other clover existing, including fakesmc. Also the config is properly loaded (which works fine with the no-efi-clover installation). Any idea how to fix?

 

UEFI boot? Do you have an aptiofix?

Share this post


Link to post
Share on other sites
Advertisement

Ah thank you!  Will try that ssdtgen kext, right!

 

 

I used osxlowmemfixdrv until now, it worked. Will try aptiofix now..

 

EDIT: Thank you so much, you saved me lot of time. That was the problem aptiofix works nicely.

Share this post


Link to post
Share on other sites

Ah thank you!  Will try that ssdtgen kext, right!

 

 

I used osxlowmemfixdrv until now, it worked. Will try aptiofix now..

 

LowMemFix only works for Insyde firmware because it releases a memory region that is in the way but is non-consequential. You shouldn't use it on any other firmware, and probably not even really at all.

EDIT: Thank you so much, you saved me lot of time. That was the problem aptiofix works nicely.

 

Try to use aptiofix2 if you can first, it works better. Aptiofix as a fallback.

Share this post


Link to post
Share on other sites

works, too :)  Curious, what is better in aptiofix2?  apianti, since I have the opportunity to have access to your knowledge, can you answer me these questions:

 

- disk numbers in diskutil seem to be random, so boot drive sometimes is disk0, sometimes disk1, etc.  Is that normal?

 

- Should I delete HFSPlus.efi from drivers64UEFI and always use VBoxHfs-64.efi instead?

 

- Should I delete NTFS.efi from drivers64 and always use GrubNTFS-64.efi instead?

 

- Will a High Sierra Update wipe my efi partition config? EDIT: Installing it on a SSD, so likely there will be a APFS conversion

 

- Should I activate KernelXCPM on my Haswell?

 

- Are there any new options to be added to successfully boot into High Sierra (coming from Sierra)?

 

- The bit depth of the graphics seem to be reduced to 16bit per channel, this is since the first time of Nightshift activation. Same happened with an AMD gfx card before. Even if I turn off nightshift, the reduction is visible in graphical transitions (showing a step effect). Any idea here?

 

EDIT: 

- If I then boot from an APFS High Sierra SSD and will backup to an HDD using CCC, will I be still able to directly boot from the HDD (still containing HFS+)?

 

- Does fakesmc have any effect on cpu/system performance?

Share this post


Link to post
Share on other sites

works, too :)  Curious, what is better in aptiofix2?  apianti, since I have the opportunity to have access to your knowledge, can you answer me these questions:

 

Aptiofix2 does not relocate anything in memory so it should not interfere with anything, whereas for some reason aptiofix does interfere. Aptiofix can break firmware runtime, like nvram.

 

 

- disk numbers in diskutil seem to be random, so boot drive sometimes is disk0, sometimes disk1, etc.  Is that normal?

 

Yes, it is the order they are enumerated, one disk may be busy and take longer to respond although it comes first in actual order. Those are just identifiers for the kernel for that boot, they no longer matter after restart/shutdown. That's why everything is identified by the partition identifier.

 

 

- Should I delete HFSPlus.efi from drivers64UEFI and always use VBoxHfs-64.efi instead?

 

That's your preference. VBoxHFS is open source but lacks features (it's slightly slower as well), however it seems to work better with some misbehaving firmwares. HFSPlus is closed source driver extracted from Apple firmware, it's fast and has more features, such as core storage RAID support and filevault.

 

 

- Should I delete NTFS.efi from drivers64 and always use GrubNTFS-64.efi instead?

 

You do not need an NTFS driver at all. Windows boots from the EFI partition so can be read directly from the firmware already. If there is any reason to have one I do not know what it is.

 

 

- Will a High Sierra Update wipe my efi partition config? EDIT: Installing it on a SSD, so likely there will be a APFS conversion

 

Good question, I'm not sure but I see no reason why it would touch the EFI partition. I haven't seen or heard of it.

 

 

- Should I activate KernelXCPM on my Haswell?

 

Can you boot without it/other patches? Is your power management working? Have you tried? Does it work? Does it give better performance? Beats me.

 

 

- Are there any new options to be added to successfully boot into High Sierra (coming from Sierra)?

 

Not that I'm aware of but it could be different depending on your hardware and kexts.

 

 

- The bit depth of the graphics seem to be reduced to 16bit per channel, this is since the first time of Nightshift activation. Same happened with an AMD gfx card before. Even if I turn off nightshift, the reduction is visible in graphical transitions (showing a step effect). Any idea here?

 

Might have something to do with injecting the wrong properties for the graphics, I am unsure how to even check that. Maybe check out ioreg for anything interesting.

 

 

- If I then boot from an APFS High Sierra SSD and will backup to an HDD using CCC, will I be still able to directly boot from the HDD (still containing HFS+)?

 

An APFS partition is a container and has another structure inside that contains the volumes like recovery, system, etc. It would not back up properly to a HFS+ partition. So probably no, but maybe it does something to convert either the HFS+ to an APFS or the APFS content to work on the HFS+. Really no idea...

 

 

- Does fakesmc have any effect on cpu/system performance?

 

Not anything meaningful, and not anymore than an actual SMC being present would. FakeSMC is just using values stored in memory to emulate that they were retrieved from an SMC, which Macs have but PCs do not.

Share this post


Link to post
Share on other sites

I wanted to install the beta 5 of 10.13.1 and ran into some issues with r4265:

 

- macOS Build is not being recognized, thus had to copy my kexts to Other in order to be able to boot the 10.13.1 beta 5 update installer

- Kext Inject Management is empty for the update installer

- When looking at preboot.log, it turns up it's injecting kexts from 10.12, while I'm obviously on 10.13

 

post-1502423-0-19275500-1509044218_thumb.pngpost-1502423-0-58114200-1509044226_thumb.png

preboot.log.zip

Share this post


Link to post
Share on other sites

Aptiofix2 does not relocate anything in memory so it should not interfere with anything, whereas for some reason aptiofix does interfere. Aptiofix can break firmware runtime, like nvram.

 

 

 

Yes, it is the order they are enumerated, one disk may be busy and take longer to respond although it comes first in actual order. Those are just identifiers for the kernel for that boot, they no longer matter after restart/shutdown. That's why everything is identified by the partition identifier.

 

 

 

That's your preference. VBoxHFS is open source but lacks features (it's slightly slower as well), however it seems to work better with some misbehaving firmwares. HFSPlus is closed source driver extracted from Apple firmware, it's fast and has more features, such as core storage RAID support and filevault.

 

 

 

You do not need an NTFS driver at all. Windows boots from the EFI partition so can be read directly from the firmware already. If there is any reason to have one I do not know what it is.

 

 

 

Good question, I'm not sure but I see no reason why it would touch the EFI partition. I haven't seen or heard of it.

 

 

 

Can you boot without it/other patches? Is your power management working? Have you tried? Does it work? Does it give better performance? Beats me.

 

 

 

Not that I'm aware of but it could be different depending on your hardware and kexts.

 

 

 

Might have something to do with injecting the wrong properties for the graphics, I am unsure how to even check that. Maybe check out ioreg for anything interesting.

 

 

 

An APFS partition is a container and has another structure inside that contains the volumes like recovery, system, etc. It would not back up properly to a HFS+ partition. So probably no, but maybe it does something to convert either the HFS+ to an APFS or the APFS content to work on the HFS+. Really no idea...

 

 

 

Not anything meaningful, and not anymore than an actual SMC being present would. FakeSMC is just using values stored in memory to emulate that they were retrieved from an SMC, which Macs have but PCs do not.

:lol:excellent and exemplary explanation :lol:

Share this post


Link to post
Share on other sites

@rotoyouoio,

 

Can you please give some screen shots or something? It's hard to understand what you mean from just your description, but I'll try.... What EFI drivers are you using? Are you injecting kexts? What else are you doing? The problem with X99 systems does not appear to be related to this at all unless you have drastically over complicated what you mean. The X99 problem is a boot time error where not enough contiguous free space can be allocated to place the entirety of the kernel - this is still in protected mode, not virtual so there is no address translation yet. Your error, if I understand correctly, is happening after boot services and during the kernel's runtime and appears to be a virtual address translation error. There are plenty of reasons why this could happen, moving stuff in memory after it's address has been translated, improperly translating an address, or just not translating the address at all. Need much more information, probably deeper debugging, which is hard if no developer has the issue or cannot reproduce it...

 

EDIT: I've never even seen you say anything about this before, so there's no need to get mad. Everyone is trying to help but remember that every one here is doing this in their free time as a hobby. We don't all have lots of time to do everything, the more users a problem affects the higher priority it will have. As far as dmazar, I don't know what you mean but he's a great guy and a friend, you may find yourself not getting help at all by insulting developers who, if not for them, you would still be complaining it didn't work but for another reason. And the reason that there is no different aptiofix is because no one has created a better idea than that collaboration from projectosx, and the slight modification for aptiofix2. By all means please develop another method.

umh... where did i insult any developer? i only said i was frustrated from diagnosing this. i mean i wasted a week before coming to the conclusion that it is not me being an idiot or the hardware being faulty. thus the frustration. the possibility of me being an idiot remains though.

 

concerning dmazar. he might be a great guy, i just remember him saying that this is heavy work that he won't spend any more time when the x99 problem happened. and i've remembered this only to save someone's time pointing me at his direction. this in no way contradicts that he's a great guy and someone's good friend =0)

 

anyway, back to the problem. screenshots of rember are in no way more informative than the text copied.

 

i will spill my understanding of the problem, forgive me if it's too lame/nooblike/utterly silly

 

the EFI (?) reserves and uses some physical memory addresses for hardware operation after the kernel is loaded, particularly usb storage devices (they are a certain condition for reproducing on x299 hardware), that the system considers available, hence writing to these addresses (virtual or not - no idea) is NOT successful, but the system has no idea. which means that when reading from these addresses - the system/software/memtest reads incorrect data, which can lead to practically anything. memtest is only different in the way that it knows what data must be returned after the inquiry.

 

there.

 

there is no way i can better describe the problem than the text above and in the previous posts.

 

not that i expect you to diagnose this without such hardware, and i can live with legacy booting. (the only practical downside is sata hotplug not working in case of no harddrive attached to the hotplug port before boot)

 

i am still rather grateful to be mentioned by someone like apianti and fritz (very little sarcasm here and it's in good spirit =0)

 

this is more a cryout and a warning for future users of x299 platforms/a challenge for hackintosh (can a new term be made?) developers

Share this post


Link to post
Share on other sites

umh... where did i insult any developer? i only said i was frustrated from diagnosing this. i mean i wasted a week before coming to the conclusion that it is not me being an idiot or the hardware being faulty. thus the frustration. the possibility of me being an idiot remains though.

 

concerning dmazar. he might be a great guy, i just remember him saying that this is heavy work that he won't spend any more time when the x99 problem happened. and i've remembered this only to save someone's time pointing me at his direction. this in no way contradicts that he's a great guy and someone's good friend =0)

 

I was just warning you about getting angry when you are frustrated and mentioning someone who I know won't be helping since he has long left actively contributing to the community. You'll get more help if you put your frustration aside and try to give as much information as possible, even if it seems mundane or unrelated.

 

anyway, back to the problem. screenshots of rember are in no way more informative than the text copied.

 

i will spill my understanding of the problem, forgive me if it's too lame/nooblike/utterly silly

 

the EFI (?) reserves and uses some physical memory addresses for hardware operation after the kernel is loaded, particularly usb storage devices (they are a certain condition for reproducing on x299 hardware), that the system considers available, hence writing to these addresses (virtual or not - no idea) is NOT successful, but the system has no idea. which means that when reading from these addresses - the system/software/memtest reads incorrect data, which can lead to practically anything. memtest is only different in the way that it knows what data must be returned after the inquiry.

 

I have an idea what might be going on but I need more information, I would like to see screen shots of the error when it happens. I would like config.plist, boot.log, maybe ioreg and some DSDT/SSDT dumps. You can probably dump all that in one go with DarwinDumper (just select everything). Is the problem only related to USB devices in some way?

 

EDIT: If you can dump your DSDT/SSDTs from clover too so they are the unpatched versions.

 

there is no way i can better describe the problem than the text above and in the previous posts.

 

not that i expect you to diagnose this without such hardware, and i can live with legacy booting. (the only practical downside is sata hotplug not working in case of no harddrive attached to the hotplug port before boot)

 

i am still rather grateful to be mentioned by someone like apianti and fritz (very little sarcasm here and it's in good spirit =0)

 

this is more a cryout and a warning for future users of x299 platforms/a challenge for hackintosh (can a new term be made?) developers

 

I just don't think any one understands what you are describing and you aren't really changing the description or giving any different information so it's hard to tell what you are talking about. It's all good.  B)

Share this post


Link to post
Share on other sites

I was just warning you about getting angry when you are frustrated and mentioning someone who I know won't be helping since he has long left actively contributing to the community. You'll get more help if you put your frustration aside and try to give as much information as possible, even if it seems mundane or unrelated.

 

 

I have an idea what might be going on but I need more information, I would like to see screen shots of the error when it happens. I would like config.plist, boot.log, maybe ioreg and some DSDT/SSDT dumps. You can probably dump all that in one go with DarwinDumper (just select everything). Is the problem only related to USB devices in some way?

 

EDIT: If you can dump your DSDT/SSDTs from clover too so they are the unpatched versions.

 

 

I just don't think any one understands what you are describing and you aren't really changing the description or giving any different information so it's hard to tell what you are talking about. It's all good.  B)

 

i made Darwin do a dump over here http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2522249

 

i think everything but the screenshots are in that darwin's dump =0) please correct me if i'm wrong.

 

the error happens instantly in memtest/rember displaying that text

 

all the other occurences are hard to screenshot, like finder getting stuck, resolve render output getting corrupted, or prefence files getting messed up up to the point of the system becoming unbootable (the reason i started testing initially)

 

i can only reproduce this problem by having usb drive devices attached. so i believe that yes, only usb related

 

dumping the original acpi tables is going to take some time, i am away from the machine now. i can, however, try to get a darwin dump with the original acpi tables from a similar setup, if my Darwin's dump is of no help without the original unpatched tables. I don't use a custom, only the patches that are in the plist an i believe that clover drops most of the secondary

Share this post


Link to post
Share on other sites

i made Darwin do a dump over here http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2522249

 

i think everything but the screenshots are in that darwin's dump =0) please correct me if i'm wrong.

 

the error happens instantly in memtest/rember displaying that text

 

all the other occurences are hard to screenshot, like finder getting stuck, resolve render output getting corrupted, or prefence files getting messed up up to the point of the system becoming unbootable (the reason i started testing initially)

 

i can only reproduce this problem by having usb drive devices attached. so i believe that yes, only usb related

 

dumping the original acpi tables is going to take some time, i am away from the machine now. i can, however, try to get a darwin dump with the original acpi tables from a similar setup, if my Darwin's dump is of no help without the original unpatched tables. I don't use a custom, only the patches that are in the plist an i believe that clover drops most of the secondary

 

Ok just looking at your log, you have some crazy issues:

0:100  0:000  CPU was calibrated without ACPI PM Timer: ACPI I/O space is not enabled., use RTC

Try using the UEFI only options when installing, it looks like you have some legacy or custom build.

0:100  0:000  Build with: [Args: -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8 | -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 9 | OS: 10.12.6 | XCODE: 9.0]

Very very unsupported CPU.

0:102  0:000  CPU Vendor = 756E6547 Model=50654
...
0:102  0:000  BrandString = Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz

You may need to adjust some settings in your firmware setup menu as there are many disabled devices:

0:102  0:000  PCI (00|00:05.01) : FFFF FFFF class=FFFFFF

Is this fake CPU capable of working with your CPU? Have you tried others?

0:119  0:000  FakeCPUID: 506E4

Are these patches 100% correct and needed? Have you tried built-in XCPM enabling?

0:119  0:000  KextsToPatch: 3 requested
0:119  0:000   - [00]: AppleUSBXHCIPCI (Remove Port Limit) :: BinPatch :: data len: 7
0:119  0:000   - [01]: IOAHCIBlockStorage (SSD Trim Enabler) :: BinPatch :: data len: 10
0:119  0:000   - [02]: AppleUSBXHCIPCI (USB Port Limit Patch) :: BinPatch :: data len: 4
0:119  0:000  KernelToPatch: 8 requested
0:119  0:000   - [00]: xcpm_cpuid_set_info © Pike R. Alpha :: MatchOS: 10.13.x :: data len: 8
0:119  0:000   - [01]: xcpm_bootstrap Sierra © Pike R. Alpha :: MatchOS: 10.13.x :: data len: 8
0:119  0:000   - [02]: xcpm_program_msrs © Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 28
0:119  0:000   - [03]: xcpm_pkg_scope_msrs © Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 12
0:119  0:000   - [04]: xcpm_SMT_scope_msrs © Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 11
0:119  0:000   - [05]: xcpm_core_scope_msrs © Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 12
0:119  0:000   - [06]: xcpm_idle patch by Pike R. Alpha :: MatchOS: 10.12.x,10.13.x :: data len: 7
0:119  0:000   - [07]: 10.13 Installer/Updater essential :: MatchOS: 10.12.x,10.13.x :: data len: 11

There were no RAM modules found on the SMBus controller... Not sure why it wouldn't find the four modules you have installed.

1:040  0:000  SMBus device : 8086 A2A3 class=0C0500 status=Success
1:040  0:000  SMBus CmdReg: 0x3
1:040  0:000  Scanning SMBus [8086:A2A3], mmio: 0x3FF44004, ioport: 0x3000, hostc: 0x11
1:040  0:000  Slots to scan [8]...

Whoa. Nice frequency! That's fast.

5:907  0:000  Finally: ExternalClock=25MHz BusSpeed=100377kHz CPUFreq=-4294963984MHz PIS: hw.busfrequency=100000000Hz

This is also not correct, there should be four device mappings here since you have four modules. Also the mappings don't make sense, this means that less than 48MB is mapped and overlapping. I have a feeling this is where your problem may be starting.

6:045  0:000  NumberOfMemoryDevices = 8
6:045  0:000  Type20[0]->End = 0xFFFFFF, Type17[0] = 0x4000
6:045  0:000  Type20[1]->End = 0x1FFFFFF, Type17[1] = 0xC000
6:045  0:000  Type20[2]->End = 0x2FFFFFF, Type17[2] = 0x18000

Are you sure you want to drop these tables entirely? You aren't reinjecting any

6:061  0:000  Drop tables from Xsdt, SIGN=DMAR TableID=A M I  Length=216
6:061  0:000   Xsdt has tables count=30
6:061  0:000   Table: DMAR  A M I   216 dropped
6:061  0:000  Drop tables from Xsdt, SIGN=SSDT TableID=PtidDevc Length=12290
6:061  0:000   Xsdt has tables count=29
6:061  0:000   Table: SSDT  PtidDevc  12290 dropped
6:061  0:000  Drop tables from Xsdt, SIGN=SSDT TableID=sensrhub Length=671
6:061  0:000   Xsdt has tables count=28
6:061  0:000   Table: SSDT  sensrhub  671 dropped

I think you may have some trouble with the number of cores that CPU has. Also don't generate p and c states, patch your existing tables, drop the originals and reinject the patched.

6:062  0:000  Out of control with CPU numbers
6:062  0:000  CPUBase=0 and ApicCPUBase=0 ApicCPUNum=20
6:062  0:000  Maximum control=0x21
6:062  0:000  Turbo control=0x2B
6:062  0:000  P-States: min 0xC, max 0x2B
6:062  0:000  SSDT with plugin-type without P-States is generated
6:062  0:000  SSDT with CPU C-States generated successfully

Remove most of these from injection, leave FakeSMC and install the rest properly. Why do you have VoodooTSCSync? Get rid of that evil monstrosity.

6:068  0:002  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other
6:068  0:000  Extra kext: EFI\CLOVER\kexts\Other\VoodooTSCSync.kext
6:074  0:006  Extra kext: EFI\CLOVER\kexts\Other\FakeSMC.kext
6:081  0:006  Extra kext: EFI\CLOVER\kexts\Other\ACPISensors.kext
6:086  0:005  Extra kext: EFI\CLOVER\kexts\Other\NvidiaGraphicsFixup.kext
6:092  0:006  Extra kext: EFI\CLOVER\kexts\Other\GPUSensors.kext
6:100  0:007  Extra kext: EFI\CLOVER\kexts\Other\IntelMausiEthernet.kext
6:105  0:005  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext
6:113  0:008    |-- PlugIn kext: EFI\CLOVER\kexts\Other\AppleALC.kext\Contents\PlugIns\PinConfigs.kext
6:119  0:006  Extra kext: EFI\CLOVER\kexts\Other\SmallTreeIntel82576.kext
6:125  0:005  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext
6:130  0:004  Extra kext: EFI\CLOVER\kexts\Other\LPCSensors.kext
6:140  0:009  Extra kext: EFI\CLOVER\kexts\Other\ATTOExpressPCI4.kext

Turn off custom boot logo. I never finished it and I'm not sure it doesn't cause side effects.

6:150  0:000  Custom boot is using apple logo
6:153  0:003  Custom boot lock
6:153  0:000  Custom boot framebuffer 0xC0000000 0x900000
6:153  0:000  Custom boot GOP: 0x39239498 @0xC0900000 0x300000 1024(1024)x768

Share this post


Link to post
Share on other sites

Lilu and its plugins are designed to run from clover not S/L/E. to run it "correctly" as you mention you would need yet another kext called lilu friend

 

Ummmmm no, http://www.insanelymac.com/forum/topic/321371-lilu-—-kext-and-process-patcher/?p=2371334

 

EDIT: Oh I see what you mean, that a few of the plugins don't work unless injected. But that's really on the person who developed them because every kext should work when installed....

Share this post


Link to post
Share on other sites

been trying to follow the thread on kext injection vs install in /L/E

for many years now, I have installed a duplicate set of kexts one set in ESP...Other and then install them in /L/E

 

Question: what is the downside of NOT having custom kexts in /L/E?

 

I observe (my experience with High Sierra and Clover 4267) with these 2 scenarios:

 

ESP

Clover injects all custom kexts (whether binary or just "property injectors") including Lilu/AppleALC

- SIP can be fully enabled

- ESP kexts provide support for installer and/or Recovery

- Note: can run OS fine too - all kexts work. 

 

Custom kexts in /Library/Extensions 

- SIP must be (partially or fully) disabled - due to kext signing etc.

- use detect kext feature

 

list of kexts:

  • ACPIBatteryManager.kext
  • ACPIPoller.kext
  • Lilu.kext+AppleALC.kext
  • AppleBacklightInjector.kext
  • BlueTooth_Injector_T420.kext
  • EFICheckDisabler.kext
  • FakeSMC.kext + plugins
  • IOAHCIBlockStorageInjector.kext
  • IntelMausiEthernet.kext
  • VoodooPS2Controller.kext

Share this post


Link to post
Share on other sites

Ummmmm no, http://www.insanelymac.com/forum/topic/321371-lilu-—-kext-and-process-patcher/?p=2371334

 

EDIT: Oh I see what you mean, that a few of the plugins don't work unless injected. But that's really on the person who developed them because every kext should work when installed....

Incorrect. When you install a kext into /S/L/E or /L/E macOS does not guarantee you any load priority unless you are an apple kext with apple security extension flag.

Lilu needs to start very early to be able to attach to a certain MAC policy to enable kext patcher/process patcher.

If you install it without LiluFriend (which is marked as apple security and has Lilu with plugins as a dependency) approximately 10-15% of kextcache rebuilds will result in Lilu and (obviously all the plugins) not loading in the system.

Share this post


Link to post
Share on other sites

Incorrect. When you install a kext into /S/L/E or /L/E macOS does not guarantee you any load priority unless you are an apple kext with apple security extension flag.

Lilu needs to start very early to be able to attach to a certain MAC policy to enable kext patcher/process patcher.

If you install it without LiluFriend (which is marked as apple security and has Lilu with plugins as a dependency) approximately 10-15% of kextcache rebuilds will result in Lilu and (obviously all the plugins) not loading in the system.

 

I was pointing out that you specifically said that it was not boot loader dependent and he said that it was designed to run from clover. Just a thought, why not just use IOPCIMatch for any Intel (and/or AMD) device...? Then it will always load... How is injecting giving you any better load priority? Wouldn't it initialize the prelinked data already there then load the kext from the datahub?

Share this post


Link to post
Share on other sites

apianti, how is that clover only? Booter extensions are supported by any bootloader from Chameleon to Ozmosis, furthermore, you could use LiluFriend (which I use on real hw and VMware; abd I do not hack Lilu and plugins' plists with apple security stuff for various reasons).

 

You might have misread me. Lilu always loads, but to work properly it needs to be loaded very early. Very early means is I need to load before most of ioreg is ready, right after main file system mount, even before dyld shared cache is mapped or launchd starts. At this step only platform and security extensions are guaranteed to load. Booter extensions start next, and they are also pretty much guaranteed to load early enough. Everything else is not, if you happen to be in the end of prelinked list, you are screwed You could always check XNU code if you are interested.

Share this post


Link to post
Share on other sites

apianti, how is that clover only? Booter extensions are supported by any bootloader from Chameleon to Ozmosis, furthermore, you could use LiluFriend (which I use on real hw and VMware; abd I do not hack Lilu and plugins' plists with apple security stuff for various reasons).

 

 

I think I'm just lazy and wasn't clear:

 

Lilu and its plugins are designed to run from clover

 

You might have misread me. Lilu always loads, but to work properly it needs to be loaded very early. Very early means is I need to load before most of ioreg is ready, right after main file system mount, even before dyld shared cache is mapped or launchd starts. At this step only platform and security extensions are guaranteed to load. Booter extensions start next, and they are also pretty much guaranteed to load early enough. Everything else is not, if you happen to be in the end of prelinked list, you are screwed You could always check XNU code if you are interested.

 

No, I understood, I was asking a question about why it wouldn't be initializing the prelinked kexts before the injected. Also seems like a pretty big security flaw, if they are indeed not even checked when sip is enabled.

Share this post


Link to post
Share on other sites

Well, this question should be asked at lists.apple.com at Darwin-Kernel. The ones in the beginning of the prelinked list are also fine, but there is no deterministic way to get there.

 

As for security flaws, this is actually a bit more secure, because this way you cannot really use Lilu unless you loaded the plugin with the system.

Share this post


Link to post
Share on other sites

I guess vit9696 is right since Apple relies on it´s ecosystem. All the things we do on bootloader level are hackintosh specific since they take place before macOS takes over. Stuff like kext injection will most likely not work on real macs since there is no layer between the machines EFI and the oses boot.efi which could enable manipulation of the Memmap in any way. Given that there is no need to double check if extensions which are part of the prelinked kernel are signed or not since they will only find their way into it if they are signed or if the user decided to disable SIP to allow loading of unsigned Extensions. 

Share this post


Link to post
Share on other sites

apianti, how is that clover only? Booter extensions are supported by any bootloader from Chameleon to Ozmosis, furthermore, you could use LiluFriend (which I use on real hw and VMware; abd I do not hack Lilu and plugins' plists with apple security stuff for various reasons).

 

You might have misread me. Lilu always loads, but to work properly it needs to be loaded very early. Very early means is I need to load before most of ioreg is ready, right after main file system mount, even before dyld shared cache is mapped or launchd starts. At this step only platform and security extensions are guaranteed to load. Booter extensions start next, and they are also pretty much guaranteed to load early enough. Everything else is not, if you happen to be in the end of prelinked list, you are screwed You could always check XNU code if you are interested.

 

It seems that kexts placed in /L/E generally go to the beginning of the prelink.  I think kextcache scans there first.

So you can probably use Lilu and plugins if you install to /L/E instead of /S/L/E without requiring LiluFriend.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By glasgood
      CLOVER DUAL BOOT MOJAVE & WINDOWS 10 GUIDE 
       

       
       
      INCLUDES  MBR / LEGACY BIOS  TO  GPT / EFI CONVERSION
      USING MBR2GPT TOOL
       
       
      PREREQUISITE: Two physical discs ( SSD’s or HDD’s )
       
       
       
       
       
      STEP 1 - Clover dual boot configuration 
       
      Open config.plist with Clover Configurator
       
      Boot
       Legacy = PBR Timeout = True ( will remove the Timeout countdown, from Clover boot menu)  

       
      GUI 
      Scan / Custom
       Entries = True  Tool = True  Legacy = False ( removes extra Windows 10 entries )  
      Hide Volume
      - Preboot ( macOS Preboot )
      - Recovery ( macOS Recovery )
       

       
      So at boot you will have two options: boot macOS Mojave or Windows 10 
       
       
       
       
       
       
       
      ————————————————————
       
       
      STEP 2 - Using a drive without Windows 10 installed
       
      Disconnect system drive that contains your macOS Mojave install from computer ( This is so that Windows does not overwrite existing macOS Mojave boot loader )
       
      Proceed with a Windows 10 UEFI install.  
      After installation reconnect macOS Mojave Drive, the Windows installation should now be detected and usable in Clover. 
      If Windows 10 is not detected or able to boot,  then verify you installed Windows 10 as UEFI and not MBR ---->  ( Read step 2 - For a drive with Windows 10 installed )
       
       
      OR
       
       
       
      STEP 2 - Using a drive with Windows 10 already installed
       
      Verify your Windows install is  GPT / UEFI or MBR / Legacy BIOS.   
      If Windows install is GPT UEFI then Windows 10 install is ready to use at Clover boot menu, you should be able to boot into Windows directly from Clover boot screen. 
       

       
       
      But if  Windows drive is detected at Clover boot screen, but when booting Windows you get a black screen with a cursor on the top left,
      then this is most likely because Windows drive is MBR ( Legacy BIOS ).  You can easily convert MBR to GPT using  Windows MBR2GPT tool ( this saves hours work having to reinstall Windows 10 and setting up all your applications again  ) 
       
      If Windows 10 install is MBR / Legacy BIOS  then simply convert to GPT / UEFI  following instructions below ( read video summary and view video )
       
       
      ** To use Windows 10  MBR2GPT tool  you must have Windows 10 version 1703 ( creators update  ) or later and less than 3 partitions on 
      the Windows 10 drive **
       
      Video summary:
       
      Confirm Windows 10 drive is MBR Legacy BIOS ( in Windows Disk Management ) Reboot into Windows PE ( Advanced Startup ) Convert from MBR Legacy BIOS to GPT UEFI ( using commands below ) mbr2gpt /validate mbr2gpt /convert Restart Verify Windows 10 drive has changed to GPT UEFI ( in Windows Disk Management )  
       
       
       
      After conversion Windows 10 is ready to use at the Clover boot menu 
       
       
       
      STEP 3 - Stop Windows Boot manager from overriding Clover boot manager
       
      How to stop Windows boot manager from overriding your Hackintosh Clover boot manager when using dual booting between macOS and Windows
       
       
       
       
       
       
    • By AppleBytes
      OK, I've searching for days trying to gather up the tools to make my current install work correctly. I'm well on my way. But all the links to the things I currently must have were apparently nuked "during a forum upgrade". :(
      As far as EFI Studio goes; I can find many links to it. But for Insanelymac, they're broken (due to the upgrade), or for the Netkas site, they're links to either Rapidshare, or Mediafire that also no linger exist. I see many users here indicating that they used it to tweak their DSDT. But the web (google/duckduckgo), Instanelymac, and Netkas seem to have no idea where it's gone.
      Could some kind soul please share a copy, or a link? I'm a loooong time hacker, and would love to bring it back to life. In fact, I'd love to improve it -- or at least bring it up to current times. If only I knew where it was.
      Thank you for all your time, and consideration.
       
      --Chris
       
    • By SoThOr
      This was spurred on from a discussion in the Clover General thread. Where there was a debate on bcdedit being able create/read/edit (U)EFI Boot entries. I didn't think it appropriate to post all this information there and somebody may want to make use of this and its likely to get lost in that massive thread.
       
      Out of curiosity I decided to see if I could create an EFI entry using bcdedit. What can I say I like a challenge.  Whilst is not a documented method by Microsoft, as it turns out in a round about way it IS possible to create an EFI entry using bcdedit and these are the steps I went through to add UEFI Shell located on a USB stick to the EFI entries. 
       
      Third party software is available that can create and edit UEFI entries from Windows with better support and more features. I'm just making this information available in case those options are unavailable. 
       
      DISCLAIMER - This is not a supported method. Use at your own risk. I recommend backing up your BCD/Firmware variables/settings beforehand.
       
      1) Copy {bootmgr} entry.
      C:\Windows\System32>bcdedit /copy {bootmgr} /d "UEFI Shell" The entry was successfully copied to {34e8383c-73a7-11e9-9cb0-94de8078a7b5}. 2) Edit the new entry using the new GUID bcdedit generated in the copy step.
        a) Set the device and path for UEFI shell on my USB stick.
      bcdedit /set {34e8383d-73a7-11e9-9cb0-94de8078a7b5} device partition=G: bcdedit /set {34e8383d-73a7-11e9-9cb0-94de8078a7b5} path \EFI\SHELL\SHELLX64.efi   b) Clean up some of the stuff that was copied from {bootmgr} (optional as far as I can tell, just makes things tidier in bcdedit)
      3) Put the new EFI entry first in boot order. (optional)
       
      After completing the steps above, here is what "bcdedit /enum firmware" shows:
       
      I shutdown my computer and when I turned my computer back on it booted up into UEFI Shell. After exiting the shell my PC went on to boot Windows.
      Here is the resulting dump using "bcfg boot dump -v" from that shell:
       
      You may notice that the shell shows as "Windows Boot Manager" in the bcdedit output. This I believe is because of the "WINDOWS" at the beginning of the option data that bcdedit added to the EFI Boot entry. I also believe this why bcdedit shows my Windows 8 installation as "Firmware Application" because it has no option data. I don't know how to remove this data using bcdedit nor do I know how the option data, that bcdedit adds, will affect other EFI applications.

      There might be a way to create the EFI entry without copying the Windows entry but if there is I'm unable to find any documentation on how one would do so. If you use the create command then it just puts it in the BCD and I'm unaware of a way to tell it to create it in EFI instead, other than by doing the above.
    • By cvad
      Small tool to download, compile and build the latest Clover X64 package.
       
       
       

      The script inside is editable.

       
      Enjoy...
       
      Many thanks to the comrade SunKi for help with creating the script.
       
       
       
       
       
      Best thanks - click "Rate File".
       
    • By blxkspell
      Hey!
      As I have 3 Monitors connected, my RX 570 gets arround 50°C while ideling/ web browsing etc. The problem is, that this temp is apparently just the threshold, when the fans start to spin. So the fans start spinning for a minute then they stop for a while again... This is very annoying for me as the rest of my hackintosh is nearly quiet (SSD, 120mm low RPM cpu fan, nearly silent PSU,...), especially when Im using the pc to revise for school. Does somebody know wether its possible to "change" the threshold till the fans start spinning? Like it would probably not be a problem for the gpu at all, if the temp rises to 55°C but therefore be soundless....
       
       
×