overdue-scratch

Author Topic: Identical loaders and Extra folders on different partitions act differently  (Read 3217 times)

0 Members and 1 Guest are viewing this topic.

tempolo

  • Member
  • Posts: 82
    • My own Hackintosh page
I think I've already got quite a good understanding on a lot of things around boot loading by now, but this puzzle I cannot figure out, despite being on this for over an entire day:

I have the same Chameleon version installed on two separate drives. Both have identical Extra folders.

But they cause different effects when booting the SAME kernel/OSX. I cannot figure out why.

Here's the details:

I have an internal drive, MBR, with two partitions, and Chameleon 2.0RC1 installed:
#1: Windows
#2: OS X

Then I have an external (USB) drive which is GUID and also contains Chameleon 2.0RC1 (which did of course not get installed into the EFI PART but on the only OS X partition on the disk).

Both the internal and the external OS X have an identical Extra folder.

When I tell the PC to start up from the external drive, and then choose to boot the internal OS X system, all is well, i.e. "kextstat" shows me that the newer kexts from the Extra folder are loaded.

But when I tell the PC to start up from the internal drive, with the boot loader on the internal OS X partition, and boot the OS X on the same partition, I can tell that some extensions from the Extra partition get loaded (because if I remove them, the system will panic), but some older kexts get loaded, especially those for the GMA950, leading to wrong display size (1024x768 on the netbook's actual 1024x600 screen).

I mean, the Extra folder on both boot loader partitions are identical (by copying one to the other), yet they cause different results when being loaded by the kernel.

I suspected the mkext or kernel cache, but even booting with "-t" doesn't help - I still get the same different results.

How can that be? What am I missing?


tempolo

  • Member
  • Posts: 82
    • My own Hackintosh page
OK, this looks like some kind of bug or "undocumented feature".

The effect seems to be caused by the fact that the Extra folders contain both an Extensions folder and a Extensions.mkext file.

If the loader starts from the same volume which the kernel will boot from, then only either the Extensions folder or the mkext will be used from the Extra folder.

If, however, the loader gets loaded from a different volume than the kernel, then, so it appears to me, both the mkext and the Extensions folder from the two Extra folders will be used. And if mkext and Extensions folder are not in sync, this will lead to the problems I've described.

Furthermore, if loader and kernel get loaded from the same volume, there's one more oddity, even more severe IMO: all is well if there is a mkext. But if the mkext is replaced by a Extensions folder with the same kexts that are in the mkext, some exts will load, but others will not. This is not good - they should lead to the same effect. After all the same is also true for the S/L/E kexts, isn't it?

To prevent others running into this confusion, the rules for Extra folder loading should be revised, I think.

Anyone from the devs open to discussion on this?

tempolo

  • Member
  • Posts: 82
    • My own Hackintosh page
Oh my, I think I get it now...

When creating an mkext, it actually does not simply only include the files from the designated /Extra/Extensions folder, but it also adds dependent extensions from the /S/L/E folder!

Hence, the mkext in Extra contains more kexts than the Extensions in Extra.

Darn, why isn't this mentioned in big letters? Took me days to figure this one out.

Now, this still leads me to believe that the Chameleon loader needs fixing. Apparently, it fails to resolve kexts in Extra that have dependencies. Since these dependent kexts are located in /S/L/E, it should load those from there.

Why doesn't it do it? Can a dev exlain?

(added later:)

Nope, that still doesn't make sense: Even if I unpack the mkext folder in Extra again (using mkextunpack) in a formerly empty "Extensions" folder, then remove the kext so that the /Extra/Extensions folder is now replacing it, it still does not have the same effect!

So, why does a mkext works and a set of identical kext files in a Extensions folder does not?
(mind, some files from the Extensions get obviously loaded, because I'd get a kernel crash if they're not there)
« Last Edit: June 22, 2009, 12:05:20 PM by tempolo »

Lord Anubis

  • Member
  • Posts: 74
Hi tempolo,

Your experience with the current Chameleon are also mostly others/mine, somethings a little different. I did try to create a matrix with posabilities, but I give up....... Anyway, this is for me a reason to wait till the next version of Chameleon or do any kind of development action.

Also I notice some different automatic rebuild behaviour when I are using macos on a second partition and did remove a extension.mkext from partition 1. The rebuilded extensions.mkext was different then doing a mkext rebuild from the booted system self.

I know this doesn't help much, but my guess is that the devs knows about this. but its always good to air your findings.

Anyway good luck.
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

tempolo

  • Member
  • Posts: 82
    • My own Hackintosh page
Thank you, Lord!
At least I know now that I'm not alone with this. I felt so stupid.

I found out that even just copying the "correct" mkext into the Extra folder is not working right. Probably because there may still be another cache, the so-called "kernel cache file", which is yet in another location on the disk, and which also needs updating, or clearing after changing the Extra's kexts. Unless chameleon does ignore that one.

I guess I'll have to roam the sources sooner or later...