Hervé

So, you've changed mSATA to ZIF adapter and problem remains? We can rule out a faulty adapter then, which leaves you with following likely causes: damaged ribbon cable loose/unreliable ribbon cable connection (ZIF end and/or adapter end) wrong SSD partition scheme or format type faulty or somehow incompatible SSD

what bootloader and Azul FB/ig-platform-id value are you using?

I would suggest you simply concentrate on patching the AGPM kext since that'll be required, with or without AGP device renaming to GFX0 in the DSDT. But it's entirely up to you in the end.

You asked what ig-platform-id value you should use. It depends on the computer and its integrated Intel HD 4x00 graphics. That's why I suggested you try the values in the range detailed by RampageDev as you may actually find you obtain graphics acceleration with a different value than expected. Now, if you already know which values work, why ask? Just try and if it does not give you satisfaction, try the other values until you find the value that does.

Look at this thread; it should answer your questions and point you in the right direction.

You may try ig-platform-id values that belong to the range detailed in RampageDev's Intel HD4400 guide.

Any Merom or Penryn Core2Duo CPU with FSB800 will do. Do not install a Penryn model with FSB1066 as, if it ran at all, it would only do it at FSB800 and therefore at much reduced speed than you'd expect. So Penryn T9300 and T9500 CPUs are Ok but don't opt for the T9600. The Penryn Extreme X9000 should work too, but you'd probably experience quite high T°...

"No such file or directory" is usually self-explanatory... Did you actually verify presence of IOBluetoothHostControllerUSBTransport plug-in or perl target binary file in the IOBluetoothFamily kext on your system? It certainly is there for me in 10.10.5 so it would seem you somehow deleted it.

For those X201/X201s owners who have an erroneous Intel HD Graphics GPU reported in SysProfiler with dev id 0x2d10, try adding statement Name (_UID, 0xFF) to Device (UNCR) of your DSDT: Device (UNCR) { Name (_BBN, 0xFF) Name (_UID, 0xFF) // fix issue of QPI link 0 (pci8086:2d10) being reported as GPU in SysProfiler Name (_ADR, Zero) Name (RID, Zero) Name (_HID, EisaId ("PNP0A03")) Name (_CRS, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x00FF, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0001, // Length ,, ) }) Device (SAD) { Name (_ADR, One) Name (RID, Zero) OperationRegion (SADC, PCI_Config, Zero, 0x0100) Field (SADC, DWordAcc, NoLock, Preserve) { Offset (0x40), PAM0, 8, PAM1, 8, PAM2, 8, PAM3, 8, PAM4, 8, PAM5, 8, PAM6, 8 } } } To reflect true MBP6,1/6,2 DSDT implementation, the brave ones may also consider: renaming Device (SAD) + subsequent references to SAD by IMCH renaming Device (UNCR) + subsequent references to UNCR by CPBG

Updated ok to DB8, though renewed trouble with cache...

The patched AICPUPM prevents KP on CPU power management. For the rest, it is self-explanatory.

Are you using distros?

Ouh... where to start? You could start looking at out EDP->Documentation pages. There are also excellent AIO guides at InsanelyMac that I can recommend. However Hackintoshing is a never-ending redo-it-all-again kind of adventure so you learn something new everyday... One thing strikes me in your above picture: I see OS X version 14F27 (i.e. Yosemite 10.10.5), yet Darwin version is 14.0.0, i.e. kernel of Yosemite 10.10(.0). That's rather odd...

With ML, you'd probably need to rollback AppleACPIPlatform kext to SL 10.6.7/10.6.8's version v1.3.5/v1.3.6 to avoid KP. I would suggest you start with Mavericks on a myHack build from which you can learn and then consider upgrading to Yosemite and El Capitan (in due course).

Please list the target OS X version you're trying to install and the bootloader you're using. Ideally, boot without cache and in verbose mode so that you can tell us the point at which the system appears to hang.

sudo touch -f /System/Library/Extensions sudo kextcache -Boot -U / -> You'll see the list of unsigned kext as reported by the OS. Basically, most add-on kexts and all modified/patched (ex-vanilla) kexts will be reported as "unsigned".

One can't really use the installer app as is (unless from an existing Clover-based OS X installation) but build a USB installer from it.

I doubled checked and all would appear to be Ok, except maybe the cosmetic aspect of the Bus speed. Arrandale i5-520M has a nominal frequency of 2.4GHz at x18 multiplier and lowest frequency of 1.2GHz at x9 multiplier. It has a Turbo boost at x20, i.e. 2.66GHz for 2 cores and x22, i.e. 2.93GHz for 1 core. That makes for a bus speed of 2.4/18 = 1.2/9 = 2.66/20 = 2.93/22 = 133MHz. OS X reporting a bus speed of 533MHZ, it appears the OS is considering CPU bus speed like a good old quad-pumped FSB even though it's not really applicable to an Arrandale CPU. http://ark.intel.com/products/47341/Intel-Core-i5-520M-Processor-3M-Cache-2_40-GHz http://www.cpu-world.com/CPUs/Core_i5/Intel-Core%20i5%20Mobile%20I5-520M%20CP80617004119AE%20(BX80617I5520M).html

I was using v1.3 from the SourceForge repo but I've now updated to v1.3(252) and I can compile the DSDT Ok.

The SD card reader is attached to Device (PXSX) @ _ADR = Zero under Device (RP01) @ _ADR = 0x001C0000, itself directly under Device (PCI0). Look it up in your DSDT. On the basis that it is PCI device 1217/8520, i.e. the well-known 02 Micro SD card reader, it should work OOB once you add the usual compatibility statement to the afore mentioned Device (PXSX) in your DSDT: Device (PXSX) { Name (_ADR, Zero) Method (_DSM, 4, NotSerialized) { Store (Package (0x08) { "AAPL,slot-name", "Built-in", "device_type", Buffer (0x11) { "Media controller" }, "model", Buffer (0x18) { "O2 Micro SD card reader" }, "compatible", Buffer (0x0D) { "pci14e4,16bc" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } ... You can read more details about this here. I've tried to patch the DSDT posted by Jake, but trying to compile it with DSDTEditor or MaciASL in ACPI v4.0 or v5.0 gives me 25 errors even before applying the patch...

I would not want to speak out for people who experimented or use the E6410 Intel HD with partial acceleration but, having tried it myself, I can tell you that any system running without graphics acceleration is just painful. To me, there is really no point in running OS X in limping mode where anything a little graphical like moving or minimising a window is effectively laggy.

Well, one might say that Mavericks would mean you could use myHack and that it would therefore be easier, but I don't think it'll change anything if you have the wrong settings or wrong bootpack. Remember that you will only ever get partial graphics acceleration on that system (Intel HD of the E6410 is not fully supported due to display connector; see here for details), so you may actually prefer not to install OS X on it as It'll never be a particularly great experience.

Post those files so that we have a look.

Guys, please post your system's specs. KP due to AICPUPM (AppelIntelCPUPowerManagement) only affect SandyBridge and IvyBridge CPUs, not the C2D/C2Q or Arrandale CPUs as far as I remember. This being said, if you need Yosemite's patched AICPUPM kexts, copies are available in the Software Matters->Mac OS X forum subsection.

Re: ig-platform-id, are you guys sure the correct syntax in the plist is "0x16260006" or "0x16160002" literally? When I used to specify this parameter manually with Chameleon or Clover, I always had to enter it in reverse order and without "0x". For instance for id 0x0a260006 (i.e. Azul FB #12), I always had to enter ig-platform-id value "0600260a".