Jump to content

SnowKitty running on VMware Workstation

Zenith432
 Share
154 posts in this topic

Recommended Posts

Donk
Donk
Posted
Posted
I don't think its e.x.p as there is no e.x.p words in the title bar. Though they could have changed that...

 

Yes it works but keeping quiet as we should be under NDA if we have the beta! You will need a new darwin.iso with Netkas fakesmc extension. I will upload it and you can try it out. OK follow my instructions for Leopard in this thread http://www.insanelymac.com/forum/index.php?showtopic=172474 but before installing the package replace with the darwin.iso here http://drop.io/donk29a called vmware-darwin-snowy.zip. There are some things to watch out for with the new betas and I will document them later.

Link to comment
Share on other sites
Donk
Donk
Posted
Posted
Hmm... Looks good, will try when i get a chance. So this will work on the latest version of workstation 6? or is workstation 7 required and if so what version?

 

Thanks Donk!

 

SL is only Workstation 7 beta.

Link to comment
Share on other sites
radam
radam
Posted
Posted
Yes it works but keeping quiet as we should be under NDA if we have the beta! You will need a new darwin.iso with Netkas fakesmc extension. I will upload it and you can try it out. OK follow my instructions for Leopard in this thread http://www.insanelymac.com/forum/index.php?showtopic=172474 but before installing the package replace with the darwin.iso here http://drop.io/donk29a called vmware-darwin-snowy.zip. There are some things to watch out for with the new betas and I will document them later.

 

Hmm... Looks good, will try when i get a chance. So this will work on the latest version of workstation 6? or is workstation 7 required and if so what version?

 

Thanks Donk!

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted

Sorry for the delay on this. One of the kexts was causing the boot process to hang for 5-10 minutes, and I had to spend a lot time figuring out which one (it was AppleProfileFamily.kext). Everything is working now, including update to 10.6.1. I've also got VMMouse, VMsvga2, and audio working. Tomorrow I'll upload a darwin10 kernel + instructions on how to set up SnowLeopard on Workstation 6.5.x.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted

Here's the guide I promised

 

Requirements:

Intel CPU with VT enabled in the BIOS

VMware Workstation 6.5.x

an existing virtual machine with Leopard installed

OS 10.6 retail install DVD

 

This method is based on this guide. It uses an existing installation of Leopard to install SnowLeopard "offline"

on a 2nd hard disk, prepare this disk, and then start the new disk.

 

[Note: the guide I linked to above is on i_H_a_c_k_i_n_t_o_s_h_._c_o_m, not insanelymac.com]

 

Start out by by a adding a new virtual scsi hard drive to an existing virtual machine with Leopard installed. Give it at least 16GB.

Boot your Leopard virtual machine. Run Disk Utility to partition the new drive with GUID partition table, and create an HFS+ partition. I'm going to assume the new volume's name is "Snow" for the rest of the guide, but you can use any name you want.

After creating the new volume, open a Terminal window and set the permissions on the new volume like this

sudo -s
vsdbutil -a /Volumes/Snow
chown -R 0:0 /Volumes/Snow

Now insert the SnowLeopard retail DVD, and start the installer like the guide I linked to above shows (from "/Volumes/Mac OS X Install DVD/System/Installation/Packages/OSInstall.mpkg"). When the installer asks for a destination volume, select the Snow volume. Let the installer run and complete. Don't reboot after installation (it shouldn't ask for reboot, because it's an offline install).

 

Now install netkas's pcefi 10.6 bootloader on the new disk. Its files are can be found in this post (download pcefi10.6vm.tar.gz). There's a README file on how to install it from a Terminal. You should replace rdisk0 with rdiskX where X is the number of the new disk (run the "mount" command to see on which disk /Volumes/Snow is). This is just so you can later boot the new disk. If you have Chameleon 2-RC4 or pcefi 10.x installed on your primary hard drive, you can use them to boot the new disk as well.

 

Now perform the following steps

  • Go to /Volumes/Snow and rename mach_kernel to mach_kernel.vanilla.
  • Go to /Volumes/Snow/System/Library/Extensions, and delete the following kexts
    • AppleProfileFamily.kext (this kext causes boot to last over 5 minutes)
    • AppleUpstreamUserClient.kext (a DRM kext that can cause problems)
    • AppleIntelCPUPowerManagement*.kext
    • AppleLSIFusionMPT.kext (see below) [Edit: not necessary on Workstation 7]

    You may copy these kexts to a backup location before deleting them. This is probably a good idea, especially for AppleLSIFusionMPT.kext.

    [*]go back to your home folder on Leopard, unpack vmsl.tar.gz. Now copy all the files under the folder vmsl to /Volumes/Snow. You should do this in a way to preserve root:wheel permissions, for example

    sudo chown -R 0:0 vmsl
sudo cp -pR vmsl/* /Volumes/Snow

    The vmsl folders contains the replacement kernel(s), all the necessary kexts, and an smbios.plist for injection.

 

Now you're all done. shutdown the virtual machine. Edit your vmx file to make the Snow drive your primary hard drive. If all went as planned, it should boot into the registration process. If you can boot the snow drive from your primary Leopard drive, go ahead and do that.

 

[Edit: If you get a KP in AppleRTC.kext during boot, see post #22 below]

 

Notes:

  • AppleLSIFusionMPT.kext is the lsilogic scsi driver. The version that comes with OS 10.6 uses scsi commands that crash the VMware backend on Workstation 6.5.x (!). So I replaced it with AppleLSIFusionMPT.kext from OS 10.5.8, which is included in vmsl. The older driver works in 32-bit mode. As a result of this, it's not possible to boot the 64-bit kernel (mach_kernel.x86_64), because it doens't have a scsi driver to access the hard disk. Edit: On Workstation 7, AppleLSIFusionMPT.kext from OS 10.6 works fine, and should not be replaced. It can be used to boot the 64-bit kernel.
  • I included the drivers neccessary for ps/2 keyboard & mouse support in vmsl, including VMMouse. If mouse.vusb and keyboard.vusb work for you under Leopard, you can probably use them instead. They don't work for me - I get erratic keyboard and mouse behavior.
  • SnowLeopard versions of the VMsvag2 driver set are also in vmsl. I haven't tested the 64-bit variants, but the 32-bit variants work with the 32-bit kernel. Don't use the VMsvga2 installer for Leopard, because the GA component from Leopard doesn't work on SL.
  • There's no audio driver. You can install EnsoniqAudioPCI with the Leopard installer. It works.
  • VMware Tools - darwin.iso tools from Fusion 2.0.5 can be installed and work ok. If you use a later variation of darwin.iso like the one uploaded by Donk, you'll lose the fit-guest function in VMsvga2, because VMware have changed the interface the driver uses for this function. If you don't care about fit-guest, use any version of darwin.iso you like.
  • Update to 10.6.1 should go ok. It doesn't overwrite the kernel, and only modifies a couple of unused kexts. Check to see that AppleProfileFamily.kext doesn't reappear in /System/Library/Extensions, and remove if it does.

 

This post has a link the most recent version of vmsl.tar.gz.

 

Edit: Attached patches made to XNU-1456.1.26 for the mach_kernel dated Oct 19.

 

Old Download Counts:

pcefi.10.3.tar.gz - 149 downloads

pcefi.10.5vm1.tar.gz - 129 downloads

xnu_patch_Oct_19.txt

Link to comment
Share on other sites
Donk
Donk
Posted
Posted
  • VMware Tools - darwin.iso tools from Fusion 2.0.5 can be installed and work ok. If you use a later variation of darwin.iso like the one uploaded by Donk, you'll lose the fit-guest function in VMsvga2, because VMware have changed the interface the driver uses for this function. If you don't care about fit-guest, use any version of darwin.iso you like.

 

 

The iso I uploaded allows an install from a retail DVD, but this is another interesting way of doing it. BTW the tools on my iso will do auto-fit as internal API capabilities are now built into the VMware monitor. However Zentih432's driver does give additional features. Note also the USB keyboard and mouse support seem much more reliable, and I have stopped reverting to PS2.

Link to comment
Share on other sites
TheGreatDeceiver
TheGreatDeceiver
Posted
Posted
The iso I uploaded allows an install from a retail DVD, but this is another interesting way of doing it. BTW the tools on my iso will do auto-fit as internal API capabilities are now built into the VMware monitor. However Zentih432's driver does give additional features. Note also the USB keyboard and mouse support seem much more reliable, and I have stopped reverting to PS2.

 

holy {censored}, the geniuses did it again ;)

 

I followed Zenith's guide but when I booted into the new SL partition it KP'ed . Then I swapped the darwin iso with Donk's new one and voila, it boots fine now. screen-shot will follow in a minute. Thank you!!

a few odd things as expected, but probably not a big deal to fix later on. E.g. the cpu shows up as 4.3GHz or 30GHz (system profiler).

btw. this is running on an i7 920 with Windows 7 64bit as host.

 

edit1: screenshot

edit2: update to 10.6.1 flawless.

edit3: sound flawless with Zenith's latest kexts

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted
The iso I uploaded allows an install from a retail DVD
Donk, I've analyzed the "snowy" darwin.iso that you've uploaded. VMware have made 2 changes to the daemon-driver interface they use for fit-guest:
  • changed their driver name from "VMwareIOFramebuffer" to "VMwareGfx".
  • Changed the function number from 3 to 0.

Both these changes can be easily patched. I'll prepare a patch of the snowy tools to work with VMsvga2.

 

Thanks a lot for uploading the "snowy" darwin.iso tools.

 

I've also made a patch for vmware-tools-guestd from Fusion 2.0.6 that was released a few days ago. I'll upload the patches together.

 

I'm also working on completing the migration of VMsvga2 to 64-bits. I'll make an installer for it and upload to sourceforge when that's done.

 

Porting the audio driver is a little more difficult. The Leopard version works under SnowLeopard 32-bit kernel. Creating a 64-bit version requires porting AppleAC97Audio to 64-bit, which requires some non-trivial work, so that'll take more time.

 

E.g. the cpu shows up as 4.3GHz or 30GHz (system profiler).
You can fake all these settings by changing them in /Extra/smbios.plist. It's a fake smbios injected by Chameleon/pcefi. If the CPU frequency isn't set in the file, it may be using the real number measured during boot, or just using some random number...

 

PS: Could you run the command "ioreg -p IODeviceTree -rn platform" from a Terminal and post the results? Those are the frequencies that Chameleon measures during boot. They're used for tsc_init by the kernel I built, and I'd like to see if they're correct for multi-core. Thanks.

Link to comment
Share on other sites
TheGreatDeceiver
TheGreatDeceiver
Posted
Posted
You can fake all these settings by changing them in /Extra/smbios.plist. It's a fake smbios injected by Chameleon/pcefi. If the CPU frequency isn't set in the file, it may be using the real number measured during boot, or just using some random number...

 

PS: Could you run the command "ioreg -p IODeviceTree -rn platform" from a Terminal and post the results? Those are the frequencies that Chameleon measures during boot. They're used for tsc_init by the kernel I built, and I'd like to see if they're correct for multi-core. Thanks.

 

I have the vm currently set to 1 cpu with 2 cores. this is the output:

+-o platform  <class IOService, id 0x100000102, !registered, !matched, active, $
{
  "name" = <"platform">
  "FSBFrequency" = <6999770500000000>
}

 

edit1: just realized that I changed this in the config.ini under C:\ProgramData\VMware\VMware Workstation for Leo to work. 

.encoding = "windows-1252"
host.cpukHz = "2660000"
host.noTSC = "TRUE"
ptsc.noTSC = "TRUE"
prefvmx.useRecommendedLockedMemSize = "FALSE"
prefvmx.allVMMemoryLimit = "6000"

 

I guess this will interfere. I will remove the lines and see if that helps.

 

edit2: ok, has no effect. the config.ini is empty and the output and everything else is identical to before.

edit3: just copied the vm over to my notebook with a Core2Duo 2GHz, 4Gb ram. I am running the vm with one cpu with one core. It is recognized as Core 2 Solo (should be correct) with 4.3Ghz under about this and 30GHz under system profiler.

here is the output for your code:

+-o platform  <class IOService, id 0x100000102, !registered, !matched, active, $
{
  "name" = <"platform">
  "FSBFrequency" = <acb1670500000000>
}

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted 
+-o platform  <class IOService, id 0x100000102, !registered, !matched, active, $
{
  "name" = <"platform">
  "FSBFrequency" = <6999770500000000>
}

Did you install the pcefi 10.3 bootloader? It sets 3 values. Here's what it looks like for me.

+-o platform  <class IOService, id 0x100000102, !registered, !matched, active, $
{
  "TSCFrequency" = <dc3ccab200000000>
  "CPUFrequency" = <dc3ccab200000000>
  "name" = <"platform">
  "FSBFrequency" = <00e1f50500000000>
}

The kernel I uploaded needs the "CPUFrequency" value.

 

Also, check /Extra/smbios.plist and see if has settings for "SMexternalclock" and "SMmaximalclock". If it does, post them.

 

Try installing pcefi 10.3 on the Snow drive and booting from it, then check if you have "CPUFrequency" in the table above. If you do and it still gives you 30GHz, I'll have to make changes in my tsc_init() for Nehalem CPUs.

 

Edit: I updated the kernels to better support Nehalem, and uploaded a new vmsl.tar.gz. The kernels still need the bootloader to set "CPUFrequency", so use a recent version of Chameleon/pcefi to boot them.

Link to comment
Share on other sites
TheGreatDeceiver
TheGreatDeceiver
Posted
Posted
Did you install the pcefi 10.3 bootloader? It sets 3 values. Here's what it looks like for me.

+-o platform  <class IOService, id 0x100000102, !registered, !matched, active, $
{
  "TSCFrequency" = <dc3ccab200000000>
  "CPUFrequency" = <dc3ccab200000000>
  "name" = <"platform">
  "FSBFrequency" = <00e1f50500000000>
}

The kernel I uploaded needs the "CPUFrequency" value.

 

Also, check /Extra/smbios.plist and see if has settings for "SMexternalclock" and "SMmaximalclock". If it does, post them.

 

Try installing pcefi 10.3 on the Snow drive and booting from it, then check if you have "CPUFrequency" in the table above. If you do and it still gives you 30GHz, I'll have to make changes in my tsc_init() for Nehalem CPUs.

 

Edit: I updated the kernels to better support Nehalem, and uploaded a new vmsl.tar.gz. The kernels still need the bootloader to set "CPUFrequency", so use a recent version of Chameleon/pcefi to boot them.

 

yeah, I did follow the step by step (did this many times before as well on notebook), but since the system didn't boot without Donk's new darwin.iso, I am afraid it didn't pick the pcefi bootloader. will do this again and report back.

thanks

 

edit1: these are the string values from smbios.plist

	<key>SMexternalclock</key>
<string>333</string>
<key>SMmaximalclock</key>
<string>3000</string>

 

doesn't matter if I change that last string, it always reports 30GHz in system profiler.

also, this is what kextutility reports:

CPU Signature: Ox106A4 (67236)
CPU TYPE:	  Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
Core:		  30000(30000) MHz x 1200.0(1200.0) Bus: 25 MHz FSB: 100 MHz
Cache L2:	  0 Mb
RAM:		   4096 Mb

 

edit2: ok, just to make sure I am installing the bootloader, I installed the latest chameleon 2 RC2 r640 package and replaced the boot with netkas' lastest bootloader (same thing I did for my notebook). I get the same results - nothing changed. Unless there is something in the darwin.iso that collides with the bootloader I am at loss. But just as you said, these are only cosmetic problems and no big deal.

thanks for your help

Link to comment
Share on other sites
Donk
Donk
Posted
Posted
Unless there is something in the darwin.iso that collides with the bootloader I am at loss. But just as you said, these are only cosmetic problems and no big deal.

thanks for your help

 

The boot loader on the darwin.iso loads the kernel, and so will not chain to anything on the hard drive.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted
yeah, I did follow the step by step (did this many times before as well on notebook), but since the system didn't boot without Donk's new darwin.iso, I am afraid it didn't pick the pcefi bootloader.
The reason you got a KP with the mach_kernel in the original vmsl.tar.gz is because that kernel didn't support Nehalem CPUs, only Core 2. I've uploaded a new vmsl.tar.gz with a mach_kernel that should boot on Nehalem. I guess that darwin.iso boots a completely different mach_kernel, because otherwise I don't see how you got my first kernel working at all.

 

The mach_kernel I built expects the bootloader to set "CPUFrequency" in the EFI tree. dfe's original bootloader didn't do this. The kernel needs a recent-enough version of Chameleon or pcefi to boot - they measure and set the CPU frequency.

 

The mach_kernel I uploaded is a Darwin 10.0.0 variant. I'm not sure which version of Darwin is on darwin.iso.

uname -a
Darwin Snow.local 10.0.0 Darwin Kernel Version 10.0.0: Mon Oct  5 17:49:40 UTC 2009; zenith432:xnu-1456.1.26/BUILD/obj/RELEASE_I386 i386

Link to comment
Share on other sites
Donk
Donk
Posted
Posted
The reason you got a KP with the mach_kernel in the original vmsl.tar.gz is because that kernel didn't support Nehalem CPUs, only Core 2. I've uploaded a new vmsl.tar.gz with a mach_kernel that should boot on Nehalem. I guess that darwin.iso boots a completely different mach_kernel, because otherwise I don't see how you got my first kernel working at all.

 

The mach_kernel I built expects the bootloader to set "CPUFrequency" in the EFI tree. dfe's original bootloader didn't do this. The kernel needs a recent-enough version of Chameleon or pcefi to boot - they measure and set the CPU frequency.

 

The mach_kernel I uploaded is a Darwin 10.0.0 variant. I'm not sure which version of Darwin is on darwin.iso.

uname -a
Darwin Snow.local 10.0.0 Darwin Kernel Version 10.0.0: Mon Oct  5 17:49:40 UTC 2009; zenith432:xnu-1456.1.26/BUILD/obj/RELEASE_I386 i386

 

I did have a darwin.iso it just chains to first hard drive, if useful for testing. Also note that Workstation 7 also has an EFI BIOS which Fusion 3.0 uses, but I cannot get running on Workstation 7 yet.

Link to comment
Share on other sites
TheGreatDeceiver
TheGreatDeceiver
Posted
Posted
The reason you got a KP with the mach_kernel in the original vmsl.tar.gz is because that kernel didn't support Nehalem CPUs, only Core 2. I've uploaded a new vmsl.tar.gz with a mach_kernel that should boot on Nehalem. I guess that darwin.iso boots a completely different mach_kernel, because otherwise I don't see how you got my first kernel working at all.

 

The mach_kernel I built expects the bootloader to set "CPUFrequency" in the EFI tree. dfe's original bootloader didn't do this. The kernel needs a recent-enough version of Chameleon or pcefi to boot - they measure and set the CPU frequency.

 

The mach_kernel I uploaded is a Darwin 10.0.0 variant. I'm not sure which version of Darwin is on darwin.iso.

uname -a
Darwin Snow.local 10.0.0 Darwin Kernel Version 10.0.0: Mon Oct  5 17:49:40 UTC 2009; zenith432:xnu-1456.1.26/BUILD/obj/RELEASE_I386 i386

I got a build date of Oct 2 with your name in it. For some reason I must have been able to boot with your older kernel.

I re-installed chameleon again and latest boot file. I installed your updated kernel (confirmed with uname -a). The IODeviceTree output is still identical to above posts. But now the system reports 4.23 GHz in System Profiler with a Bus speed of 367MHz. At least now the CPU speed is the same as in About Mac (4.3GHz) - getting closer (true speed should read 2.67GHz for i7 920, although even under windows it often goes passed that, e.g. 2.9GHz). I see that the clock speeds in smbios.plist of your recent upload are blank.

any more guidance?

thank you!

Link to comment
Share on other sites
Donk
Donk
Posted
Posted
See attached image...

 

Clarification: The host is Workstation 6.5.3 with guestOS "freebsd-64" and same vmx settings I use for Leopard (no vusb, no ide).

 

Excellent work! I missed that this was Workstation 6.5. There is an ongoing issue with Nehalem processors, which you have fixed in your kernel. Can you share your pacthes as I think a good approach for Leopard and Snow Leopard using the built-in VMware support for Darwin XNU kernels could also benefit from it. I have looked at the source from 2 or 3 other kernels, but pinning down what makes Nehalem work is confusing especially when some claim support but it doesn't work.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted
any more guidance?
You're still using darwin.iso to boot. You should try booting directly from the Snow hard disk. Edit your vmx file, comment out the virtual DVD drive that points to darwin.iso, and make sure the Snow vmdk is the first hard disk (scsi0:0). Then try booting it. You say you've installed Chameleon on it, so it should boot. If you don't get a KP, you're all set, and the CPU frequency reported should be close to the right number (within 0.1 GHz). If you still get a KP, see below...

 

I found there's another potential source of KP in my setup other than tsc_init(). It's AppleRTC.kext - it sometimes crashes after finding a malformed CMOS ram. I need time to analyze this. In the meantime you can work-around it as follows:

Start the Snow virtual machine, and press ESC in the first few seconds and then enter BIOS setup in the guest (you need quick fingers for this ;) ).

In the Main Menu, disable the floppy drive.

Go to Advanced->I/O Device Configuration and then disable the Floppy disk controller.

Go to the Exit menu, click "Exit Saving Changes" and reboot.

 

The system should boot now without KP in AppleRTC. Disabling the floppy is just one change that eliminates the problem. It looks as if making any change in the CMOS ram and saving it will fix it.

 

Can you share your pacthes
Attached below are the patches I made to xnu-1456.1.26 for the mach_kernel in vmsl.tar.gz dated Oct 5.

Edit: Attachment removed, see post #10.

Link to comment
Share on other sites
TheGreatDeceiver
TheGreatDeceiver
Posted
Posted
You're still using darwin.iso to boot. You should try booting directly from the Snow hard disk. Edit your vmx file, comment out the virtual DVD drive that points to darwin.iso, and make sure the Snow vmdk is the first hard disk (scsi0:0). Then try booting it. You say you've installed Chameleon on it, so it should boot. If you don't get a KP, you're all set, and the CPU frequency reported should be close to the right number (within 0.1 GHz). If you still get a KP, see below...

 

I found there's another potential source of KP in my setup other than tsc_init(). It's AppleRTC.kext - it sometimes crashes after finding a malformed CMOS ram. I need time to analyze this. In the meantime you can work-around it as follows:

Start the Snow virtual machine, and press ESC in the first few seconds and then enter BIOS setup in the guest (you need quick fingers for this :) ).

In the Main Menu, disable the floppy drive.

Go to Advanced->I/O Device Configuration and then disable the Floppy disk controller.

Go to the Exit menu, click "Exit Saving Changes" and reboot.

 

The system should boot now without KP in AppleRTC. Disabling the floppy is just one change that eliminates the problem. It looks as if making any change in the CMOS ram and saving it will fix it.

 

Attached below are the patches I made to xnu-1456.1.26 for the mach_kernel in vmsl.tar.gz dated Oct 5.

 

Darn, forgot to change it to guestOS "freebsd-64" in the vmx. It was still looking for darwin-64 which I had still in there. It is working now. Frequency is detected correctly. I had some problems with the mouse not being picked up by the guestOS. I deleted all entries from the vmx file related to usb+mouse and got it to work after a while. I have it attached. I'd appreciate if you can tell me if there is anything else in there that may be a problem. Thank you. No more darwin.iso - very nice. Now the only thing left I need to fix is the guest autofit.

 

this is the output now:

+-o platform  <class IOService, id 0x100000102, !registered, !matched, active, $
{
  "TSCFrequency" = <04b4859e00000000>
  "CPUFrequency" = <04b4859e00000000>
  "name" = <"platform">
  "FSBFrequency" = <00e1f50500000000>
}

btw: "make sure Snow vmdk is the first hard disk (scsi0:0)" it didn't matter whether I had it on scsi0:0, 1 or 2, it worked either way and the partition always stayed disk0s2 in SL irrespective of this.

 

edit 1: installed vmware tools from fusion 2.05. two things: I am getting "no permission" to shared folders and guest autofit does not work either. Went back to darwin-snowy by Donk and get at least shared folders back.

Snow_Leopard1.zip

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