Jump to content

Virtualizing Mac OS X 10.5.8 on a new MacBook Pro with Retina


8 posts in this topic

Recommended Posts

I have a problem that is driving me crazy:

My retired uncle had a Macbook Pro (early 2008), which started failing and eventually died.

 

He was running:

·      Mac OS X 10.5.8 (Leopard) – the reason for this being, that he was still using a lot of PowerPC applications, and 10.5.8 was the last version supporting that

·      VMware Fusion 1.1.3 – in order to run Windows XP

 

I managed to rescue his old (also failing) harddisk, and created a 200GB diskimage file.

 

We then bought a new Macbook Pro (late 2013) – 15 inch with Retina display. And of course: OS X 10.9.1 (Mavericks).

I installed VMware Fusion 6.0.2 on this and transferred his Windows XP without any problems.

 

The task would then be to virtualize his old Mac on the new one! And this is where the challenges began!

 

I have a Macbook Pro myself (early 2011) – 17 inch with OS X 10.9.1 and VMware Fusion 6.0.2. So I thought I would just create the VM on my Mac and then transfer it to his new Mac.

I tried different solutions until I finally found the unlocker 1.2.0 here – thank God for that! So I got his old Mac up and running as a VM.

Simple task now: Run the unlocker 1.2.0 on his Mac, transfer the VM files - peace of cake …. NOT!

 

During boot it ended up with this error:

 

 

 

 

It didn’t help to restart, and I haven’t been able to locate the cause of this.

 

I compared vmware.log on his and my system to find where it started differing. Being different hardware there would be difference, of course, but up until the two lines below it was basically the same:

 

2014-01-08T19:59:45.492+01:00| vcpu-0| I120: UHCI: HCReset

2014-01-08T19:59:45.708+01:00| vcpu-0| I120: APIC THERMLVT write: 0xdc

 

The following lines are from his system, where it appears to begin shutting down:

 

2014-01-08T19:59:49.336+01:00| vmx| I120: VNET: MACVNetLinkStateTimerHandler: ethernet0: state from 1 to 5

2014-01-08T19:59:57.726+01:00| vmx| I120: VMXVmdbCbVmVmxExecState: Exec state change requested to state poweredOff without reset, soft, softOptionTimeout: 0.

2014-01-08T19:59:57.726+01:00| vmx| I120: Stopping VCPU threads...

2014-01-08T19:59:57.727+01:00| svga| I120: SVGA thread is exiting

2014-01-08T19:59:57.732+01:00| mks| I120: MKS-SWB: Number of MKSWindows changed: 1 rendering MKSWindow(s) of total 1.

2014-01-08T19:59:57.732+01:00| mks| I120: GL-Backend: stopped by HWinMux to do window composition.

2014-01-08T19:59:57.732+01:00| mks| I120: MKS-SWB: Number of MKSWindows changed: 0 rendering MKSWindow(s) of total 0.

2014-01-08T19:59:57.741+01:00| mks| I120: GL-Backend: stopped by renderMux to do screen composition.

2014-01-08T19:59:57.741+01:00| vmx| I120: USB: Disconnecting device 0xa00000000e0f0008

2014-01-08T19:59:57.741+01:00| vmx| I120: USB: Disconnecting device 0x4000000105ac020b

2014-01-08T19:59:57.741+01:00| vmx| I120: USB: Disconnecting device 0x400000050e0f0003

2014-01-08T19:59:57.741+01:00| vmx| I120:

2014-01-08T19:59:57.741+01:00| vmx| I120+ OvhdMem: Final (Power Off) Overheads

 

I then decided, that it might be necessary to build it from scratch on his Mac instead of transferring it from mine.

 

I furthermore decided to make a test first, where I would install a raw OS X 10.5.8 VM on his system – but alas, I ended up with the exact same error when it booted from the install media (being an ISO file mounted on the virtual DVD drive).

 

I ran the same test on my Mac to verify that I was actually doing it right – and ended up with a virtual OS X 10.5.8 system in 30 minutes – working like a charm.

 

So – a very long intro – and now I ask: What is wrong here?

 

I have this feeling that it is something very simple.

 

From af virtual machine perspective, VMware Fusion should present a more or less independent virtual environment.

 

Could it be:

·      The unlocker should be updated in order to make further changes to the vmware-vmx files?

·      VMware Fusion is not creating a proper neutral environment?

·      Manual parameters required for the EFI boot process?

·      Other?

post-1274738-0-69453600-1389361678_thumb.png

Link to comment
Share on other sites

Well there is no reason to use the unlocker on a real Mac, Fusion can virtualize OS X just fine on the correct hardware. However you may have a Apple model specific image and ISO, which is not the same as the retail version and cannot boot unless on the same hardware. The other issue is that the CPU may be too new for the kernel in Leopard. However Fusion 6 is meant to deal with this silently by masking out features that are too new.

 

I suggest you post the vmware.log file either as an attachment here or use a gist and paste the link. Please do NOT paste it directly into the post as it makes following the thread very difficult.

Link to comment
Share on other sites

Hi Donk,

 

You will find the entire vmware.log file from his system here:

 

http://www.hrouda.dk/Leopard-VM/vmware.log

 

I actually have the original Leopard Retail install DVD, but it wouldn't boot on my system until I ran the unlocker.

Before running the unlocker, I found an ISO file online, which I used.

I need to use an ISO file (or an external DVD-drive) on his Mac, since it hasn't got an internal drive.

I haven't tried that, though. I could do that the next time I get my hands on his Mac.

 

I really appreciate that you're looking into this.

 

Link to comment
Share on other sites

I can't see anything wrong so far in the logs. However I am a dumb-ass, you do need the unlocker to allow the non-server version of Leopard to boot!!

 

I will download a Leopard DVD from Apple Dev Centre and try it out, but my guess is the CPUID instruction needs to be masked to present an older processor type to Leopard. Make sure that you use a retail DVD or image, and to be honest I wouldn't download something from the web, usually full of junk that messes with VMware.

 

Whilst I am checking that out you could try it yourself by adding this line to the VMX file for the guest whilst it is powered down:

cpuid.1.eax = "0000:0000:0000:0001:0000:0110:1010:0101"

or this one:

cpuid.1.eax = "----:----:----:0010:----:----:1010:0111"
Link to comment
Share on other sites

Hi Donk,

 

I managed to get my hands on his Mac tonight - and with a touch of success :-)

 

I tried the "cpuid.1.eax" parameter with no success.

 

I created a new ISO-file from the original Retail version DVD. Tried it on my Mac - it installed without any problems.

When I booted from it on his Mac, the system came with a slightly different error - i.e. it didn't ask me to restart.

I managed to translate that into (via Google):

During boot the system looks at available hardware - and will find an i7 CPU capable of 8 processor cor

es.

But Leopard apparently only supports a maximum of 2 cores - thus it exits with an error.

I found a vmx parameter called "cpuid.coresPerSocket". Setting it to "2" made the system boot ... WOW :-)

I then managed to install Mac OS X 10.5 on his new Mac.

Then I ran the first software update, that would (combo)upgrade it to 10.5.8 - and rebooted directly into the old error - Hmmmprrfff !!!

 

I got a small step further - but still not all the way. And it still puzzles me, since my Mac also has an i7 processor with 8 cores ...

 

But at least I got a step further - guess it's all about the correct vmx parameters.

Link to comment
Share on other sites

Hi Donk,

 

I managed to get my hands on his Mac tonight - and with a touch of success :-)

 

I tried the "cpuid.1.eax" parameter with no success.

 

I created a new ISO-file from the original Retail version DVD. Tried it on my Mac - it installed without any problems.

When I booted from it on his Mac, the system came with a slightly different error - i.e. it didn't ask me to restart.

I managed to translate that into (via Google):

During boot the system looks at available hardware - and will find an i7 CPU capable of 8 processor cor

es.

But Leopard apparently only supports a maximum of 2 cores - thus it exits with an error.

I found a vmx parameter called "cpuid.coresPerSocket". Setting it to "2" made the system boot ... WOW :-)

I then managed to install Mac OS X 10.5 on his new Mac.

Then I ran the first software update, that would (combo)upgrade it to 10.5.8 - and rebooted directly into the old error - Hmmmprrfff !!!

 

I got a small step further - but still not all the way. And it still puzzles me, since my Mac also has an i7 processor with 8 cores ...

 

But at least I got a step further - guess it's all about the correct vmx parameters.

Hi phrouda,

 

Glad you made some progress, sorry you still have an issue. Have you tried trying the CPUID mask since the update to 10.5.8, it may still not work as certainly the CPUID mask ending in 0101 was created by myself and Donk based on a Quad Core Xeon 5520 processor, so we may need to try and find an earlier CPU to create a 2 core based CPUID mask.

 

In terms of why it works with your i7 and not with the new i7 is probably down to the generation of the processor, Apple are pretty specific with OS support and processors, they often bring out a patched version of OS X if they introduce a new version of a processor in one specific Apple Mac.

Link to comment
Share on other sites

Major breakthrough! I have it up and running on his Mac now :-)

 

I created a "raw" 10.5 virtual machine from the original retail DVD as previously explained.

I then migrated his user (documents, applications etc.) to the VM, and was able to login. Everything worked.

Made a VMware snapshot.

I then started a cyclic process of updating Mac OS, testing and creating a VMware snapshot.

I went from 10.5 to 10.5.1, 10.5.2, 10.5.3, 10.5.4, 10.5.5 10.5.6 - and then it crashed with the above mentioned (kernel) panic.

I restored to the 10.5.5 snapshot, and tested that everything worked. It did.

 

And I'm gonna leave it there.

 

I'm not quite sure exactly what happened from 10.5.5 to 10.5.6 that would cause this error - except that the darwin kernel was upgraded from 9.5 to 9.6.

The generel Mac OS X 10.5.6 update description doesn't ring a bell.

 

Anyway - thank you for the time you spent here ... it's a great website!

 

Take care :-)

Link to comment
Share on other sites

 Share

×
×
  • Create New...