Bootloader Chameleon 2.4svn Official PKG Installer

[MacNB]

Hi... you giving me good news about DSDT; i was hopping it would be fixed with the latest changes...

That -v thing is another story; i can't test Lion and i can't imagine why the booter would do such thing with it

and not with Snow?? anyway, it's not the first time i read this.

Can anybody else confirm this?

 

MacNB, do you have the same problem using the menu (down arrow) to choose -v?

 

Yes the bug in DSDT option was a big issue - especially when one is experimenting with DSDT edits and without the ability to go back to a default was a real pain when you cannot boot back to a working OS.

 

I can confirm that choosing Boot Verbose from the boot menu produces the same problem as entering -v

[Azimutz]

Yes the bug in DSDT option was a big issue - especially when one is experimenting with DSDT edits and without the ability to go back to a default was a real pain when you cannot boot back to a working OS.

yeah... i know what you mean. Going to check it out...

 

About the -v, see if anyone can confirm this.

bbl...

[Andrew+]

is there a PKG version for the latest build rev 901

[MacNB]

Done some more tests on the kext cache issue and -v flag.

 

Lion creates system kext cache differently from Snow Leopard.

The boot loader does not (yet) understand how to load that cache (I believe).

 

So, i used Oldnapalm's suggestion to create a system kext cache:

sudo kextcache -v 1 -a i386 -a x86_64 -m /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /System/Library/Extensions

 

This creates the "old" style kext cache.

 

Now, if you boot with the -v flag, the loader now boots and does not load every kext.

BUT...I a KP in the kernel.

I eventually manage to reboot after several tries and deleted the created cache.

 

It appears the cache created above is not compatible (or the same) as the Lion cache.

 

So, my theory is that the -v flags causes the bootloader to check for the "old" style cache and it will not find it on Lion, so will load every kext.

[Azimutz]

is there a PKG version for the latest build rev 901

Andrew, follow the "trunk build" link on my signature; latest trunk is r1078.

 

Done some more tests on the kext cache issue and -v flag.

 

Lion creates system kext cache differently from Snow Leopard.

The boot loader does not (yet) understand how to load that cache (I believe)....

 

So, i used Oldnapalm's suggestion to create a system kext cache:

sudo  kextcache -v 1 -a i386 -a x86_64 -m  /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext  /System/Library/Extensions

 

This creates the "old" style kext cache.

 

Now, if you boot with the -v flag, the loader now boots and does not load every kext.

BUT...I a KP in the kernel.

I eventually manage to reboot after several tries and deleted the created cache.

 

It appears the cache created above is not compatible (or the same) as the Lion cache.

 

So, my theory is that the -v flags causes the bootloader to check for the "old" style cache and it will not find it on Lion, so will load every kext.

This is getting weirder by the moment... are you sure the DSDT key is working from the prompt??.. it's still messed up for me

And that's not the only one; i'm tracking this bug for a long time, i guess it's time to kill it for good damn thing...

This was working properly when i started my branch!

 

Now, about the -v, can you get the package i pointed above and test with it!?.. we need to make sure we're all talking about the same booter.

-v shouldn't cause any of this; it's just a verbose enabler, for the booter & kernel.

 

About cache creation, afaik Lion follows the same procedure and uses the same paths as Snow; only the boot arguments version

changed, which was already updated on the booter and has nothing to do with cache creation.

Anyway, this is interesting info... thanks for keeping up

Will keep an eye on this... just need to put some stuff on stand by.

[MacNB]

This is getting weirder by the moment... are you sure the DSDT key is working from the prompt??.. it's still messed up for me

And that's not the only one; i'm tracking this bug for a long time, i guess it's time to kill it for good damn thing...

This was working properly when i started my branch!

 

Now, about the -v, can you get the package i pointed above and test with it!?.. we need to make sure we're all talking about the same booter.

-v shouldn't cause any of this; it's just a verbose enabler, for the booter & kernel.

 

About cache creation, afaik Lion follows the same procedure and uses the same paths as Snow; only the boot arguments version

changed, which was already updated on the booter and has nothing to do with cache creation.

Anyway, this is interesting info... thanks for keeping up

Will keep an eye on this... just need to put some stuff on stand by.

Yup, I can definately enter DSDT path on the bootloader command line.

I am using Chameleon 2.0-RC5 (svn-r1078).

 

Here's the beginning and ending output from the bdmesg command:

Last login: Fri Jul  1 17:16:28 on console
MacNBs-MacBook-Pro:~ macnb$ bdmesg
Chameleon 2.0-RC5 (svn-r1078) [2011-06-26 01:03:30]
msr(230): platform_info 20011100
msr(234): flex_ratio 00000000
Sticking with [BCLK: 132Mhz, Bus-Ratio: 170]
CPU: Brand String:			 Intel(R) Core(TM) i5 CPU	   M 430  @ 2.27GHz
...
...
...
Read HFS+ file: [hd(0,2)/macnb.dsdt.aml] 55864 bytes.
ACPI table not found: SSDT.aml
FADT: Restart Fix applied!
FADT: Using custom DSDT!
Found ACPI CPU: CPU0
Found ACPI CPU: CPU1
Found ACPI CPU: CPU2
Found ACPI CPU: CPU3
Found ACPI CPU: CPU4
Found ACPI CPU: CPU5
Found ACPI CPU: CPU6
Found ACPI CPU: CPU7
SSDT with CPU C-States generated successfully
P-States: min 0x9, max 0x12
SSDT with CPU P-States generated successfully
RSDT: Added 2 SSDT table(s)
FADT: Restart Fix applied!
FADT: Using custom DSDT!
Added 2 SSDT table(s) into XSDT
Starting Darwin x86

MacNBs-MacBook-Pro:~ macnb$

As you can see above, I had entered macnb.dsdt.aml. It was the only flag I entered by typing:

 

DSDT=/macnb.dsdt.aml

Re Lion's handling of kext cache, I do believe it has changed. Kext Utility had to be updated. Kext Wizard also handles it differently.

As I said, I can generate the "usual" S-L-E .mkext file and the bootloader loads it but I get a KP.

hmmmm...the plot thickens.

[Azimutz]

Ok, sorry for the delay...

As you can see above, I had entered macnb.dsdt.aml. It was the only flag I entered by typing:

DSDT=/macnb.dsdt.aml

yeah, i know that much. But, try typing another argument and you'll see; the damn thing is catching the entire bootargs string instead of just the DSDT one.

And check DSDT's first call (when pci root is checked), it didn't respected your path.

Well, i know were these DSDT problems come from, but i can't figure out why the keys are not working??

It doesn't seem related with the code it self; i went back to the time when this was working properly and it doesn't work anymore.

Maybe some system header change is causing it?... will talk with the guys about this.

 

Re Lion's handling of kext cache, I do believe it has changed. Kext Utility had to be updated. Kext Wizard also handles it differently.

As I said, I can generate the "usual" S-L-E .mkext file and the bootloader loads it but I get a KP.

hmmmm...the plot thickens.

On this matter, i don't think that handling system caches manually is a good idea (unless really needed)!?

Touching S/L/E is enough to cause the system to update the caches, like Kext Wizard does when installing kexts.

I don't know why Janek added that optional to update Lion's cache??...

Can you point me to some explanation on this different Lion cache handling?... Is this related to the prelinked kernel location on the installer??

[DarwinX]

Ok, sorry for the delay...

 

On this matter, i don't think that handling system caches manually is a good idea (unless really needed)!?

Touching S/L/E is enough to cause the system to update the caches, like Kext Wizard does when installing kexts.

I don't know why Janek added that optional to update Lion's cache??...

Can you point me to some explanation on this different Lion cache handling?... Is this related to the prelinked kernel location on the installer??

 

If I understand this issue correctly, in Lion there appears to be no other way to load the /Extra/Extensions/ kexts without having to reload all caches at boot as the

 UseKernelCache=YES

boot argument only loads the proper system kernelcache.

[Azimutz]

If I understand this issue correctly, in Lion there appears to be no other way to load the /Extra/Extensions/ kexts without having to reload all caches at boot as the

 UseKernelCache=YES

boot argument only loads the proper system kernelcache.

Well, if that's the problem there's an obvious solution for it, UseKernelCache=No!

What you describe is not a booter problem, that's just how the system works and the booter respects it (for now);

if the kernelcache is loaded, all other caches (and kexts) are ignored, both in Extra or system and

no other kexts will be loaded at boot time besides the ones that are already prelinked on the kernelcache.

For now, people need to install drivers to S/L/E if they want to use kernelcache!

 

Please note that, i'm talking about an already installed and running system; in this case and afaik,

this stuff should work just like on Tiger, Leo or Snow, being the only difference, the paths for the caches.

So, unless people are trying to create the prelinked kernel in another location (like /, as in the InstallESD.dmg),

i don't know wtf is wrong with the kernelcache creation/update on Lion?!

[MacNB]

Ok, sorry for the delay...

 

yeah, i know that much. But, try typing another argument and you'll see; the damn thing is catching the entire bootargs string instead of just the DSDT one.

I see what you mean. When I entered AtiConf=Hoolock DSDT=/macnb.dsdt.aml I had a crash as soon as it started display the output...I saw that the bootloader passed "Hooklock DSDT=/macnb.dsdt.aml" as the framebuffer name to the graphics. !!

looks like parsing of the bootloader command line is screwed up.

And check DSDT's first call (when pci root is checked), it didn't respected your path.

Sorry do not know how to do that check. Are you saying that even when I enter DSDT flag on it's own, it not really loading that file ?

 

On this matter, i don't think that handling system caches manually is a good idea (unless really needed)!?

Touching S/L/E is enough to cause the system to update the caches, like Kext Wizard does when installing kexts.

I don't know why Janek added that optional to update Lion's cache??...

Can you point me to some explanation on this different Lion cache handling?... Is this related to the prelinked kernel location on the installer??

I read somewhere on these forums that Kext Utility had to be updated to to allow for Lion's change of cache handling. Janek's Kext Wizard also mentions it - it in fact only TOUCHes the the kext folder (I think) as it completes the action instantly.

Also read here http://www.insanelymac.com/forum/index.php...135&st=380# post 393 by digital_dreamer where is shows how to link the kernel and caches together.

 

now I am getting more confused about Lion cache handling

[RSN]

Hi guys. Sorry to butt in. Maybe I can help so I state my case.

 

About the extensions loading, Ive been seeing this problem since DP2 and tried every alternative with no luck. It reads all SLE kexts. Used usekernelcache=y but crashes in DP2 and DP4. Using RC5 828 Package install but effect is the same if u install RC5 manually with any version.

 

It seems like -v is also -f. (Two different machines and cpus same RC5 version).

 

Also I have a VERY weird problem maybe related.

 

The HD has Snow and Lion in different partitions#(1-2). Eventually when fooling around with kexts using Kexts Wizard or MANUALLY I cant boot anymore to either partition. Chameleon shows up but in verbose mode u can see a general corruption of RTC kext and others in either Snow or Lion. No console messages are logged. Says the magic number for RTC is mal formed or mach_o headers are corrupted. Very strange.

 

I finally saved a running image of the Snow partition to another HD and just restored the first partition (Snow) of the "damaged HD" and then I can boot both partitions and the second one is intact without any damage . If I just install RC5 again to the main partition or both, no go, delete Library caches, etc, same problem.

 

BTW, at first I worked with both HDs fooling around and when one HD died I used the other and eventually that one died too. Did a a HD in depth diagnostic with no HW errors found so its not a bad sector. NEVER had this problem with Snow or Leopard and Ive installed tons of kexts without problems.

 

My current config is intel dp67de, i7 2600, 8GB, Nvidia GT220.

 

Ive got several HDs and one has Snow(10.6.8) and Lion (DP4) so I could experiment with configs.

 

Cheers

[Azimutz]

... looks like parsing of the bootloader command line is screwed up.

 

Sorry do not know how to do that check. Are you saying that even when I enter DSDT flag on it's own, it not really loading that file ?

Yep.. screwed is the word.

Check bdmesg; dsdt is "loaded" 2 times, the first right before "Using PCI-Root-UID value: ..." just to read the UID;

the argument didn't worked there. SMBIOS key also doesn't work and what else i don't know

 

I read somewhere on these forums that Kext Utility had to be updated to to allow for Lion's change of cache handling. Janek's Kext Wizard also mentions it - it in fact only TOUCHes the the kext folder (I think) as it completes the action instantly.

Also read here http://www.insanelymac.com/forum/index.php...135&st=380# post 393 by digital_dreamer where is shows how to link the kernel and caches together.

Don't know about Kext Utility; stopped using it when the option to fix perms/repair perms was adopted, even for a 1 kext install.

Don't know if it's still that way... Been giving some use (and feedback) to Kext Wizard because Janek seems to respect and

use the system commands; if i ever find he cheats, kaput specially being closed source.

 

Digital_dreamer's post.. fall's under the jurisdiction of the "... create the prelinked kernel in another location" thing.

It seems DarwinX hit the spot...

Can you check if your kernelcache has arch and adler?.. e.g. kernelcache_x86_64.361580EE

 

Hi guys. Sorry to butt in. Maybe I can help so I state my case.

...

I've read stuff like this, yep... never happened to me and can't/don't want to reproduce it

We'll see about that; now i'm tired...

[MacNB]

Check bdmesg; dsdt is "loaded" 2 times, the first right before "Using PCI-Root-UID value: ..." just to read the UID;

the argument didn't worked there.

Yes you are right...it is loading the dsdt twice. However, the second load appears to overwrite the first.

That is, it is loading the file I want. How do I know that ? Because, the file that gets loaded has bugs in it which crashes the OS when I SLEEP (I am trying to fix sleep via this custom dsdt).

 

Can you check if your kernelcache has arch and adler?.. e.g. kernelcache_x86_64.361580EE

How do I check that as the ketxtcache file is a binary file ?

[Azimutz]

Yes you are right...it is loading the dsdt twice. However, the second load appears to overwrite the first.

That is, it is loading the file I want. How do I know that ?

As i mentioned, the first time dsdt.aml is loaded it's just to determine the PCI root.

The second time it's when the ACPI table is really loaded. It's the same file loaded twice.

How do you know the file that's being loaded?... is that what you meant?.. i think you already figured that out

 

How do I check that as the ketxtcache file is a binary file ?

LoL... just look at the file and see if it has the architecture and Adler (checksum) apended,

e.g. _x86_64.361580EE or _i386.361580EE (checksum is an example).

Anyway, i got confirmation from one of the dev's that everything works fine on Lion, when it comes to system caches.

[MacNB]

LoL... just look at the file and see if it has the architecture and Adler (checksum) apended,

e.g. _x86_64.361580EE or _i386.361580EE (checksum is an example).

Anyway, i got confirmation from one of the dev's that everything works fine on Lion, when it comes to system caches.

All I see in the Startup folder is:

MacNBs-MacBook-Pro:~ macnb$ cd /System/Library/Caches/com.apple.kext.caches/Startup 
MacNBs-MacBook-Pro:Startup macnb$ ls -l
total 46360
-rw-r--r--  1 root  wheel	 67515  1 Jul 23:13 IOKitPersonalities_i386.ioplist.gz
-rw-r--r--  1 root  wheel	 69249  1 Jul 01:35 IOKitPersonalities_x86_64.ioplist.gz
-rw-r--r--  1 root  wheel		41  1 Jul 23:13 KextPropertyValues_OSBundleHelper_i386.plist.gz
-rw-r--r--  1 root  wheel		41  1 Jul 01:35 KextPropertyValues_OSBundleHelper_x86_64.plist.gz
-rw-r--r--  1 root  wheel  23585657  1 Jul 23:13 kernelcache
MacNBs-MacBook-Pro:Startup macnb$

I don't see thing appended to the kextcache filename.

Anyway, i got confirmation from one of the dev's that everything works fine on Lion, when it comes to system caches.

Well that's nice for the dev on a real Mac but certainly not working with the Chameleon bootloader as the kexts get loaded if -v flag is entered.

[Azimutz]

Well that's nice for the dev on a real Mac but certainly not working with the Chameleon bootloader as the kexts get loaded if -v flag is entered.

What makes you think i'm talking about a dev on a real Mac???... are we talking about real Mac's here!?

I'm talking about a Chameleon dev, which most certainly will not use a real Mac to test the booter.

 

By the way, can you point me to another post, by another person, with the same -v problem?

I remember one, long time ago, not Lion related...

[DarwinX]

What makes you think i'm talking about a dev on a real Mac???... are we talking about real Mac's here!?

I'm talking about a Chameleon dev, which most certainly will not use a real Mac to test the booter.

 

By the way, can you point me to another post, by another person, with the same -v problem?

I remember one, long time ago, not Lion related...

 

In my experience with Lion, the verbose mode effectively becomes the ignore caches mode unless the UseKernelCache=YES flag is used.

[Azimutz]

Well, Apple is always playing around with stuff so, i doesn't surprise me that they changed something on this matter.

I've been missing the fact that on Lion the kernelcache is now an universal binary unlike previous OS X so, it doesn't

need the arch appended to the name. The Adler (checksum) seems gone too.

Will try to confirm the -v thing...

 

Update: it seems there are new behaviors on Lion when it comes to system caches and possibly boot args like -v...

Need more time to collect/confirm info, but none of this seems directly related to Chameleon.

Edited July 7, 2011 by Azimutz

[MacNB]

What makes you think i'm talking about a dev on a real Mac???... are we talking about real Mac's here!?

I'm talking about a Chameleon dev, which most certainly will not use a real Mac to test the booter.

Which ever developer they are, we still have a problem.

 

By the way, can you point me to another post, by another person, with the same -v problem?

I remember one, long time ago, not Lion related...

I cannot find the post but I did have this one booked marked as other have been discussing Lion kext handing. One specific post (#19) mentions the problem with verbose mode (i.e. -v) here

[meklort]

MacNN, the problem you are having is *not* do to Chameleon, but do to a change in lion.

 

In Lion, there is no /System/Library/Extensions.mkext file generated, and as such, when you *don't* use the kernel cache, chameleon cannot find an mkext (because one doesn't exist). The end result is that it's similar to using -f on Snow Leopard, even though you don't specify it.

 

The reason why using -v is so much slower, is because chameleon prints out every file it loads up when you specify -v. Printing out strings is slow, so this causes bootup to take longs.

 

Again, this is not an issue with chameleon, it's due to a change in the way lion works.

[MacNB]

MacNN, the problem you are having is *not* do to Chameleon, but do to a change in lion.

 

In Lion, there is no /System/Library/Extensions.mkext file generated, and as such, when you *don't* use the kernel cache, chameleon cannot find an mkext (because one doesn't exist). The end result is that it's similar to using -f on Snow Leopard, even though you don't specify it.

 

The reason why using -v is so much slower, is because chameleon prints out every file it loads up when you specify -v. Printing out strings is slow, so this causes bootup to take longs.

 

Again, this is not an issue with chameleon, it's due to a change in the way lion works.

Meklort,

Thx for the clarification.

I just double checked your explanation by running bdmesg and it indeed just showed that Chameleon is loading every kexts every time (with or without any flags). It takes 1:52 minutes to get to the login screen.

 

I then copied all the kexts from /Extra/Extensions to /System/Library/Extensions using Kext Wizard.

Then I booted using -v UseKernelCache=Yes boot flags and indeed it booted without loading all the kext. Boot time was 1:02 minutes (50 seconds less).

[if I do not copy the kexts in /Extra/Extensions to /System/Library/Extensions, then I get a KP as the mkext in /E/E is not being loaded by Chameleon when UseKernelCache=Yes flag is used]

 

So I agree it's not chameleon causing the problem re the -v flag. But it would be a nice new feature in chameleon if it checked for the existence of the Lion cache and load it (just like it checks for mkext currently).

 

However, there is a problem with the way it is parsing the DSDT flag as Azimutz and I have found.

[meklort]

So I agree it's not chameleon causing the problem re the -v flag. But it would be a nice new feature in chameleon if it checked for the existence of the Lion cache and load it (just like it checks for mkext currently).

 

The default setting for chameleon is to *not* load the prelinked kernel by default for one reason, and one reason only. XNu does not support loading from *both* a prelinked kernel cache, *and* additional booter extensions or mkexts. Due to this, chameleon disables the kernel cache by default unless if you specifically tell it that you want to use it. The reason it does this is that before you can use the kernel cache you *must* do one of the following:

1) Install needed extensions is /S/L/E and regenerate the cache

2) Install binpatched version of xnu that can load both the prelinked extensions and additional extensions. (currently not in the wild / not released).

3) Use a recompiled kernel with the above patch in the source code (currently none exist in the wild / released)

 

--

 

As far as the DSDT bug goes, I can tell you that it won't get fixed (atleast by me) unless if either I run into it myself (and I won't, I almost never use a custom dsdt, esp on the command line.), or if you submit a bug report. To submit a big report, please go here: http://forge.voodooprojects.org/p/chameleon/issues/ and open a new issue.

[MacNB]

The default setting for chameleon is to *not* load the prelinked kernel by default for one reason, and one reason only. XNu does not support loading from *both* a prelinked kernel cache, *and* additional booter extensions or mkexts. Due to this, chameleon disables the kernel cache by default unless if you specifically tell it that you want to use it. The reason it does this is that before you can use the kernel cache you *must* do one of the following:

1) Install needed extensions is /S/L/E and regenerate the cache

2) Install binpatched version of xnu that can load both the prelinked extensions and additional extensions. (currently not in the wild / not released).

3) Use a recompiled kernel with the above patch in the source code (currently none exist in the wild / released)

Thanks for the further explanation. Very interesting.

From that, I concur that by default, Lion booting is going to take a long time (almost twice as long). Immediate workaround is 1) above with UseKernelCache=Yes flag. Which means we will not be able to keep /S/L/E vanilla as we will have to dump kexts from /E/E to /S/L/E and keep a track of them in case of s/w updates. Not a big deal for most hacks I guess.

 

As far as the DSDT bug goes, I can tell you that it won't get fixed (atleast by me) unless if either I run into it myself (and I won't, I almost never use a custom dsdt, esp on the command line.), or if you submit a bug report. To submit a big report, please go here: http://forge.voodooprojects.org/p/chameleon/issues/ and open a new issue.

OK will do.

[ErmaC]

added compiled binaries from trunk 1138.

Remember to change the com.apple.Boot.plist in org.chameleon.Boot.plist.

 

Enjoy

 

Fabio

[Fiox89]

added compiled binaries from trunk 1138.

Remember to change the com.apple.Boot.plist in org.chameleon.Boot.plist.

 

Enjoy

 

Fabio

A little note. With this change, chameleon PrefPane do not read (and write) org.chameleon.Boot.plist in /E/E, but write the original c.a.B.p in /Library/Preferences/ecc ecc