I’d like to talk about iMessage, El Capitan and Yosemite.
I’ve been using Mac OS X on a Maximus V Gene motherboard with an i7-3770K processor for quite some time now. With the introduction of Yosemite I needed to figure out a way to make iMessage work as it included changes around the same time with validation of MLB and ROM values that were reported by the system and the NVRAM.
Here’s my basic setup: Chameleon boot loader (previously regular flavor, now ENOCH), drop the Chameleon.plist, insert SMBIOS.plist, FakeSMC, IntelE1000-Ethernet.kext and my systems is working. To enable iMessage I had to install the FileNVRAM.kext (1.1.4 package) and FileNVRAM.dylib (1.1.4 package) file onto the USB stick containing the chameleon boot loader. With this setup, I was able to boot Yosemite fine and get a working NVRAM. However, keep in mind that you have to create the /Extra folder on the hard drive of your OS X install and make it writable by anyone. Then the FileNVRAM.kext is able to create the nvram.1d34-12d4d1234-1d341234.plist ( 😉 ) which contains the data you have written. Whenever I needed to boot the system with -v -f or when doing software updates, I had to use a second Chameleon stick that did not include the FileNVRAM.kext and dylib files. (If booting with -v -f and FileNVRAM installed, the system would crash on caching the kexts) I would then boot the system, run kext utility or similar permissions-checking and kext-caching applications and reboot with the FileNVRAM-USB stick. This was my full working arrangement. Tedious, but worked excellent. Never had a problem with iMessage, FaceTime, iPhone Calls, AppStore, iTunes or iCloud. So far so good, but it was time to move to El Capitan.
In El Capitan I encountered the problem that kexts cannot be passed through the Chameleon boot loader but have to be installed directly into /S/L/E and have to be cached by a running system (usually just boot the same SSD from a real Mac). This forced me into a predicament with the FileNVRAM.kext which had to be loaded through Chameleon as it wouldn’t otherwise boot. So by trial and error I examined a problem with the FileNVRAM.kext on 10.11.3 which resulted in it not being loaded, no matter where you put it. Reason why? The Info.plist of the FileNVRAM.kext has the following code written in it:
<key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOStorageFamily</key> <string>1.0b1</string> <key>com.apple.kpi.bsd</key> <string>8.0b1</string> <key>com.apple.kpi.iokit</key> <string>7.0</string> <key>com.apple.kpi.libkern</key> <string>8.0d0</string> <key>com.apple.kpi.mach</key> <string>8.0d0</string> <key>com.apple.kpi.unsupported</key> <string>8.0b1</string> </dict>
Not sure if you spotted the error yourself, but the IOStorageFamily version is too low for El Capitan. This OS X ships with 2.1 instead and the kext simply refuses to load. If you change this value in the Info.plist file, the kext is loadable. This is more of a dirty patch than a correct solution. So what happens next: I got my El Capitan working again with the same approach as above, but no FileNVRAM module or kext anywhere, neither Chameleon, nor OS X. When the system is booted up I would install the FileNVRAM.kext into /S/L/E, onto the /E/E on the Chameleon stick and in the /E/E folder on the hard drive. Same with the module, /E/E on both hard drive and chameleon stick. Now I would have to run kext utility again to precache the FileNVRAM.kext into the system and reboot. Sometimes it wouldn’t boot up, sometimes it would “break” the system (fixable by dropping FileNVRAM from all instances and touching /S/L/E and running kextcache -u / from single-user mode or external system) – but most of the times it just works. NVRAM is capable of saving and creating the /Extra/nvram.xxxxxx.plist file and returning the required MLB/ROM values after being saved – even after reboot. Thus I have managed to get FileNVRAM.kext working by this trick in El Capitan.
My hope is that there is someone capable of updating the FileNVRAM.kext file for El Capitan and its latest Xcode. The kext itself is still working, but the dependencies are off and thus causing the issues.