Hervé

Did you install the bootpack through myHack->Create Extra menu option?

It's a rather odd solution just for a shutdown, don't you think? The solution is either to find the suitable DSDT patch of an eventual shutdown/reboot/restart kext that addresses that issue (you know something like the EVOreboot kext that existed in SL). I'll try and have a look at the 755's DSDT in the coming days.

Those messages refer to some old Leopard distro, so ??? If you're trying to install Mavericks on a HDD that had that distro in the past, it looks as if you need to wipe it out completely beforehand. Use myHack + the downloaded Mavericks app + OSXL bootpack to make your USB installer. When you boot your installer, go to Utilities->Disk Utility and delete any existing partitions on the drive and create a brand new GUID partition that you'll format OS X extended (journaled). Do not use the MBR patch at the end of the Mavericks installation. You only need the MBR patch if you install on a disk with existing MBR partition table and you lust use a different patch than the defective one provided with myHack v3.3.1.

That error will not cause any system freeze or prevent the OS from booting to completion. It's related to CPU Power Management, meaning CPU management won't be optimum (C states are CPU power modes from max voltage at full power to low-power in sleep mode. You can read about this here), but system will remain fully useable nevertheless. My own D620 GMA950 does display that error just before switching to ML desktop but there's no issue running ML at all... Granted that I have not retested the process with myHack v3.3.1 (and I see no reason to believe it would differ from previous versions) but if you follow the described process rigorously, I can guarantee that you will obtain a fully running ML installation on your D620. Recommended BIOS settings are also provided in this very section, so if you've followed that as well, you should not have any issues at all.

Why do you say "damaged DSDT"? What's makes you think it's damaged? When you do a system build, EDP will indeed re-install some or all of the files that are included in the bootpack (depending on the eventual option changes you may make) but the DSDT file will be exactly the same. I do not believe we have one DSDT file in the bootpack and one different DSDT in the EDP database. That's be easily verified if you had a different behaviour before and after EDP system build, having used the bootpack for installation. BIOS does not do anything with DSDT file in /Extra. If there is a DSDT file, OS X will load it to override the table found in BIOS. Remember that DSDT files are originally extracted from BIOS and patched to correct such and such defect for OS X (typically CMOS reset) or inject some additional info about hardware (typically Video cards).

Run myHack again and select "Create Extra" from the scroll-down menu. Select "my Own" not "Generic" and the point to the downloaded Extra (the bootpack). This will basically use the appropriate files for your models. You must follow the same process at the end of installation when prompted for the /Extra: select my own and point to /Extra of your USB installer.

A behaviour change with recent Chameleon trunk versions (post r2290) highlighted a small defect in the boot plist settings provided in above pack and the kernel handling. I have set boot option UseKernelCache to Yes and refer specifically to the legacy kernel, not to standard/vanilla mach kernel. This leads to the generation of an incorrect kernel cache as, by default, cache is built with vanilla mach_kernel. Leaving such kernel unchanged at root level therefore leads to a kernel cache that is incompatible with legacy kernel and which causes a system reset/boot loop when loaded, unless the cache is built with option -K (or -kernel ...). This was not an issue up to Chameleon r229x because these versions would ignore kernel cache when non-standard mach kernels were used. I've come to realise this changed with post r229x Chameleon trunk versions and kernel cache will be loaded whatever the kernel. To fix this, proceed as follows: at HDD root level, rename vanilla mach_kernel file to something else such as mach_kernel_bak (or remove entirely) at HDD root level, rename legacy kernel Darwin_10.8.0 (or whatever name the legacy kernel bears) to mach_kernel using Chameleon Wizard, uncheck Kernel case in the boot plist or replace the named Darwin kernel by mach_kernel The result is that kernel cache will no longer be built on original/vanilla mach kernel but actually on the now-renamed legacy kernel. Any cache refresh/rebuild made manually, through myHack or any other tool will subsequently be totally safe to load. Oh, I've never mentioned this but boot time from the moment bootloader kicks in to desktop is about 30s and shutdown/restart nearly-instantaneous at about 2-3s. Good old Snow Leopard! It's the most stable Hack I've ever had so far.

@tarfoh, it would be useful to add a little explanation about your patch, i.e. indicate what you added or modified in a plist or what binary modification (binmod) you might have done.

Erm... Use of forum Search facility is highly recommended before posting, especially about matters that have been extensively covered long ago and not just here... http://www.osxlatitude.com/mountain-lion-on-gma950x3100-nvs-110m-systems/ http://www.insanelymac.com/forum/topic/287810-yes-we-can-ml-qeci-on-gma950-gma-x3100-nvidia-7300-etc-systems/

As explained in post #57, this guide should be considered obsolete. Please refer to the documentation and procedure available in EDP menu at the top of your screen.

/ is what is called a convention (it's what... 40+ yrs old?), where elements between are the individual parameters so to speak. Eg: DSDT=/Extra/myDSDT.aml -> = "/Extra", i.e. folder Extra at HDD root (root = /) -> = "myDSDT.aml", self-explanatory I think... Chameleon is our bootloader, a necessity on non-Apple systems since those boot differently than good old traditional BIOS-based PCs. To enter boot flags or boot options, you need to interrupt the Chameleon bootstrap when you see either the delay bar or the countdown; this is done by pressing any key on your keyboard. Re: motherboard, who knows? Probably a Foxconn manufacture in those days... Have a good read through the various 755 threads on the forum. I'd also invite you to read on as much as you can on Hackintoshing and Chameleon and bootloaders in general to improve your knowledge on the matters. There's plenty on that on the Net.

Oh wow, I thought it'd been mentioned enough times on the forum before... When you play with DSDT editing, you NEVER totally replace the current DSDT file until you're happy with the edited table! What you do is save the new file under a specific name and you manually call on that new DSDT through Chameleon option: DSDT=/. This allows you to reboot with your existing working table in case there is a problem with the new one!

In the list provided by EDP, you can opt for the default myHack PS2 pack, that's guaranteed to work. The ANV/Slice works particularly well too, but is often found to be too sensitive and, indeed, one has to make use of a "light" finger to move the mouse as a heavy finger will do scrolling. It takes a little time to get used to.

Download DSDTEditor from Olarila.com. The app comes with a set of patches, one of them being the Gigabyte Shutdown. Try it, I used it on my Vostro200 (a close cousin of the Optiplex 755) and it sorted out the shutdown issue.

What OS X version? Installed using myHack + OSXL bootpack, followed by EDP? Try a permissions repair via Disk utility and/or a myFix (full).

Check that your BIOS parameters are configured according to the recommended settings in the pinned thread of this very section, on the basis that you have a Merom CPU, not a Penryn. Try the performance tuning with modified FakeSMC kext + boot plist P&C States + MB5,1 SMBIOS plist Package_D630i.zip Place plist files in /Extra, FakeSMC.kext in /Extra/Extensions, run myFix (quick) and reboot. Of course, this assumes you also remove all previous instances of FakeSMC/CPUMonitor/PState/VoodooTSCsync kexts from /E/E beforehand as explained here.

Ok, if doing an EDP system build deleted your LAN kext, you need to report it as a bug. We cannot know about it otherwise. Regarding shutdown, if you confirm the behaviour i mentioned above, try the patch I also mentioned above if you feel up to it. Failing that, I'll try and have a look at the DSDT.

Look at the top of your OSXL web page, click on big EDP menu item then select Bootpacks or Compatibility page. You'll see the bootpacks there. Look for your model and target OS X version. If your desired OS X version is not there, grab the latest available bootpack (say Lion for instance).

i7-3537U has built-in HD4000 graphics. That would normally be supported by OS X, but if you can't disable nVidia GPU in BIOS, it could prove difficult to use...

Is the wireless card added to the list of interfaces in the Network Pref Pane? You could try and run a new myFix (quick) to rebuild your kext cache.

It's not a matter of OS X versions, it's a matter of hardware. Apple do not use Intel wireless cards so there are no drivers. Supported brands include Broadcom, Atheros, Realtek or Ralink. Have a look in R&D->Hardware->Wifi section for a non-exhaustive list of supported devices.

I forgot that model was already integrated in EDP; says Ok for SL and Lion. It may well be that the GMA4500 is not supported from ML in a similar fashion as the older GMA 950/X3100 were dropped.

All Latitude keyboards are more or less the same, only the national particularities differ (you're QWERTY, I'm AZERTY). But yes, the lower part of the keyboards is the same for all models. I can only recommend that you use the (DE?) Logitech layout found in the Ukelele dmg as I found it matches our keyboards more or less perfectly. I then use DoubleCommand to make some swapping of Alt-CMD keys and activate PC-like keys such as HOME and END keys. I see no reason why PS2 kexts that worked on my M4300 (now sold) would not work on yours. The underlying hardware is the same and a mere different layout would not prevent the drivers to work.

Long/slow shutdowns & restarts are usually an issue of cache and/or AppleACPIPlatform kext which needs replacement. It's available in the bootpack for your model and it should be installed by EDP which also rebuilds cache at the end of system build, so it's kind of strange... If system restarts when you shutdown, you need to patch your DSDT (the Gigabyte shutdown patch available wih DSDTEditor works fine on Vostro200 and should therefore be Ok on your Optiplex 755). Screen resolution is a matter that depends entirely on your graphics card and the availability of full graphics acceleration. Optiplex 755 on-board graphics is Q35 chipset integrated GMA 3100 (same as Vostro 200) and that is not supported by Mac OS X. You have to use a supported add-on PCIe x16 graphics card and I did not see any such card when you previously posted your lspci output.

Ha, well, I don't know about your particular country layout, all I know is that the French Logitech Layout fits perfectly to the Dell French keyboards. You seem to have opted for a numerical keyboard model, I never do that for a laptop (unless it has a num keypad).