Jump to content

Chameleon RC4 is out!

Poco

By Poco,
in Front Page News and Rumors

 Share
1,054 posts in this topic

Recommended Posts

rekursor
rekursor
Posted
Posted
r118 working again here, not tested with mem detection active, but this reminds me that we need a section in the prefpanel to add custom key like this new two:

UseMemDetection and DropSPD

The goal in the end is to reactive mem detection as a default and hopefully remove that options ...

BTW, it is not DropSPD but DumpSPD and this latter debug option simply gives you a validation of the mem detection process, by first listing human readable info for the mem, then displaying a binary + ascii dump of your spd content in the case mem detection does not work for you.

Same remark for this option than for UseMemDetect, it is supposed to diseappear in the mid term.

I am currently reworking the full detection algorithm that will include gpl'ed code, this work that by far goes beyond the trivial change will not be committed to the trunk for obvious reasons :)

Link to comment
Share on other sites
THe KiNG
THe KiNG
Posted
Posted
p.s. So what is next? SMBIOS override (from file) ala ACPI table patching?

This can be a good idea but I dunno if is possible, @ rekursor it is doable?

If so maybe we can just get apple one from ioregs and customized them a bit(an option in prefpane would be great or a dedicated app) using code from dmidecode

 

I am currently reworking the full detection algorithm that will include gpl'ed code, this work that by far goes beyond the trivial change will not be committed to the trunk for obvious reasons :whistle:

Huh? You lost me there...

Link to comment
Share on other sites
rekursor
rekursor
Posted
Posted
A future (binary only?) version of Chameleon will include GPL'ed source code?

Of course not, GPL is synonym of open source, and people that deal with me from start clearly know I am not the kind of folk that would not publish the sources :D

 

No, it's simply that further mem detection work will happen on my branch instead of the trunk because it could cause potentially too much regression to proceed on the trunk ...

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
Of course not, GPL is synonym of open source, and people that deal with me from start clearly know I am not the kind of folk that would not publish the sources :P

I know that [playing devils advocate again] but the person who PM'ed me didn't :wacko:

 

No, it's simply that further mem detection work will happen on my branch instead of the trunk because it could cause potentially too much regression to proceed on the trunk ...

Ah so your branch is back. Thanks for the heads up.

Link to comment
Share on other sites
Dr. Hurt
Dr. Hurt
Posted
Posted
Of course not, GPL is synonym of open source, and people that deal with me from start clearly know I am not the kind of folk that would not publish the sources :P

 

No, it's simply that further mem detection work will happen on my branch instead of the trunk because it could cause potentially too much regression to proceed on the trunk ...

 

Sincere Respect. :wacko:

Link to comment
Share on other sites
BladeRunner
BladeRunner
Posted
Posted

Back in post post #922 I mentioned that I had installed the pre12 that was attached to post #918 and could no longer boot the system without using a pre-boot CD.

 

I did some digging and more re-boots than I would care to count, but I have isolated the problem and worked around it. I think what i found is interesting and might need some attention.

 

As background, my hardware (old iron) is listed in my sig. Suffice to say, I need a patched kernel to run OS X. Since I want to be able to use software update with minimum chance of re-boot failures I install the kernel with an alternate name and reference it in the boot.plist e.g.,

	<key>kernel</key>
<string>mach_kernel-10.6.2</string>

 

In addition, I had been running VMware Fusion which requires the running kernel to be named "mach_kernel". To resolve that issue it was recommended that I use a sym-link. e.g.,

ln -s mach_kernel-10.6.2 mach_kernel

 

So, that was my environment. When I tried to boot using the RC5-pre12 boot code I saw about three lines of text and then back to the boot menu. By long term holding of the enter key I got the messages displayed enough times to see references to mach_kernel and a bad magic number.

 

If I removed the sym-link, and left the kernel named "mach_kernel-10.6.2" the boot still fails. Then, the messages say "can't find mach_kernel". If I copy the kernel so that both "mach_kernel" and "mach_kernel-10.6.2" exist, the system boot without problem.

 

What surprised me was that the boot process did not use the kernel name from the boot.plist. You obviously scanned the boot.plist for things like which partition was the default and which ones to hide etc... So, why not use the kernel name found in the boot.plist?

 

Well, that's what I found and my 2 cents worth. And, thanks for listening.

 

Edit: also, note that the existing code could not handle the sym-link - that is what was causing the bad magic number error.

Edit-2:I see in the options.c code where boot is looking for the a kernel name override. Question is, why didn't it find it in the /Extra/com.apple.Boot.plist file?

Link to comment
Share on other sites
zef
zef
Posted
Posted
Do we still need to add bs=512 count=2 in boot1h ?

 

This way you can make sure that dd won't touch more than 2 sectors on your HFS partition even if the input file file size exceeds (boot1h in this case) 1024 bytes.

Link to comment
Share on other sites
zef
zef
Posted
Posted
Edit: also, note that the existing code could not handle the sym-link - that is what was causing the bad magic number error.

Edit-2:I see in the options.c code where boot is looking for the a kernel name override. Question is, why didn't it find it in the /Extra/com.apple.Boot.plist file?

 

Yes, the current HFS filesystem implementation in the booter doesn't support symlinks (never did). Did you try booting with Kernel=your_mach_kernel option added at the boot prompt?

 

I believe that you have another boot.plist somewhere on your target drive which overrides the default settings.

 

When the booter starts, it tries to pickup the initial boot.plist in the following order:

 

http://forge.voodooprojects.org/p/chameleo...ingTable.c#L607

 

After you selected your target volume, the booter loads a second boot.plist to able to override the default values loaded in the first pass. This time this is the loading order:

 

http://forge.voodooprojects.org/p/chameleo...ingTable.c#L647

 

Not all keys/values will be overridden:

 

http://forge.voodooprojects.org/p/chameleo...ingTable.c#L482

Link to comment
Share on other sites
BladeRunner
BladeRunner
Posted
Posted
Yes, the current HFS filesystem implementation in the booter doesn't support symlinks (never did). Did you try booting with Kernel=your_mach_kernel option added at the boot prompt?

 

I believe that you have another boot.plist somewhere on your target drive which overrides the default settings.

 

I did not try entering the kernel name at the boot prompt. I never doubted that it would accept it from there.

 

Other than the copies of the boot.plist found in the TimeMachine backup found on /Volumes/TimeMachine, there are two that I know of.

 

bash-3.2# find -x / -name com.apple.Boot.plist
/Extra/com.apple.Boot.plist
/Library/Preferences/SystemConfiguration/com.apple.Boot.plist
bash-3.2#

bash-3.2# grep ernel /Extra/com.apple.Boot.plist
<key>Kernel Flags</key>
<key>kernel</key>
<string>mach_kernel-10.6.2</string>
bash-3.2# grep ernel /Library/Preferences/SystemConfiguration/com.apple.Boot.plist
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
bash-3.2#

 

The difference I just noticed is that the key name in the copy in my /Extra directory is lower case. I will change that and retest.

 

Thanks for the code pointers. I had been searching code but not yet located those.

 

Update: I checked a few of the boot.plist copies in the TimeMachine backup and NONE had a lower case kernel key name. I changes the key name in my boot.plist in the Extra directory and removed the "/mach_kernel" I had placed there for testing. All works as it should.

 

I apologize for cluttering up the thread with my self inflicted errors :whistle:

Link to comment
Share on other sites
zef
zef
Posted
Posted

@BladeRunner:

 

Sorry,

 

The kernel can be specified as the first argument at the boot prompt command line without using any key name like:

 

rd(0,0)/my_custom_kernel -v etc...

 

And also can be set in the boot.plist files using the "Kernel" key. For a quick test, I changed my target volume's /Extra/com.apple.Boot.plist's Kernel key to "mach_kernelx", then after rebooting I got the can't find /mach_kernelx message. This means the override works :whistle:

Link to comment
Share on other sites
Smith@@™
Smith@@™
Posted
Posted

Observation. I noticed that with the latest versions rc5 of cham i have a "big" problem on two of my desktop and same problem on my vaio: simply, often, very often, the keyboard is not recognized and on my notebook also the trackpad, very often. With rc4 or pcefi 10.6 or with asere boot or with early versions of cham rc5 i haven't NEVER this problem. Are days and days I'm trying and I'm SURE the problem is the booter, not the kexts or other things.

The keyboard is "broken" to start, to boot, it is as if to the boot was not always recognized.

Once in the system, it still works, hence the problem is that to the boot i can't always choose " the options". On my vaio the problem , this problem is bigger because it brokens also the trackpad and... restart, restart, always, often...

 

It's strange that I am the only one who noticed this little problem, the broken keyboard to boot, on three configurations.

 

Now I'm using the boot of Asere and the problem has completely disappeared, but I would use cham rc5 hoping that the problem can be solved ....

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

@smith@@

 

I have also recently had the keyboard issue where the keyboard didn't work in the booter. It happened a couple of times but I haven't had the problem since. Thing is though I can't remember if I have changed the version of the booter since it happened so I can't give accurate feedback, but I can confirm you are not alone. If it happens again, I will record the build number.

 

I am currently using r112 and the keyboard works.

Link to comment
Share on other sites
XLR
XLR
Posted
Posted

Hey guys! Can anyone tell me please where does prefPane saves it's configuration files, especially the EFI Injections? I've installed some new hardware and want to delete my old device properties but can't do it, they always come back. Tried deleting the Chameleon-devprop.plist and com.Chameleon.prefpane.plist but it's still there...

 

EDIT: Nevermind, ignore me. It sorted out after reboot.

Link to comment
Share on other sites
thiagomorales
thiagomorales
Posted
Posted
@smith@@

 

I have also recently had the keyboard issue where the keyboard didn't work in the booter. It happened a couple of times but I haven't had the problem since. Thing is though I can't remember if I have changed the version of the booter since it happened so I can't give accurate feedback, but I can confirm you are not alone. If it happens again, I will record the build number.

 

I am currently using r112 and the keyboard works.

 

Very strange..Only to report:

I´m currently using r117 and i didn´t noticied any issue with keyboard...

 

Regards.

Link to comment
Share on other sites
ErmaC
ErmaC
Posted
Posted
I had some problem too,

keyboard enter key not working, but other keys working, i was thinking theme related, but now I suspect the bootloader be the cause

 

I confirm this "issue" same for me too

 

numkeypad not work with AsereBNL v1.1.9 (I try inside firefox 3.5.8)

numkeypad work with Chameleon RC5 pre8 (I try inside firefox 3.5.8)

 

Fabio

Link to comment
Share on other sites
apoll
apoll
Posted
Posted

Hi!

Could not find a single boot and having Restart fix and correct operation sleepimage

Example:

Netkas boot10.3 (10.5) sleepimage - Works! Restart fix-not working

Rekursor boot_RC4 Restart fix - Works! Sleepimage - does not work - requires an increase sleepimage

Tested on a laptop Dell_Vostro_ A860

This problem has a solution? (Netkas boot + Rekursor and similar boot)

Tested my boots: RC5pre6 rekursor's; RC5pre18 - Build 112; AsereBLNv1.1.9 (1); PC-EFI 10.3 (and above) Netkas

Sorry for my English

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