Installing Pre Snow Leopard guest OS X in VB 5.1.x

[rpmurray]

I'm currently in the process for moving from OS X Snow Leopard (10.6.8 ) and VirtualBox 4.3.6 to OS X El Capitan (10.11.6) and VirtualBox 5.1.12.

The host machine is an iMac i7 3.4 27-Inch (Mid-2011).

Two of my guest virtual machines are giving me problems. They are OS X Tiger (10.4.11 - intel version) and OS X Leopard (10.5.8 ). Up through VB 4.3.6 they ran without difficulty, see Status of OSX on OSX for details.

The devs have made some changes since then that have the side-effect of causing these VMs to both fail to boot with kernel panics. After futzing around with both of them for awhile I've managed to get Leopard to run but Tiger is putting up a fight. For Leopard I was finally able to get it to run by using the following two commands in Terminal:

VBoxManage setextradata "Leopard" "VBoxInternal/CPUM/MSRs/Ia32MiscEnables/First" 0x000001A0
VBoxManage setextradata "Leopard" "VBoxInternal/CPUM/MSRs/MsrPmgCstConfigControl/First" 0x000000E2

Leopard in this case being the name of my VM. These two commands were enough to get it past the kernel panic and running. Seeing as the same two error messages that brought me to this solution also exist in the Tiger VM log I tried them there but no joy.

So, my next experiment was to try to create a Leopard VM from scratch using the installer disc. Since I already had working settings in the Leopard VM that I'd updated I just created a new VM with those same settings and attempted the install process. Much to my surprise this did not work. But the kernel panic I'm getting is the same as what I see with the Tiger VM. At this point I searched the forums and discovered two possible leads. One is a user that apparently has Tiger running in VB 5.1.10 on Sierra Tiger guest on Sierra host. The user provided some log files and after working on various settings I was able to get my Tiger VM to produce a log that is identical (except for unique things like UUIDs) up until the point where my VM kernel panics and his doesn't. I'm kind of hoping that user will sign back on and provide some details about the settings he used. The other lead is that a moderator in these forums, socratis, had Leopard working in VB 5.0.x and I'm hoping he will see this post and provide some details about how he did that, if it was different from my solution. It could be that may also help me get the VM installed from disc.

In the meantime I'll continue to work on both of these VMs and see if I can get them working.

One thing that I noted in the Leopard VM is that when I have it running and the Enable Nested Paging option is checked that the cursor issue mentioned here Host cursor is showing on guest cursor does not happen until I move the cursor outside the window of the VM. I get just the single cursor and can click on items with no problem. When I move the cursor outside the window and then move it back then I get the two cursor issue. If I check the Enable Nested Paging option then the twin cursors appear immediately once the VM is running, even when I don't move the cursor outside the window first.

[socratis]

One of the reasons that I started the "Status of OSX on OSX" thread was:

Background: I tried to make a fresh installation of a 10.5 guest on a 10.6.8 host with VB 4.3.12. It failed. I went back several VB versions to see what works and what doesn't. This post is the result of this exercise.

And what I discovered was that I could install 10.5 in VirtualBox between 4.3.0 and 4.3.6. Only. After that it has run fine, including in the as of today latest and greatest 5.1.12. It does not install on 5.1.12. Don't know why, which leads me to my next question:

VBoxManage setextradata "Leopard" "VBoxInternal/CPUM/MSRs/Ia32MiscEnables/First" 0x000001A0
VBoxManage setextradata "Leopard" "VBoxInternal/CPUM/MSRs/MsrPmgCstConfigControl/First" 0x000000E2

Where on earth did you come up with these? And why? There is no reference that I could search for, so why? How did you know? I'm asking that because you were the first (and only) so far to raise and use the "cpuidset" modification command. Both exotic settings, so the source of your clues can potentially hold more clues?


One other thing that I bumped into, but never had the time to test, is from bug 16254. In there, "bird" mentioned the following modification command:

• VBoxManage modifyvm "<VM_Name>" --cpu-profile "Intel Xeon X5482 3.20GHz"

Now, given that the cpu-profile value is highly specific, I searched for and I found that it refers to a CPU entry, one among the ones in "CPUMR3Db.cpp", with the actual detail implementations in the "cpus" sub-directory: https://www.virtualbox.org/browser/vbox ... VMMR3/cpus

Another clue is in /src/VBox/Main/src-client/ConsoleImpl2.cpp:

Code: Select all

if (fOsXGuest)
{
    /* Expose extended MWAIT features to Mac OS X guests. */
    LogRel(("Using MWAIT extensions\n"));
    InsertConfigInteger(pCPUM, "MWaitExtensions", true);

    /* Fake the CPU family/model so the guest works.  This is partly
       because older mac releases really doesn't work on newer cpus,
       and partly because mac os x expects more from systems with newer
       cpus (MSRs, power features, whatever). */
    uint32_t uMaxIntelFamilyModelStep = UINT32_MAX;
    if (   osTypeId == "MacOS"
	|| osTypeId == "MacOS_64")
	uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482. */
    else if (   osTypeId == "MacOS106"
	     || osTypeId == "MacOS106_64")
	uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */
    else if (   osTypeId == "MacOS107"
	     || osTypeId == "MacOS107_64")
	uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure out
									what is required here. */
    else if (   osTypeId == "MacOS108"
	     || osTypeId == "MacOS108_64")
	uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure out
									what is required here. */
    else if (   osTypeId == "MacOS109"
	     || osTypeId == "MacOS109_64")
	uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure
									out what is required here. */
    if (uMaxIntelFamilyModelStep != UINT32_MAX)
	InsertConfigInteger(pCPUM, "MaxIntelFamilyModelStep", uMaxIntelFamilyModelStep);
}

where the comment says pretty much that they have to fake the CPU for OSX guests in order to make it happen. Which they don't (at least not here). They have a case-if-then, but they all point to the same Penryn processor. So if you tweak this it might work?

But as I said, try to install 4.3.0-4.3.6 and see if you can install 10.5.

[rpmurray]

Where on earth did you come up with these? And why? There is no reference that I could search for, so why? How did you know? I'm asking that because you were the first (and only) so far to raise and use the "cpuidset" modification command. Both exotic settings, so the source of your clues can potentially hold more clues?

What, you want me to pull back the curtain and expose all my secrets, thereby revealing that I am not the wizard I appear to be?

If I remember correctly I came upon using the cpuidset command when installing OS X Tiger as a guest and the verbose text you get on startup would complain about an unknown CPU. This was back in the days of VB 4.0.x. I'd previously seen the cpuidset command in the VB manual and after digging around on intel's website was able to determine which leaf I needed to adjust. I wasn't sure at the time if Apple might not have more extensive checks for the CPU but it turned out they didn't and it worked so I was happy. I've since found that I wasn't the first to discover this and that others had already learned this well before I did.

As for the two MSRs; when moving the Tiger and Leopard VMs from 4.3.6 to 5.1.10 I noticed in the Leopard log the following when starting under VB 5.1.x:

IEM: wrmsr(0x1a0,0x0`00041c01) -> #GP(0)
IEM: wrmsr(0xe2,0x0`1e000001) -> #GP(0)

A little Google-fu led me to a page that explained what these errors meant and how to use the setextradata command to modify the MSRs to get past them. The three relevant commands are:

VBoxManage setextradata VM “VBoxInternal/CPUM/MSRs/name/First value
VBoxManage setextradata VM “VBoxInternal/CPUM/MSRs/name/Last value
VBoxManage setextradata VM “VBoxInternal/CPUM/MSRs/name/Value value

I already knew about these commands from running into the problems of installing onto 4.3.8 but up till now hadn't found anything that explained how to use them.

Thanks for the tip about the cpu-profile, I'll play with it and see if that gets me any further. I am kind of disappointed that there is no (current) way to install the Leopard guest directly into VB 5.1.x. The fact that it can be moved from VB 4.3.6 to 5.1.x and still works makes me wonder what is blocking it from installing directly into 5.1.x.

[socratis]

The fact that it can be moved from VB 4.3.6 to 5.1.x and still works makes me wonder what is blocking it from installing directly into 5.1.x.

I've been trying to figure it out myself for years. The installer seems to be really picky about where it is allowed to get installed. The actual OS, not that much. Weird at its best. My best guess? Prevent installation on anything but approved systems/components, but allow the flexibility to the developers to "move" and test the OS to uncharted territories.

I was collecting some CPUIDS from different user reports. Mine is the MacBook8,3 and the funny part is that it gets different leafs depending on the guest. This was prior to discovering the CPU description files. Here's a list:

Code: Select all

------------------------------
MacBookPro8,3
------------------------------
XP
Gst: 00000001  000206a7 00040800 00000201 178bfbff
Hst:           000206a7 02100800 1fbae3ff bfebfbff

8.1
Gst: 00000001  000206a7 00020800 00002201 178bfbff
Hst:           000206a7 07100800 1fbae3ff bfebfbff

Fedora_64, Ubuntu, Windows7
Gst: 00000001  000206a7 00020800 00000201 178bfbff
Hst:           000206a7 06100800 1fbae3ff bfebfbff

RedHat_64, 10.5, 10.7.x, 10.10, 10.10.1, OpenSolaris
Gst: 00000001  000206a7 00020800 80000201 178bfbff
Hst:           000206a7 04100800 1fbae3ff bfebfbff

WindowsNT4, LiveCDs (Ubuntu), Linux (Android 4.4.2)
Gst: 00000001  000206a7 00000800 00000209 078bfbff  # 'Intel Core i7-2635QM'                      (INTEL 0x6/0x2a/0x7 Intel_Core7_SandyBridge)
Hst:           000206a7 00100800 1fbae3ff bfebfbff  # 'Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz' (INTEL 0x6/0x2a/0x7 Intel_Core7_SandyBridge)

------------------------------
MacBookPro5,2
------------------------------
Gst: 00000001  0001067a 00000800 00000209 078bfbff  # 'Intel Xeon X5482 3.20GHz'                    (INTEL 0x6/0x17/0x6 Intel_Core2_Penryn)
Hst:           0001067a 01020800 0408e3fd bfebfbff  # 'Intel(R) Core(TM)2 Duo CPU' T9600  @ 2.80GHz (INTEL 0x6/0x17/0xa Intel_Core2_Penryn)

------------------------------
MacBookPro11,1
------------------------------
Gst: 00000001  000306a9 00000800 80000201 078bfbff  # 'Intel Core i5-3570'                       (INTEL 0x6/0x3a/0x9 Intel_Core7_IvyBridge)
Hst:           00040651 03100800 7ffafbbf bfebfbff  # 'Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz' (INTEL 0x6/0x45/0x1 Intel_Core7_Haswell)

------------------------------
MacBookPro11,3
------------------------------
Gst: 00000001  00040661 07100800 7ffafbff bfebfbff  # 'Intel Core i5-4850HQ' (INTEL 0x6/0x3a/0x9 Intel_Core7_IvyBridge)
Hst:           00040661 00020800 00000201 178bfbff  # 'Intel Core i5-3570'   (INTEL 0x6/0x3a/0x9 Intel_Core7_IvyBridge)

------------------------------
iMac12,2
------------------------------
Gst: 00000001  000206a7 00000800 00000209 078bfbff  # Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Hst:           000206a7 00100800 1fbae3ff bfebfbff  # 'Intel Core i7-2635QM' (INTEL 0x6/0x2a/0x7 Intel_Core7_SandyBridge)

Plus there are two related bugs open, but they haven't received too much love:

• https://www.virtualbox.org/ticket/13069 (yours)
• https://www.virtualbox.org/ticket/13118

What I'm going to do is to compare the 4.3.6 and 4.3.8 source trees, hoping to find what changed in between these two versions and made 10.5 uninstallable. Stay tuned, but it may take a while...

[okiuss]

Leopard ( 10.5.8 ) installed with the upgrade cd from Tiger ( 10.4.11 ) and all available online
updates works without the "still waiting for root device" problem.

[michaln]

Apple did not make the OS X installer intentionally picky. The core problem is that there is code in OS X, and especially in the infamous
AppleIntelCPUPowerManagement.kext, that is highly CPU specific and not at all written with future CPUs in mind. What that means is that an OS X installation DVD shipped with generation X Mac would simply crash when booted on generation X + 1 Mac. It didn't help that Intel OS X was done at a time of rapid change. The initial development was all done on Pentium 4 boxes, but the release targeted only Intel Core Duo (Yonah) 32-bit CPUs. A few months later (early 2007?), Apple switched to 64-bit Core 2 processors which had some differences. Then in 2009, the Nehalem (Bloomfield, Clarkdale, Westmere, etc.) generation came, quite a big architectural change from Core 2.

Installation media shipped with Macs are always locked to a specific Mac model. But trying to boot them on a newer Mac crashes long before the "this disc ain't for this Mac" message can be shown.

When OS X is updated, it typically gains support for newer hardware as a side effect. That may explain why an installed OS doesn't behave the same as the installation disc.

Anyway, none of that was ever a problem for Apple because Macs are always shipped with the OS preinstalled. So unless you did funny things like booting the OS X disc from your old iMac on your new iMac, you'd never notice.

Re CPUID filtering. Specifically NT 4 has a well known problem in that it crashes if the host CPU reports more than 3 CPUID leaves. Almost every BIOS has (or at least had) an option for that, and the CPUs had the requisite functionality. When Microsoft screws up, Intel has to work around it And BIOSes never say "you need this option cuz NT 4 is buggy"; I have seen help text saying things like "you don't need this option for Windows XP", never mentioning NT 4 at all.

[socratis]

Excellent summary of the problem from a historical point of view, thanks Michaln!