Hervé

As I said, the pack is available in EDP in the System Build options. Look in the kext tab.

Don't bother; don't waste time or money on this obsolete piece of hardware. Get a SSD instead.

You have to re-run myHack and select "Install Extra" for the bootpack.

You will need to have available disk space for that and also to use an MBR patch (not the MBR patch from myHack). Ideally, the target partition should be created in Windows and formatted FAT so that you just have to reformat it Mac OS X Extended (journaled) from Disk Utility once you've booted your installer.

Could be that the pack contains the wrong kext. We found out there were 2 different kexts for that Broadcom LAN card, one was universal binary code and caused issues, the other one was full Intel code and worked Ok. There's at least a couple of posts on that matter either in D6xx or D4xx sections with a copy of the Intel kext.

Which Intel graphics? What exact CPU do you have? MBP8,2 profile may not be suitable at all (SandyBridge i7-2xxxQM & Radeon HD 6490M/6750M§6770M). Did Allen_N tell you if his pack was for your particular E6320 (?) model (if not, the DSDT may not suit…)?

On the D630 X3100, use patched STAC9205 audio pack. On the D630 nVidia, use VoodooHDA audio pack. Both packs are available from EDP menu when you do your System Build. We have different DSDTs according to the model and VoodooHDA proves not to work on X3100 models.

At this stage, you're having trouble with graphics initialization. What graphics do you have? Try and boot with option GraphicsEnabler=No. You'll also have to sort out those SMC errors. Which version of FakeSMC do you have? What SMC keys does it have? which SMBIOS profile do you use?

No such lock from factory build I'm afraid; this is done by companies or individuals who want to secure their systems...

It means hardware may need replacement for feature to work. Typically, this applies to wireless (eg: incompatible Intel cards -> replace with supported model) or graphics cards in desktop computers (eg: incompatible built-in graphics such as GMA 3100 -> use supported PCIe x16 card).

Sorry, can't help you with Clover.

Assuming you use Chameleon bootloader, run Chameleon Wizard and install/apply Chameleon module EFINVRam.dylib. This normally fixes the iMessage issue (but not always...).

One only extracts a DSDT in order to patch it; if not, there's no need to extract it, OS X is perfectly capable to load it from BIOS.

No, that should be Ok, but you could have done that by re-running myHack and opt for Create Extra in the menu. The references to distro you listed above certainly do not come from myHack!

It will if the process described in the guide is followed to the letter.

It's not something many people use I reckon… Out of interest, how are you trying to use it, I mean for what specific purpose?

Ok, so now that we know the basis are Ok after you make good use of the boot pack, it's "just" a matter of helping you with the GMA4500MHD graphics because, as you've sussed out, your graphics card is not natively supported. Can you please post the output of Terminal command lspci -nn? We have some kexts for the GMA 4500MHD, depending on exact version of hardware...

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.