Chameleon > Bug Reports

Problem booting different version of Leopard using Chameleon V2 RC1

(1/2) > >>

BladeRunner:
After a few missteps caused by attempting to install openSUSE on an external MBR drive all is working quite well. Except for one thing.

On the internal GPT HDD I have EFI, WIn7, OSX 10.5.6, and Data partitions. External USB drive 1 is GPT with OSX 10.5.1 and external USB drive 2 is MBR with openSUSE 11.1.

I can boot and run Win7, OSX 10.5.6 and openSUSE with no problems. However, since the pre-boot kext/mkext from the internal HDD are always used, I can’t boot the older 10.5.1 OSX on my external drive.

We really need a method of switching to the kext from the target drive when booting any version of OSX.

Please don’t misunderstand. This is not a complaint. Just a request for a future enhancement :)

BladeRunner:
@zef: I ran several tests with two different external USB devices. First a USB stick containing a clone of my retail 10.5.1 install disk and second an external USB HDD containing 10.5.1 installed from the USB stick. Both have Chameleon v2 installed. One in the EFI partiton and one in the root partition. The results were about the same for both.

I could be way off base here but I think a part of the problem is the use of the Boot.plist from the default boot drive. The reason I say that is because I use a different kernel on the 10.5.6 system from 10.5.1 version. On 10.5.6 I use mach_kernel.voodoo (v1) and on the 10.5.1 systems it is mach_kernel.modbin. The kernel selections are coded in the Boot.plist kernel string.

When I boot from the default drive but select one of the external USB drives I see an error message about not finding mach_kernel.voodoo. If I enter mach_kernel.modbin on the command line the boot progresses much further before a KP.

I have a floppy boot mgr that can see the usb drives and directly boot the target partition. If I use it either one of the 10.5.1 systems boots and runs correctly. If I activate one of the Chameleon v2.0 on the 10.5.1 systems and then select the 10.5.6 version I see the kext loading from the 10.5.1 system. I say that because thare are several more of them and the differences in the messages is quite noticeable.

zef:
Hi BladeRunner!

Thx for your detailed description. I'm going to setup a similar scenario, but i don't have the 10.5.1 retail anymore, but can play with the 10.5.6 9G66 retail image. Hope we can find out something :)

BladeRunner:
I did some additional tests and saw some detail I had missed previously.

The internal hdd version 10.5.6 uses the voodoo kernel which disables the Intel power management kext automatically.  Therefore, no disabler.kext.  The external usb drive with 10.5.1 uses modbin (9.4) kernel which needs the disabler.kext to block the power management kext.

When I boot to the Chameleon on the internal hdd and select the external usb drive 10.5.1 system I saw the following error messages:

com.apple.kernel.6.0: Undefined in symbol set: __Z23... 

There were several of these messages followed by a kernel panic caused by the power management kext.

The kext on the external usb drive are:

root ~ # ls -al /Volumes/EFIx/Extra/Extensions
total 0
drw-r--r--   9 root  wheel  306 Apr  1 23:49 .
drwxr-xr-x  11 root  admin  374 Apr  2 12:20 ..
drw-r--r--   3 root  wheel  102 Apr  1 23:49 AppleACPIPlatform.kext
drw-r--r--   3 root  wheel  102 Apr  1 23:49 AppleDecrypt.kext
drw-r--r--@  3 root  wheel  102 Apr  1 23:49 ApplePS2Controller.kext
drw-r--r--@  3 root  wheel  102 Apr  1 23:49 AppleSMBIOS.kext
drw-r--r--@  3 root  wheel  102 Apr  1 23:49 Disabler.kext
drw-r--r--   3 root  wheel  102 Apr  1 23:49 IOATAFamily.kext
drw-r--r--@  5 root  wheel  170 Apr  1 23:49 System.kext

Using a different boot manager to get to the external usb drive, it runs correctly.

BladeRunner:
I apologize for providing data piecemeal, but it's related to the way I did the tests.  The first few were done selecting a target system on an 8Gb SanDisk Cruzer.  The last few were done selecting a system on an IBM DeskStar 120Gb hdd in an external USB enclosure.

The loading behavior is different depending on the selected target.  On this test, I selected the external hdd and saw the following. 

1) I still had to enter the kernel name - mach_kernel.modbin
2) The kext still came from an mkext cache but it was clearly the one on the target system.
3) The partition booted however, was the internal default hdd.  I can tell this because of the waiting for uuid message and the found disk0s3 message.  It should have said disk1s2

I have no clue why the loading behavior is different between the two types of target, but it is.  I think I will quit testing for a while and give you all a rest :)

Navigation

[0] Message Index

[#] Next page