virtualbox.org

Thanks. I'll give it a shot, not that I want a 10.5.8 guest. But based on what you said, it seems I shouldn't be able to run 10.6 without changing the Model ID but I am. Is VB changing it when you pick the template?

No luck.
Here's the situation. I am running OSX 10.10.4 and VB 5.0 Beta 2

I installed Snow Leopard which shouldn't run on my iMac13.2 by just changing the CPU ID
I tried to install Leopard by changing both the CPU ID and Model ID to no avail.

Hmm. The installer script for OS X 10.6 has a check in it to test the Model ID and shouldn't install it on any Macs not in the supported list, so I have no idea why Snow Leopard would install without changing the Model ID for the VM guest on your iMac13,2. Unless you're correct and VB is changing it when you pick the template. There's a line in the vbox.log file when you boot a Mac guest that should list the DmiSystemProduct that it's sending to the guest. Do a find in the log and see what it says.

I think you may be running into the same issue that is in all VB versions post-4.3.6 that keeps any OS X guests earlier than 10.6 from running under VB, since you're using VB 5.0 Beta 2.

in the vbox.log for 10.6 it says: 00:00:01.404403 DMI: Using DmiSystemProduct from host: iMac13,2

the other thing is, the only mention of cpuid in the .vbox file is:

Rats! I'll need to check on my home Mac to see why that might be. My home machine can natively run 10.6 so I never needed to check this before, but I know I wasn't able to install 10.4 and 10.5 without presenting a supported Model ID, so I thought that should be the case with 10.6. What kind of install media did you use? Was it a retail client install disc, or a server install disc, or one that came bundled with a Mac?

The CpuIdTree you see in the .vbox file is what gets written when you use the CPUID command. The devs decided to list it as decimal for some reason instead of leaving it as hex.

rpmurray wrote:Rats! I'll need to check on my home Mac to see why that might be. My home machine can natively run 10.6 so I never needed to check this before, but I know I wasn't able to install 10.4 and 10.5 without presenting a supported Model ID, so I thought that should be the case with 10.6.

What kind of install media did you use? Was it a retail client install disc, or a server install disc, or one that came bundled with a Mac?

Actually it was the developer 10.5 .dmg because when Apple decided to drop CD/DVD drives I threw away all my install disks.

The CpuIdTree you see in the .vbox file is what gets written when you use the CPUID command. The devs decided to list it as decimal for some reason instead of leaving it as hex.

I figured as much, I was just too lazy to convert them back.

Is anyone able to decipher what is preventing me applying the MacOSXUpdCombo10.5.8.dmg to my Mac OS X 10.5.6 guest? The process stalls at 27 minutes during the install. FYI, the Mac OS guest will only boot after a ‘shutdown’ as a ‘restart’ results in an aborted VM.

Alternatively, do you know if it is possible to restore my 10.5.8 time machine backup to this newly created virgin 10.5.6 VM? I presume the OS must match but I’d love to be wrong.

As always any advice would be much appreciated.

Thanks, Mark

FYI, I finally managed to update to 10.5.8 by connecting the 10.5.6. guest directly to Apple’s server rather than running the MacOSXUpdCombo10.5.8.dmg previously downloaded (also from Apple). Now to restore from Time Machine - could be interesting

You certainly are persistent.

If I may ask, what is the purpose of having a half-working version of 10.5.8?

mark.wyllie wrote:FYI, I finally managed to update to 10.5.8 by connecting the 10.5.6. guest directly to Apple’s server rather than running the MacOSXUpdCombo10.5.8.dmg previously downloaded (also from Apple).

That would have been my third suggestion, after running Repair Disk Permissions in Disk Utilities and turning off Energy Saver in System Preferences (both in the guest).

Once you get everything set up the way you want it you can try (after making a backup of the VM) to remove the AppleIntelCPUPowerManagement.kext from the "/System/Library/Extensions/" folder and restart the guest. In my testing that caused the CPU load on the host to decrease by about half for the Leopard guest. A nice side effect is that you could then also update VB to the latest releases since the kext is what causes the kernel panics in versions of VB after 4.3.6. If you're going to experiment like this though, you definitely want to back up the VM folder for this guest before you play.

Since the question has been asked, the purpose (desperation) of creating the 10.5.8 guest was because I have a bunch of apps that don't run on 10.6 and beyond plus my current 10.5.8 host machine (MacBook Pro 2007) is getting tired. Nor is it possible to boot current (i7) Macs from a 10.5.8 partition. So, with your help, today I'm delighted to have run the 10.5.8 guest hosted on my MacMini (OS 10.10.2 | Quad Core | i7 | 16GB). Once I've done the backups & experiments suggested above then restored my system & apps via a Time Machine backup of the original 10.5.8 MBP machine, I hope to be able to run my 'intensive' audio and video apps natively in 10.10.2 while having my less intensive but essential apps running on the 10.5.8 guest all hosted on one powerful new machine. Believe me this journey has been extremely worthwhile so far and looks like it will result in a solution that many of my colleagues have also been seeking.

OK; I had my OS X 10.5.8 server guest running on VirtualBox 4.3.12 on a Core 2 Duo Mac. I've since upgraded to VirtualBox 5.0.2 on an i7 Mac, with the expected pain points. Downgrading VirtualBox appears to enable it to boot. Unfortunately, VirtualBox 4.3.12 won't install under OS X 10.11, and OS X 10.7+ don't perform all that well under 4.3.12.

So does anyone have any suggestions as to how I can either a) run 4.3.12 under OS X 10.11 without uninstalling VBox 5.0.2, or b) get 10.4.11 and 10.5.8 running under 5.0.2?

Edit:  The errors shown when booting are WRT the IOKit and ACPI modules, which throw a kernel panic. So I presume newer versions of VBox aren't virtualizing in the "old" manner, causing the kexts to fail to function when passed directly to the modern hardware (or modified virtual hardware, not sure which). Has anyone found a way around this?