Jump to content

Chameleon v2.1 (Main Trunk)

ErmaC

By ErmaC,
in Chameleon

 Share
595 posts in this topic

Recommended Posts

Dr. Hurt
Dr. Hurt
Posted
Posted

Quick question,

 

Now that many new PCs and laptops are shipping with UEFI, isn't it about time to create a Chameleon version with support for native UEFI boot? Perhaps a chameleon.efi module to be installed to the EFI partition and loaded from the UEFI boot menu. Shouldn't be too hard, I think.

 

Am I missing something?

Link to comment
Share on other sites
KariNeko
KariNeko
Posted
Posted
There is another way to do this.

Make a file named rc.local and place it in /etc, fix permissions to root:wheel

Place in rc.local this.

kextload /Volumes/EFI/Extensions/*

 

I don't use EFI partition, just make sure the /Volumes/??? actually points to the EFI folder.

Far easier to just use /Extra/Extensions and not worry about the EFI thing.

In this case the command is just kextload /Extra/Extensions/*

 

Hi STLVNUB, I followed your advice for bmas as I installed Lion and "discovered" this new thing about UseKernelCache and otherwise the default always processing kexts boot.

But even creating rc.local file on /etc, checking root:wheel ownership and permissions it's not working, because I still get the "APCI_SMC_PlatformPlugin::registerLPCDriver - Failed to locate SMC driver" error because fakesmc isn't loading from /Extra/Extensions/ (kextload /Extra/Extensions/* on rc.local).

 

Any idea?

 

Thanks in advance,

Karina

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted (edited)

Hey Bungo, are you still around??

You mention on this post:

Mem info is correct but smbios.plist overriding doesn't work for memory modules

you might have a point here.

I just noticed while comparing my Chazi with the trunk, i spotted long ago

that the mem keys are incorrect on the new code, SMmanufacturer instead of SMmanufacter, etc...

It's well known the "manufacter" misspell; i guess Kabyl overlooked it?!

This is not a fatal issue so, i'll commit it later if no one does; i'm avoiding committing to the trunk atm so it gets

easier for Meklort to pick up on the code that i reverted to get the boot prompt working as before;

if no one touches it, all we have to do is update the trunk to the previous rev.

 

----------//----------

 

Changing subject and "human target" :P

 

Reading through the kernelkcache related messages, i hope your guys realize that,

using a prelinked kernel and loading non prelinked kexts, totally defeats the purpose of using a prelinked kernel!!

There's a reason why it's called "prelinked" and why it speeds up the boot process, faster than kext cache;

from "man kextcache":

The second type of cache is the prelinked kernel, which contains the kernel code,

kext executables already linked for their run-time locations,...

 

-system-prelinked-kernel

This option is a convenience to update the prelinked kernel used for startup

on the root volume, with all kexts in the system extensions folder that have

been loaded to date. This option implies -all-loaded.

 

-r, -all-loaded

When creating a prelinked kernel, include all kexts in the system extensions

folder that have been loaded by the machine running this command during this

startup session. This include kexts loaded and later unloaded.

For those less informed, "already linked for their run-time locations" means that the load address of the kexts

and other relevant info is stored on the kernelcache, thus the kexts get prelinked. Use kextstat and you'll get the picture.

 

If loading kexts from Extra is really important for someone, then the natural thing to me is "avoid using kernelcache";

hell, we lived so long without it! Extra is very useful for the "noob" while testing; after a good setup is achieved and

a certain amount of knowledge is gathered, there's no reason to not move all the kexts to S/L/E.

Sure, when an update comes, any system kext (e.g. AppleHDA.kext) can be updated (not certain!) thus resetting

any patch applied to it, but that's it, no other kexts are touched (e.g. fakeSMC.kext).

Don't tell me that it's so damn annoying e.g. having to use a pre made rescue booter (if you don't have one, you're crazy!)

to boot the system and repair it, every 6 months or so!? It will only do you good, to remember how it's done :)

That is, if you even have to bother with that... some people are lucky enough to have almost or full support for their hardware.

Anyway, this is just my opinion; no one is forced to follow it or agree with.

Edited by Azimutz
Link to comment
Share on other sites
rednous
rednous
Posted
Posted
I still use a very old, self patched, selfcompiled Chameleon Version (RC3). Is it OK to just replace the boot file with the RC5 Version?

I remember i had to "install" boot0 and boot1h when i switched to Chameleon.

 

Absolutely, you're right, you have to update both boot0 & boot1h in that case.

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted
I just noticed while comparing my Chazi with the trunk, i spotted long ago

that the mem keys are incorrect on the new code, SMmanufacturer instead of SMmanufacter, etc...

It's well known the "manufacter" misspell; i guess Kabyl overlooked it?!

Ok, this is no overlook :P cleared it out with Kabyl...

This is the future living in the past :unsure:

  • Like 1
Link to comment
Share on other sites
FKA
FKA
Posted
Posted
Don't tell me that it's so damn annoying e.g. having to use a pre made rescue booter (if you don't have one, you're crazy!)

to boot the system and repair it, every 6 months or so!? It will only do you good, to remember how it's done :P

 

fakesmc.kext can be a bit of a bugger if you are trying to boot a working install with fakesmc in s/l/e using a boot drive that contains fakesmc - unless of course you remember to make an boot disk without fakesmc ... :)

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted
... unless of course you remember to make an boot disk without fakesmc ... :rolleyes:

I never run upon or tested that situation (or even crossed my mind),

but i also don't see any problem from Chameleon side!

We have to remember that the booter loads kexts from both E/E & S/L/E;

but that's not really a problem because, once a version of the same kext is loaded,

no more versions can be loaded;

but, since there's org.netkas.fakesmc & org.netkas.FakeSMC floating around,...

yeah, i can imagine some conflicts; this is assuming the diff bundles identifiers,

else is a kext flaw.

Unless i'm missing something?!

 

 

On a side Note: imho, Chameleon has some design flaws (well, at least 2) when it comes to loading kexts;

kexts are the "only file" the booter loads that don't have a key, to pass a diff "path to";

and the startup volume is always the first to be checked, which is not a good practice for rescue booters.

Compare trunk with Chazi (my branch), and you'll know the main reason why i started messing with the booter's code.

Refer to this text, for ugly explanations :P

Atm the keys (getValueForKey() function, to be more precise) are half broken, failing at the boot prompt.

Link to comment
Share on other sites
FKA
FKA
Posted
Posted
but, since there's org.netkas.fakesmc & org.netkas.FakeSMC floating around,...

yeah, i can imagine some conflicts; this is assuming the diff bundles identifiers,

else is a kext flaw.

Unless i'm missing something?!

 

Exactly - I was just pointing out a gotya that got me!

I don't update my boot drive too frequently but my main install has been and with the varying flavours of fakesmc.

 

BTW - should prelinked kernel option also work with Snow?

 

D

Link to comment
Share on other sites
Bungo
Bungo
Posted
Posted
*Azi takes a deep breath, counts to ten and looks at the code very carefully to explain it to Bungo...*

Many thanks for spending me your time and clearing. I'm not a coder but got a thing or two.

I thing XPC patches System UUID in SMBIOS table (checked dmidecode output before and after)

To be clear i'm talking about Hardware UUID value in System Profiler and a possibility of changing it using Chameleon. Using XPC i can override original System UUID writing a new one to setting.plist down from e.g. original MBP's DMI parsed with dmidecode then i got in my hackintosh same value of Hardware UUID in System Profiler as in MBP's. Chameleon gives different value in this case.

I conclude i should to use a Hardware UUID from MBP's System Profiler for SystemId key, or i'm wrong?

XPC_0.85.05.zip

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted
I conclude i should to use a Hardware UUID from MBP's System Profiler for SystemId key

I don't think that's necessary. It seems to me that the sequence of letters and numbers don't matter, all that matters is that the string format is correct.

I've been using Chameleon's automatic UUID patching since it was added and I have never had any trouble registering software, itunes account weirdness or any of the other issues that you can have if the HardwareUUID is not set properly (or not at all).

Link to comment
Share on other sites
FKA
FKA
Posted
Posted
BTW - should prelinked kernel option also work with Snow?

 

deffo not working for my SW RAID ... I implemented STLVNUB's suggestion for EFI installs from here, obviously swapping out for /Volumes/Boot \OSX/Extra/Extentions - but with no joy.

 

D

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted
why isn't fakesmc part of chameleon itself? no hackintosh can run without it anyways and many (us) new users have conflicts you described.

 

thanks,

stirkac

Copyright issues, i believe; not the best person to explain this those.

If the decrypt key was "public domain" there would be no problem.

Anyway, this needs to be done at the kernel level and copyright problem is also applies there.

For instance, AnV released some versions of the Voodoo kernel (now ported to the legacy_kernel)

that had the decrypter embedded, but that's he's private work.

 

BTW - should prelinked kernel option also work with Snow?

As far as i know, it should be working, both kernelcache and kext caches.

I can't test Lion on the desktop and still got no time to hack the laptop.

Anyway, the kernelcache code needs some additional work, in my opinion.

The code that Slice cooked up to load the kernel without depending on correct Adler generation,

has a flaw that can mess things under rare?? conditions. The rest of the related code,

is also not the best/correct way of doing it.

I also have this stuff cooked up in a diff way on Chazi, based "correct" Adler generation.

Those changes were all my doing while researching/testing this stuff,

except the for rules to generate the Adler, which are from RevoBoot (thanks RevoGirl :) ).

What's the specific problem? Just RAID failing?... i've seen the talk but didn't payed attention.

Can't help with RAID atm but will soon :)

I can take a look at this later, if no one does... atm my priorities are other.

 

Slice, if you read this, don't be mad at me; i'll talk with you about this matter and my findings on VoodooForums :)

 

I conclude i should to use a Hardware UUID from MBP's System Profiler for SystemId key, or i'm wrong?

Bungo, i already told you that spoofing another machine's hardware uuid is not a good idea, but that's up to you.

You need to use the uuid as shown under IODeviceTree:/efi/platform/system-id;

the one on System Profiler is converted from this one: I explained this some posts ago :P

 

-----//-----

 

By the way, if someone is interested on ATI/AMD GraphicsEnabler, take a look here.

Link to comment
Share on other sites
Bungo
Bungo
Posted
Posted
Bungo, i already told you that spoofing another machine's hardware uuid is not a good idea, but that's up to you.

You need to use the uuid as shown under IODeviceTree:/efi/platform/system-id;

the one on System Profiler is converted from this one: I explained this some posts ago :D

Found Slice's RC5m_749 (Slice_RC5m_749.zip) gives same value as XPC. RC5 (main trunk) uses another convertion algorithm? I'm confused.

I noticed this difference and wanted to know if it's a bug or doesn't metter only.

Thanks once more for spending me a time and help.

Link to comment
Share on other sites
FKA
FKA
Posted
Posted
What's the specific problem? Just RAID failing?... i've seen the talk but didn't payed attention.

Can't help with RAID atm but will soon :(

I can take a look at this later, if no one does... atm my priorities are other.

 

It no big deal just would be a nice feature to have working..

 

With UseKernelCache=Yes I'm just booting as before. no change.

 

Now I'm using /Extra/Extensions not Extensions.mkext and have added rc.local file to /etc.

I can see boot time has not changed and I can see FakeSMC (whether its boot position does change with SL or not I don't know just going on STLVNUB's comments about Lion.) loads at the same point in the boot.

 

I seem to remember for SW RAID the prelinked kernel and kext caches are loaded from the boot helper partition. I think this maybe the problem I'm having.

 

Cheers

D

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted (edited)
Found Slice's RC5m_749 (Slice_RC5m_749.zip) gives same value as XPC.

That's because Slice cooked the hardware uuid code "his way" and specially because you're using UseNVRAM=yes.

Infact, you just answered my curiosity in whether this stuff was still present or not on XPC.

When you set UseNVRAM=yes on Slice's booter, it will create "options" node on ioreg just like XPC does;

this node can't be created by the booter, or we get a uuid like 00000000-0000-1000-8000-MacAddress.

 

I think we're done about this matter! :D

At least, if you are not, i am.

 

p.s.: Just to make it clear here too, uuid code works just fine on Chameleon!

That's all i can test and guarantee :(

 

... whether its boot position does change with SL or not...

I can't remember precisely, but... i don't recall a fakeSMC load order change, from E/E to S/L/E on Snow.

Thinking better, it's probable that STLVNUB's tip about rc.local doesn't work on RAID, the software kind, i mean.

 

I seem to remember for SW RAID the prelinked kernel and kext caches are loaded from the boot helper partition.

Yep... as i was saying, at least On Apple software Raid, kernel, caches, Boot.plist, Extra, etc... it's all loaded from the

Helper partitions (AppleBoot), because it's not possible to read from system volume at early boot. The same doesn't

apply to hardware Raid.

 

Just to make it clear, the kernelcache code is working fine on non RAID volumes and Snow!

That's all i can test and guarantee.

Edited by Azimutz
Link to comment
Share on other sites
Bungo
Bungo
Posted
Posted
I think we're done about this matter! :rolleyes:

At least, if you are not, i am.

 

p.s.: Just to make it clear here too, uuid code works just fine on Chaneleon!

That's all i can test and guarantee ;)

Got it. You made my knowlege better, thanks.

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted
Yes, you there with your hands, again double characters, keys do not work!

 

 

"--vv" Enter and...

The same bug every week

Check again... this problem was fixed on r1034. No issues here!

 

Got it. You made my knowlege better, thanks.

Your welcome, Bungo :censored2:

 

So after updating Chameleon to this version, will I then be able to update my current Snow Leopard 10.6.8 to Lion no issues ?

 

Thanks !

I guess , if you don't have problems with 10.6.8, you will not have with Lion.

But, that's just a guess...

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted
@Azimutz

 

Ok, so I update Chameleon then update to Lion and all will work just fine ?

I can't test Lion atm so, i also can't guarantee.

On the booter side, i think you will not have problems...

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...