overdue-scratch

Author Topic: Extension loading precedence?  (Read 2927 times)

0 Members and 1 Guest are viewing this topic.

rcfa

  • Member
  • Posts: 47
Extension loading precedence?
« on: May 01, 2009, 07:28:24 AM »
In my quest to get a more or less vanilla version of Mac OS X running on my EeePC 1000HE, I was always stumped by a boot failure of the original DVD. Thanks to some hints, this could be reduced to ACPI and APIC related extensions. So creating ditto copy of the original install DVD onto a spare partition of the hard disk and overwriting the two offending extensions allowed me to use Chameleon to boot that "DVD" and start the install from there.

The issue is: these two extensions were already in the EFI partition's Extra/Extensions/ folder, and part of the Extensions.mkext cache.

Since the ones that work are older versions, it seems that during boot the newer versions on the install DVD took precedence and thus the boot failed. How can I specify that whatever extensions are present in the EFI partitions Extra/Extensions/ folder are the once to be used, and that any conflicts ought to be decided in their favor?

Is there a way to do that, or would I have to try to trick the OS into thinking they are newer versions, e.g. by editing the .plist files within the .kext bundle to make them seem "newer" than they are?
Or is there some Chameleon option or something in com.apple.boot.plist that I can set?

Any help highly welcome.

Superhai

  • VoodooLabs
  • Posts: 102
Re: Extension loading precedence?
« Reply #1 on: May 01, 2009, 11:13:00 AM »
The kernel prioritize newer versions of the kexts.

rcfa

  • Member
  • Posts: 47
Re: Extension loading precedence?
« Reply #2 on: May 01, 2009, 04:10:15 PM »
The kernel prioritize newer versions of the kexts.

Thanks, that's what I suspected.

Is it sufficient to edit the Info.plists within the kext bundles to trick the kernel into thinking that an older version is newer (e.g. by giving an absudly high version number of 9999.99), and thus preventing boot failure after Apple Software Updates, or is there a version embedded in the binary part of the kexts that the kernel uses?