Jump to content

Chameleon v2.1 (Main Trunk)

ErmaC

By ErmaC,
in Chameleon

 Share
595 posts in this topic

Recommended Posts

Flashe
Flashe
Posted
Posted

Welcome everyone,

 

The standby system works for you? I do not work for me .

You know why ?

 

Processor interconect speed detected not displayed in System Information for me.

 

I have the dvd player that wakes up every 5 minutes. Why ?

Link to comment
Share on other sites
buoo
buoo
Posted
Posted

Wozzup ?!

 

svn: Failed to add directory 'chameleon/branches/Chimera/Chameleon.xcodeproj/.svn': an unversioned directory of the same name already exists

 

Edit: Solved :)

Link to comment
Share on other sites
DarwinX
DarwinX
Posted
Posted
oh! and what happends if you use the EFI partition?

 

Installers way will never be obsolete.

Regards.

 

The Chameleon Wizard.app by Janek provides the EFI partition support. What I did say was that this app effectively makes the CHAMELEON package installers NEARLY obsolete, which it factually does if you actually bothered to test the app. A brand new installer with very limited options must be created with each new Chameleon trunk, does that sound efficient, practical or sustainable to you? I think not. Regards.

Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

Thanks for the .ioreg.

I extracted all the info (smbios both binary and parsed, ACPI tables in aml and dsl and deviceproperties in hex and plist) and added it to the .ioreg collection.

All info is now available on this machine.

Link to comment
Share on other sites
Razorbackeve
Razorbackeve
Posted
Posted
The Chameleon Wizard.app by Janek provides the EFI partition support. What I did say was that this app effectively makes the CHAMELEON package installers NEARLY obsolete, which it factually does if you actually bothered to test the app. A brand new installer with very limited options must be created with each new Chameleon trunk, does that sound efficient, practical or sustainable to you? I think not. Regards.

 

So what is this? Efficient, practical or sustainable?

 

New version 1.6. Some fixes, EFI partition support disabled by default.

I have no idea why sometimes it doesn't work. I had no problems on my disks. I use standard commands like !Xabbu posted and I found in tutorials. I gave up trying.

 

Don´t take my words wrong, i like that program, is just that the more the options we have the better for all of us.

And in this case, i can´t use the prog cause i do use EFI partition.

 

Regards.

Link to comment
Share on other sites
DarwinX
DarwinX
Posted
Posted
So what is this? Efficient, practical or sustainable?

 

New version 1.6. Some fixes, EFI partition support disabled by default.

I have no idea why sometimes it doesn't work. I had no problems on my disks. I use standard commands like !Xabbu posted and I found in tutorials. I gave up trying.

 

Don´t take my words wrong, i like that program, is just that the more the options we have the better for all of us.

And in this case, i can´t use the prog cause i do use EFI partition.

 

Regards.

 

The app is still indeed buggy as it is in the active developmental beta stages at the moment. I've had those Chameleon package installers completely wipe out and/or corrupt my partitions which is acceptable due to the nature of this enterprise. This new app actually allows for the seamless installation of the most current product rather than the random trunk revisions which are now floating around the net. The Chameleon package installers were always nothing more than mere substitutes for the previously absent multifunctional boot loader app which we now do have thanks to Janek202. I was under the impression that those installers also handled the EFI partitions poorly or not at all.

Link to comment
Share on other sites
^Andy^
^Andy^
Posted
Posted

Spotted an error in the 898 trunk bootstruct.h:33:43: error: "/*" within comment

 

Easily fixed but surprised it got into the trunk.

 

Also took me a while to work out what was going on with the new make (kconfig) procedure lol

Link to comment
Share on other sites
Hackintosh2000
Hackintosh2000
Posted
Posted
I am quite aware of that. However, without said function the Lion boot up process is simply too slow for Lion to be viable as a main system. On the other hand, who cares about the /Extra/Extensions directory? I've never quite understood or agreed with its importance or necessity. I am quite content to keep all my kexts in the proper /System/Library/Extensions directory.

 

I know I'm a little late to the party but...

 

You don't really need UseKernelCache=Yes to use Lion. Simply boot with a GUI. If you have GUI=Yes and don't boot verbose you'll be fine. I personally can't tell the difference in speed with and without UseKernelCache when I'm using a GUI and the traditional apple and spinning bar screen. If I use verbose then I'm treated to a show consisting of watching every kext load.

 

My $0.02.

Link to comment
Share on other sites
DarwinX
DarwinX
Posted
Posted
I know I'm a little late to the party but...

 

You don't really need UseKernelCache=Yes to use Lion. Simply boot with a GUI. If you have GUI=Yes and don't boot verbose you'll be fine. I personally can't tell the difference in speed with and without UseKernelCache when I'm using a GUI and the traditional apple and spinning bar screen. If I use verbose then I'm treated to a show consisting of watching every kext load.

 

My $0.02.

 

The boot up GUI is enabled by default in Chameleon and has nothing to do with this issue as it is a purely cosmetic function.

 

<key>GUI</key>
<string>Yes</string>

Link to comment
Share on other sites
^Andy^
^Andy^
Posted
Posted
The boot up GUI is enabled by default in Chameleon and has nothing to do with this issue as it is a purely cosmetic function.

 

<key>GUI</key>
<string>Yes</string>

 

DarwinX - I'm not sure exactly what the issue is that you are having regarding the kernelcache. It seems to work fine for me - without it and using an ssd drive I can boot in roughly 15 seconds and with it I boot in roughly 10 using the latest trunk build.

Link to comment
Share on other sites
Hackintosh2000
Hackintosh2000
Posted
Posted
The boot up GUI is enabled by default in Chameleon and has nothing to do with this issue as it is a purely cosmetic function.

 

<key>GUI</key>
<string>Yes</string>

 

All I can report to you is my experience. When I do an entirely graphical boot meaning GUI boot menu and gray apple screen with spinning bar the boot process is not substantially different whether I use usekernelcache=yes or not. What does make for a painfully long boot is booting verbose without usekernelcache=yes.

 

Trust me I do not understand why a graphical boot without verbose should be so much shorter than a nongraphical boot with verbose. Logic would say they shouldn't be that different but they are on my system. I did not see this behavior in OS X 10.6.7. I guess if I ever booted 10.6.7 with Ignore Caches it would do it, but I never tried.

 

I am currently booting with Chimera 1.4.1 from the tonymac website, but to be honest I was booting fine with a number of recent Chameleon bootloaders... besides verbose mode, of course.

 

I'm not telling you this to argue with you. I just want to let you know what I think a properly working system looks like. Don't be discouraged. Something is definitely wrong. There should be a method to boot Lion in a reasonable fashion with the GUI or at very least with usekernelcache and verbose.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
All I can report to you is my experience. When I do an entirely graphical boot meaning GUI boot menu and gray apple screen with spinning bar the boot process is not substantially different whether I use usekernelcache=yes or not. What does make for a painfully long boot is booting verbose without usekernelcache=yes.
I've found that one's boot time without the kernel cache is dependent upon the boot disk's performance. On a test box with an old boot disk that can only do 61MB/sec peak, the difference with vs without cache is quite remarkable. On my laptop with an SSD boot disk, the cache makes far less difference.
Link to comment
Share on other sites
DarwinX
DarwinX
Posted
Posted
DarwinX - I'm not sure exactly what the issue is that you are having regarding the kernelcache. It seems to work fine for me - without it and using an ssd drive I can boot in roughly 15 seconds and with it I boot in roughly 10 using the latest trunk build.

 

Loading via the prelinked kernel method disallows and negates the use and the loading of the kexts from the /Extra/Extensions directory. Only the /System/Library/Extensions/ directory is utilized with the 

kernelcache=Yes

option. Of course there is always this terminal command:

 

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

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted

DarwinX, not entirely correct... explaining:

Loading via the prelinked kernel method disallows and negates the use and the loading of the kexts from the /Extra/Extensions directory.

Only the /System/Library/Extensions/ directory is utilized with the 

kernelcache=Yes

option.

When there's an "up to date" kernelcache (system prelinked kernel) the booter will ignore kexts and mkexts from both E/E and S/L/E.

If the kernelcache is not up to date (e.g. you just rebooted due to a kext installation to S/L/E) the mkexts (kext cache) are used.

If even the kext cache is out of date (rare but it can happen), than the kexts are used.

 

Of course there is always this

terminal command:

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

Why would you want to do this?? Don't you have a /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext?..

if not, your system is messed up! Usually, installing/deleting a kext to/from S/L/E is enough to start the kext cache update process;

sudo touch /System/Library/Extensions

is the correct way to trigger kext cache update.

Link to comment
Share on other sites
DarwinX
DarwinX
Posted
Posted
DarwinX, not entirely correct... explaining:

 

When there's an "up to date" kernelcache (system prelinked kernel) the booter will ignore kexts and mkexts from both E/E and S/L/E.

If the kernelcache is not up to date (e.g. you just rebooted due to a kext installation to S/L/E) the mkexts (kext cache) are used.

If even the kext cache is out of date (rare but it can happen), than the kexts are used.

 

 

Why would you want to do this?? Don't you have a /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext?..

if not, your system is messed up! Usually, installing/deleting a kext to/from S/L/E is enough to start the kext cache update process;

sudo touch /System/Library/Extensions

is the correct way to trigger kext cache update.

 

I appreciate your clarification and stand corrected. :blink:

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

@meklort

sergey:~ slice$ cd /Users/slice/Projects/Chameleons/chameleon/trunk 
sergey:trunk slice$ svn up
D	i386/libsaio/smbios_patcher.h
D	i386/libsaio/mem.h
D	i386/libsaio/ati.h
U	i386/libsaio/xml.c
U	i386/boot2/drivers.c
U	i386/boot2/gui.c
U	i386/boot2/options.c
U	i386/modules/uClibcxx/Makefile
U	i386/modules/klibc/Makefile
U	i386/modules/HelloWorld/Makefile
Updated to revision 941.
sergey:trunk slice$ make
================= make all for i386 =================
================= make all for util =================
================= make all for fdisk =================
================= make all for klibc =================
================= make all for uClibcxx =================
================= make all for Resolution =================
================= make all for HelloWorld =================
================= make all for libsa =================
================= make all for libsaio =================
[CC] xml.c
make[2]: *** No rule to make target `mem.h', needed by `/Users/slice/Projects/Chameleons/chameleon/trunk/obj/i386/libsaio/platform.o'.  Stop.
make[1]: *** [all] Error 2
make: *** [all] Error 2
sergey:trunk slice$

With rev 935

Read HFS+ file: [hd(0,3)/Extra/com.apple.Boot.plist] 501 bytes.
Invalid mach magic 0x2
Read HFS+ file: [hd(0,3)/Extra/modules/klibc.dylib] 31840 bytes.
Read HFS+ file: [hd(0,3)/Extra/modules/Resolution.dylib] 17852 bytes.
Read HFS+ file: [hd(0,3)/Extra/modules/uClibcxx.dylib] 65080 bytes.

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