Author Topic: Bug? Some kexts only load properly from /System/Library/Extensions/  (Read 10634 times)

0 Members and 1 Guest are viewing this topic.

rcfa

  • Member
  • Posts: 47
I use the EFI partition install of Chameleon. So I have all "special" kexts on the EFI partition's /Extra/Extensions folder. I added as many OS X original kexts into that folder (incl. System.kext) until I could build the mkext file in /Extra/ without any errors about missing dependencies.

So I would have assumed that all dependencies are met, and that all kexts loaded from that /Extra/Extensions.mkext or alternatively /Extra/Exteneions/*.kext would remain loaded UNLESS there's a newer kext in /System/Library/Extensions.

This however does not seem to be the case. I just re-installed the vanilla 10.5.7 GMA950 related kexts and also the 10.5.7 IOBluetoothFamily.kext into /System/Library/Extensions.

I then took these very same kexts (same version numbers) and patched them. So now these patched ones have the same version number, but will recognize the device IDs present in my computer. These patched versions I then put into /Extra/Extensions on the EFI partition and built a new Extensions.mkext.

So the expectation was that these extensions are loaded, and when the extensions in /System/Library/Extensions are looked at, then these would be skipped because versions with the same version number were already loaded. However, what seems to be the case is that the unpatched versions get loaded and then replace the already previously loaded patched versions.

The only way I get the patched versions to load is if I rename/remove the vanilla versions in /System/Library/Extensions and add the patched versions to that folder as well. Now they get loaded and work as expected, which proves that they are functional and patched properly.

Is there a fundamental issue that prevents Chameleon to successfully load video drivers before it gives up control to the kernel, and thus this behavior is expected, am I doing something stupid, or is this a bug?

Of course, things work when I put these three extensions into /System/Library/Extensions/ but really, the whole point of the EFI partition approach is that I can keep all modified kexts out of the main partition, but this seems to be not possible given this behavior. It would be really nice if I could get to the point where there are either no hackintosh-related kexts in /System/Library/Extensions, or at least only ADDITIONAL ones, but none that have to replace vanilla extensions with patched versions, nor should I have to delete any of the vanilla extensions.

Anyway, the good news is that I'm down to three extensions that need replacement, and all three are now native 10.5.7 versions that I know how to patch and thus likely will be able to patch in 10.5.8 etc.

Config: EeePC 1000HE, BIOS 0802, 2GB RAM, 500GB HD, Mac OS X 10.5.7 vanilla install, Chameleon 2.0RC1
« Last Edit: May 25, 2009, 05:49:04 PM by rcfa »

thorazine74

  • Member
  • Posts: 57
I always thought you needed to bump up version numbers of extension from Extra to make them load in place of S/L/E kexts. At least that was before with Chameleon 1, dont know if that changed in 2...
Mac OS X 10.5.6 Retail (Updated to 10.5.7) with Chameleon 2.0 RC1+BootIt NextGen 1.86 (MBR Single Drive)
Gigabyte 73PVM-S2H + C2D + 2 Gb
2 SATA HD (AppleAHCIport.kext) + 1 PATA DVD+RW (DarwinATAPort.kext)
Realtek ALC889 (VoodooHDA.kext)
Geforce 8600GTS (EFI String) PS/2 M & KB: VoodooPS2.kext

Lord Anubis

  • Member
  • Posts: 74

So I would have assumed that all dependencies are met, and that all kexts loaded from that /Extra/Extensions.mkext or alternatively /Extra/Exteneions/*.kext would remain loaded UNLESS there's a newer kext in /System/Library/Extensions.

This however does not seem to be the case. I just re-installed the vanilla 10.5.7 GMA950 related kexts and also the 10.5.7 IOBluetoothFamily.kext into /System/Library/Extensions.

Is there a fundamental issue that prevents Chameleon to successfully load video drivers before it gives up control to the kernel, and thus this behavior is expected, am I doing something stupid, or is this a bug?


This is what I am experiencing too.

I did go nuts to understand how it works, a lot of things did get more clear with what I see and was discussed in former postings.

However, like you notice, the real world, is different.

I notice that when I use mkext files things get difficult. Now I start always with the -f flag and ignore the mkexts. Like I wrote before in another post, I have the impressions that the extensions mkext is throwing away or overriding the Extra/mkext or Extra/Extensions.

However there was also a disscusion about moving the Extra/Extensions inside another folder to avoid some issues. I dont think it is related but you never know.

HTHAL
Quicksilver 2002 Case - GB EP45-DS3P - 8Gb Kingston mem. - Q6600 - Asus 7300GT Silent 512Mb - 6 SATA drives - 1 IDE drives ( using F12/Chameleon for booting, not visible in OSX ) - 1 external Sata Samsung DVD - OSX 10.6.8 server retail - Chameleon 2.0RC1 + Cartri Bios

rcfa

  • Member
  • Posts: 47
Bug or feature: some kexts only loaded from /System/Library/Extensions
« Reply #3 on: May 29, 2009, 12:29:37 PM »
1) Situation: HFS+ formatted EFI partition with Chameleon 2.0RC1
2) Extra/Extensions folder contains all original Apple kexts that are required to build the Extra/Extensions.mkext without errors about missing dependencies
3) Still, the following kexts will not load unless they are present in /System/Library/Extensions:
   - lspcidrv.kext
   - Natit.kext
   - VoodooBattery.kext
   - VoodooHDA.kext
   - VoodooPower.kext
   - VoodooPS2Controller.kext
   - ClamshellDisplay.kext
4) on the other hand, these kexts load just fine from the Extra/Extensions folder:
   - AppleDecrypt
   - AttansicL1eEthernet.kext
   - Disabler.kext
   - AHCIPortInjector.kext
   - ATAPortInjector.kext
   - IOAHCIBlockStorageInjector.kext

Am I doing something wrong, is this a bug in Chameleon, is this so by design (and if so, why?), or am I plain missing something?

I'd really love to get rid of all the Hackintosh related .kexts in /System/Library/Extensions and keep all the mods in Extra/Extensions if anyhow possible, such that I can boot a regular Mac with the same drive, if needed and not get a bunch of errors or potential conflicts...

diamondsw

  • Observer
  • Posts: 11
1) Situation: HFS+ formatted EFI partition with Chameleon 2.0RC1
2) Extra/Extensions folder contains all original Apple kexts that are required to build the Extra/Extensions.mkext without errors about missing dependencies
3) Still, the following kexts will not load unless they are present in /System/Library/Extensions:
   - lspcidrv.kext
   - Natit.kext
   - VoodooBattery.kext
   - VoodooHDA.kext
   - VoodooPower.kext
   - VoodooPS2Controller.kext
   - ClamshellDisplay.kext
4) on the other hand, these kexts load just fine from the Extra/Extensions folder:
   - AppleDecrypt
   - AttansicL1eEthernet.kext
   - Disabler.kext
   - AHCIPortInjector.kext
   - ATAPortInjector.kext
   - IOAHCIBlockStorageInjector.kext

Am I doing something wrong, is this a bug in Chameleon, is this so by design (and if so, why?), or am I plain missing something?

I'd really love to get rid of all the Hackintosh related .kexts in /System/Library/Extensions and keep all the mods in Extra/Extensions if anyhow possible, such that I can boot a regular Mac with the same drive, if needed and not get a bunch of errors or potential conflicts...

I've just been facing the exact same thing. Several of the ones you list work fine for me (with the "OSRequiredBundle"="Root" keys added). Namely:

Code: [Select]
lspcidrv.kext
Natit.kext
VoodooBattery.kext
VoodooPower.kext

The ones that gave me fits were VoodooHDA and AppleIntelIntegratedFramebuffer and AppleIntelGMA950. VoodooHDA.kext will require you also copy over the vanilla Apple kexts IOAudioFamily.kext & OSvKernDSPLib.kext. In my experience, I did NOT have to modify them in any way (such as with the keys mentioned above).

Note that AttansicL1eEthernet.kext similarly needs IONetworkingFamily.kext, but doesn't declare it properly as a dependency - it will claim it's loading fine even though your ethernet jack is dead.

AppleIntelIntegratedFramebuffer and AppleIntelGMA950 will require several kexts:

Code: [Select]
IOACPIFamily.kext
IOGraphicsFamily.kext
IONDRVSupport.kext
IOPCIFamily.kext

(Well, you may not need ALL of them, but that's what worked for me based on the dependencies in the Info.plist files.)

rcfa

  • Member
  • Posts: 47
Thanks, I'll try adding the
Code: [Select]
<key>OSBundleRequired</key>
<string>Root</string>
to the various kext's Info.plist file.

I'm still not clear on if that' should be be considered a bug, missing feature, oversight, or feature of Chameleon that this behaves that way, or if that's something that's beyond Chameleon to control and a basic OS X feature, at which point of course the question shifts if this should be considered a bug, missing feature, oversight or feature of the various kexts in question...

Also, does the "Root" property value imply "Safe Boot"? i.e. what happens when I replace the Safe Boot with Root as I will have to do in some kexts if I want the "Root" property to be present...
EDITNevermind this last question: I found this here: https://developer.apple.com/documentation/Darwin/Conceptual/KEXTConcept/KEXTConceptLoading/loading_kexts.html#//apple_ref/doc/uid/20002369
« Last Edit: May 30, 2009, 03:24:25 AM by rcfa »

rcfa

  • Member
  • Posts: 47
I've just been facing the exact same thing. Several of the ones you list work fine for me (with the "OSRequiredBundle"="Root" keys added). Namely:

Code: [Select]
lspcidrv.kext
Natit.kext
VoodooBattery.kext
VoodooPower.kext

OK, so I edited these, and after adding/changing the key to Root, these do load.
Problem is, something like SafeBoot should be sufficient e.g. in Natit.kext, and I really shouldn't have to mess with keys, particularly when they are not just missing, but are present and properly chosen.

The ones that gave me fits were VoodooHDA and AppleIntelIntegratedFramebuffer and AppleIntelGMA950. VoodooHDA.kext will require you also copy over the vanilla Apple kexts IOAudioFamily.kext & OSvKernDSPLib.kext. In my experience, I did NOT have to modify them in any way (such as with the keys mentioned above).

Turns out, all these were already in my Extra/Extensions folder as it is. So I'm not sure why they still don't load...

Note that AttansicL1eEthernet.kext similarly needs IONetworkingFamily.kext, but doesn't declare it properly as a dependency - it will claim it's loading fine even though your ethernet jack is dead.

Yup, the IONetworkingFamily.kext I already had there anyway, and I don't seem to have any issue with the AttansicL1eEthernet.kext, so all's good on that front. Only the generic issue with this driver or hardware, that it only works when the cable is plugged-in at boot time. It can then be removed and added as often as needed, but if it's not there at boot time, that's that and the port is unavailable for that session.

AppleIntelIntegratedFramebuffer and AppleIntelGMA950 will require several kexts:

Code: [Select]
IOACPIFamily.kext
IOGraphicsFamily.kext
IONDRVSupport.kext
IOPCIFamily.kext

Hm, these too were already present...
...not even adding the root key would load them from Extra/Extensions, and these along with the IOBluetoothFamily.kext are the most important ones, because these are the only patched original Apple kexts, and as such precisely these I don't want to have to load from /System/Library/Extensions.

I guess I could try messing with the version numbers or do some similar hack, to my patched versions not just have the same version as they have now, but a "newer/higher" one. But again, that would be a hack.

In short, the most important kexts I can't get rid of in the /System/Library/Extensions folder.
So no love with these, key present or not, and with all dependencies in place:

   - VoodooHDA.kext
   - VoodooPS2Controller.kext
   - ClamshellDisplay.kext
   - AppleIntelGMA950.kext
   - AppleIntelIntegratedFramebuffer.kext
   - IOBluetoothFamily.kext

So given that I can't achieve the main objective, and given that just moving some of them out of there still requires modifying kext from how they are distributed (causing potential source of confusion when comparing my setup with others), I decided to revert and just have all Hackintosh kexts in both places and let the system pick where to load them from.

Clearly, this isn't optimal, but right now, I'm not going to be able to change it.

On the other hand, clarification from some of the developers if this is supposed to be this way (and if so why), or considered a bug that will eventually be fixed, would be helpful, because if not anything else, it would help me plan future activity (e.g. if it's supposed to be that way, I won't have to repeat these experiments with each future iteration of Chameleon or Mac OS X to see if the situation has improved).

Cheers.
« Last Edit: May 30, 2009, 05:10:21 AM by rcfa »