Jump to content
ErmaC

Chameleon v2.1 (Main Trunk)

603 posts in this topic

Recommended Posts

You wont be able to use the kernelcache if booting from cd so dont even try that - additionally your bootcd would need the lion kernel on it along with a preboot.dmg relevant to your motherboard and hardware.

 

Thanks for the info, Andy.

Well the kernel was actually the only missing part, because I normally do not need

to put any kernel on the boot132-cd, using Mac DVD's vanilla one ;)

Would that mean that putting a lion-kernel would make the Lion DP2-DVD load to the isntaller ?

Hm, all this mess cause of the "kext summary"...

 

Otherwise - I don't know if you saw my feedback about booting FreeBSD,

but I would like to ask you - Were you able to boot it on GPT with your booter's version ?

Because I tested your version, but ended up in same result (again) - UFS not visible...

 

Thanx & Cheers

Share this post


Link to post
Share on other sites
Advertisement
Thanks for the info, Andy.

Well the kernel was actually the only missing part, because I normally do not need

to put any kernel on the boot132-cd, using Mac DVD's vanilla one ;)

Would that mean that putting a lion-kernel would make the Lion DP2-DVD load to the isntaller ?

Hm, all this mess cause of the "kext summary"...

 

Otherwise - I don't know if you saw my feedback about booting FreeBSD,

but I would like to ask you - Were you able to boot it on GPT with your booter's version ?

Because I tested your version, but ended up in same result (again) - UFS not visible...

 

Thanx & Cheers

 

Unfortunately FreeBSD and OpenBSD support are among many of the features that I simply can't test (I can only test with the kit I have) so just hoped they would work.

 

Regarding loading the installer from a boot cd it should be possible. I've not actually tried it however I can boot the installer from a seperate usb drive with the bootloader on it and have built several boot cd's that load the snow leopard retail installer just fine so as far as I know it shouldn't be a problem

Share this post


Link to post
Share on other sites
tnx @DarwinX for your help.

 

Anyone got any idea where the Lion's update may be located ?

Do you mean this:

 

It is also worth noting that I updated the 11a430e to 11a444d from the Snow Leopard partition via the LionSWUpdate.pkg rather than the automatic Software Update.

Share this post


Link to post
Share on other sites
Is there no way to include the /Extra/Extensions kexts within the kernelcache without having to relocate them to the /System/Library/Extensions directory?

Yes, there is; i tested that superficially a while ago, but there was always some kext/s that didn't loaded, thou they were included on the cache. We can do something like this

sudo kextcache -system-prelinked-kernel -- /Extra/Extensions

and E/E will be included as a kext repository. Again, i tried this a while ago; i'm just looking at some notes i took at the time so, don't take this as a full explanation. The main problems i see are that this is a completely manual procedure and it's obviously not "noob" friendly. Also, i didn't found a way to pass this to the system; the main kext repository is specified on /usr/standalone/bootcaches.plist but i don't think it's possible to specify a second kext repo there!?.. at least i was not able to do it.

Bottom line: S/L/E it's easiest way and the correct way (from the system point of view).

Still on this matter; i hope that this kernelcache "thing" is not going to be turned into another OSx86 "trend"! I'm using kernelcache for a while now, and at least on my system, i don't see a speed up on the boot process that fully justifies using it instead of kextcache. In my opinion, there are much more important things to be fixed on Chameleon, not to mention that it needs a good deal of restructure so this (and other things) can be implemented properly!

 

Talking about important things; beware of keys like DSDT and SMBIOS; they work fine on Boot.plist but don't when typed at boot prompt, specially the DSDT one. Just a heads up :huh:

Share this post


Link to post
Share on other sites

I can't get UseKernelCache to work, only Kabyl_LionV3 use the key but sys fail to boot with FakeSMC error.

tried rebuilding cache deleted extra Extensions.mkext with no luck, and for sure i'm not using extra folder to load any kexts.

Any hints !

Share this post


Link to post
Share on other sites
I can't get UseKernelCache to work, only Kabyl_LionV3 use the key but sys fail to boot with FakeSMC error.

tried rebuilding cache deleted extra Extensions.mkext with no luck, and for sure i'm not using extra folder to load any kexts.

Any hints !

 

If you are using the UseKernelCache=Yes option then you must make sure that any kexts that are required for your system to load are installed in System\Library\Extensions correctly.

 

I have tested this with my own build and it definitely does work (I deleted my Extra\Extensions folder and the Extra\Extensions.mkext file after moving the relevant kexts to System\Library\Extensions in order to test it).

 

I prefer the old way of doing things, much easier to upgrade a motherboard etc on a hack knowing you just need to swap a few files in the Extra\Extensions folder or can use a custom built boot cd to at least sort out the mess - noty sure it's going to be so easy in future!

Share this post


Link to post
Share on other sites

Andy

 

Can u help me

I have a problem after update the lion to the latest package. When open itunes my system become hang. Can't move the pointer. Must be restart for fix it.

 

Do u know why

Share this post


Link to post
Share on other sites
Andy

 

Can u help me

I have a problem after update the lion to the latest package. When open itunes my system become hang. Can't move the pointer. Must be restart for fix it.

 

Do u know why

 

If you are talking about the latest software update for dp2 then no because after installing that I can't even boot back into lion anymore and have to reinstall dp2 again - so looks like you are doing better than me on that score! :lol:

Share this post


Link to post
Share on other sites
If you are using the UseKernelCache=Yes option then you must make sure that any kexts that are required for your system to load are installed in System\Library\Extensions correctly.

 

I have tested this with my own build and it definitely does work (I deleted my Extra\Extensions folder and the Extra\Extensions.mkext file after moving the relevant kexts to System\Library\Extensions in order to test it).

 

I prefer the old way of doing things, much easier to upgrade a motherboard etc on a hack knowing you just need to swap a few files in the Extra\Extensions folder or can use a custom built boot cd to at least sort out the mess - noty sure it's going to be so easy in future!

and that's exactly what i did moved E/E kexts to S/L/E folder deleted E/E folder along with mkext.

ur build doesn't even load UseKernelCache key "added to boot.plist" sys still load all kexts @ start not sure what's the problem.

btw does arch=i386 key work ! i know it also doesn't work for me sys boot to 64 :lol:

dam maybe it's time to look for another bootloader, recommendation ppl !!

Share this post


Link to post
Share on other sites
and that's exactly what i did moved E/E kexts to S/L/E folder deleted E/E folder along with mkext.

ur build doesn't even load UseKernelCache key "added to boot.plist" sys still load all kexts @ start not sure what's the problem.

btw does arch=i386 key work ! i know it also doesn't work for me sys boot to 64 :lol:

dam maybe it's time to look for another bootloader, recommendation ppl !!

 

Erm my build does use the 'UseKernelCache' key and does work , are you sure you have the right build?

 

Copying the kexts to the System\Library\Extensions folder isn't enough - they need to be installed properly so either use a kext tool to do it or use terminal to chown and chmod them after copying them etc

Share this post


Link to post
Share on other sites
Erm my build does use the 'UseKernelCache' key and does work , are you sure you have the right build?

 

Copying the kexts to the System\Library\Extensions folder isn't enough - they need to be installed properly so either use a kext tool to do it or use terminal to chown and chmod them after copying them etc

It's only one kext FakeSMC and it's installed probably and i checked it again now and yes everything in order.

If ur build does use UseKernelCache key, why sys still check all kexts @ boot ?

like i said before the only build that used UseKernelCache is Kabyl_LionV3 but sys won't boot with FakeSMC error.

anyway who gonna compile build 769 for us :lol:

Share this post


Link to post
Share on other sites
anyway who gonna compile build 769 for us :lol:

 

Not much point yet as it's just a copy of trunk (760) until changes are checked in :)

Share this post


Link to post
Share on other sites

Hi

 

after several experiences with XPC and [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] without results and used" kext utilities" to repair permissions,I got success with

 

"Chameleon_RC5_752_Lion_Snow.pkg.zip" on a P67A-ud3 and SB 2400,

 

I copied my Extra folder from SL to "root" "base system" before install it, but I think the success was due to the use of "kext wizard" to repair permissions and remake Extensions.mkext ,after each file I transfer to "base System" and after installation of Lion DP1 ...

 

full working and using it now..

 

my boot .plist:

 

<key>Boot Banner</key>

<string>No</string>

<key>GenerateCStates</key>

<string>No</string>

<key>GeneratePStates</key>

<string>No</string>

<key>EthernetBuiltIn</key>

<string>Yes</string>

<key>GraphicsEnabler</key>

<string>Yes</string>

<key>Kernel</key>

<string>mach_kernel</string>

<key>Kernel Flags</key>

<string>busratio=30</string>

<key>Timeout</key>

<string>1</string

 

c.frio

Share this post


Link to post
Share on other sites

You don't need to add

 

<key>GenerateCStates</key>
<string>No</string>
<key>GeneratePStates</key>
<string>No</string>

 

they are setted No in default

Share this post


Link to post
Share on other sites
You don't need to add

 

<key>GenerateCStates</key>
<string>No</string>
<key>GeneratePStates</key>
<string>No</string>

 

they are setted No in default

 

 

Thanks "buoo"

 

c.frio

Share this post


Link to post
Share on other sites
Yes, there is; i tested that superficially a while ago, but there was always some kext/s that didn't loaded, thou they were included on the cache. We can do something like this

sudo kextcache -system-prelinked-kernel -- /Extra/Extensions

and E/E will be included as a kext repository. Again, i tried this a while ago; i'm just looking at some notes i took at the time so, don't take this as a full explanation. The main problems i see are that this is a completely manual procedure and it's obviously not "noob" friendly. Also, i didn't found a way to pass this to the system; the main kext repository is specified on /usr/standalone/bootcaches.plist but i don't think it's possible to specify a second kext repo there!?.. at least i was not able to do it.

Bottom line: S/L/E it's easiest way and the correct way (from the system point of view).

Still on this matter; i hope that this kernelcache "thing" is not going to be turned into another OSx86 "trend"! I'm using kernelcache for a while now, and at least on my system, i don't see a speed up on the boot process that fully justifies using it instead of kextcache. In my opinion, there are much more important things to be fixed on Chameleon, not to mention that it needs a good deal of restructure so this (and other things) can be implemented properly!

 

Talking about important things; beware of keys like DSDT and SMBIOS; they work fine on Boot.plist but don't when typed at boot prompt, specially the DSDT one. Just a heads up :)

I remember doing this a while back and it worked -- momentarily.

After a minute or so the system would update the kernelcache again and it would be back to the sans-E/E version. You could reboot immediately after a manual update, but the system will always revert to just what's in S/L/E eventually. :(

 

I actually tried to look into /System/Library/Caches/c.a.k.c./Directories/... for a way to manipulate the paths for E/E, but no such luck. The KextIdentifiers.plist.gz file appears to keep a list of the contents and paths of kexts, including plugins, in S/L/E.

 

As for the ExtensionsDir key in /usr/standalone/bootcaches.plist, what about creating a new repository that includes all kexts in S/L/E and E/E? It sounds like a kluge that would be prone to problems.

 

It sounds like users will be faced with two installation choices:

Kernelcache for non-vanilla S/L/E approach, but keep modified Apple-named kexts updated after SU.

Or, use mkext in /Extra (and S/L/C) or E/E approach just as we have been doing.

 

Personally, I love the kernelcache approach, as it saves some 10 secs on my boot, but hate being stuck with non-vanilla installs.

 

MAJ

Share this post


Link to post
Share on other sites
If you are talking about the latest software update for dp2 then no because after installing that I can't even boot back into lion anymore and have to reinstall dp2 again - so looks like you are doing better than me on that score! :D

 

i can boot normally on the latest update "444d", only the problem is the iTunes,

all is fine, just like my SL. Extension.mkext on Caches and on Extra are loaded fine.

 

u cant boot with the latest update?

Share this post


Link to post
Share on other sites
i can boot normally on the latest update "444d", only the problem is the iTunes,

all is fine, just like my SL. Extension.mkext on Caches and on Extra are loaded fine.

 

u cant boot with the latest update?

 

Nope once I have installed the latest update it will no longer boot to the desktop no matter which bootloader I try. I have tried swapping out the 2 NullCpuPowermanagement kexts for the original versions from dp2 but still no joy.

 

I even tried swapping the kernel back for the original from dp2 along with the ATi drivers but it still wont load the desktop. I've been too busy messing with bootloaders and making boot cd's to try and work out what's going on :(

 

If ur build does use UseKernelCache key, why sys still check all kexts @ boot ?

Maybe I did something wrong when merging the 760 code (won't be the first time) :wacko: or maybe that's how it's works in the main 760 build :blink: .

I'll add it to my list of things to look at although as my current build appears to booting snow and lion ok for most people maybe I shouldn't try and fix it :D

Share this post


Link to post
Share on other sites
Guest sincro77
didnt get you method sorry little elaboration which key to press before enter?

 

 

dunno if it matters what key .. but i have arch=i386 enabled in plist and it still tries to load lp64 kernel.

so what i did was just pressed the key "a" and pressed enter... it said unknown command at the top left real quick....than i press enter again and it loads up i386 the x86 kernel.. dont ask me why but it works for me.. maybe im lucky ..maybe it will work for someone else too .

or maybe its fixed in the newest chameleon for lion ..i dont know.... [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] usb for lion always worked but was kind of a pain in the ***.

anyways cheers..

77

Share this post


Link to post
Share on other sites
It's only one kext FakeSMC and it's installed probably and i checked it again now and yes everything in order.

If ur build does use UseKernelCache key, why sys still check all kexts @ boot ?

like i said before the only build that used UseKernelCache is Kabyl_LionV3 but sys won't boot with FakeSMC error.

anyway who gonna compile build 769 for us ;)

 

OK I have done some testing with this and it defvinitely does work. Using an SSD and UseKernelcache=No it takes 20 seconds to get to the desktop, with UseKernelCache=Yes it takes 15.

Share this post


Link to post
Share on other sites

I guess for build 444d, it's back to business with [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] or XPC until further notice.

It's a sad for us.

Share this post


Link to post
Share on other sites
OK I have done some testing with this and it defvinitely does work. Using an SSD and UseKernelcache=No it takes 20 seconds to get to the desktop, with UseKernelCache=Yes it takes 15.

 

 

Did u test it @ 444d ?

Share this post


Link to post
Share on other sites
Nope once I have installed the latest update it will no longer boot to the desktop no matter which bootloader I try. I have tried swapping out the 2 NullCpuPowermanagement kexts for the original versions from dp2 but still no joy.

 

I even tried swapping the kernel back for the original from dp2 along with the ATi drivers but it still wont load the desktop. I've been too busy messing with bootloaders and making boot cd's to try and work out what's going on :)

 

 

Maybe I did something wrong when merging the 760 code (won't be the first time) ;) or maybe that's how it's works in the main 760 build :D .

I'll add it to my list of things to look at although as my current build appears to booting snow and lion ok for most people maybe I shouldn't try and fix it :)

 

I haven't try this yet, but maybe you can "manually decrypt the Windowserver", then overwrite the original one (also do that with Dock, and some other files), file and see if it gets loaded. I think for some reason the the non AnV bootloader (this trunk branch) does not emulate fakesmc properly when the kext is loaded, or the encrypt keys has changed ?

 

edit:

 

does anyone know why Anv's lion rc3 chameleon is not able to go into single user mode?

 

I am trying to trace the launchd/launchctl, and found that its not loading coreservicesd and Windowserver.

 

also the dsmos message is from inside the mach_kernel

 

edit2:

 

I did a patch to force launchctl to go into the shell, then ran

launchctl load /System/Library/LaunchDaemons

 

but there is code_signing compliants when I load the shell like this. is it possible to resign patched binary?

or disable this check?

 

If I just type "exit" to have it boot normally, then the system reboots (I think it detects cracking)

if I use the launchctl load ... command above, I get gray screen

 

this is with AnV's kernel..

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×