digital_dreamer

I had the same problem. The ASL data store is corrupted. Use Terminal to stop the logging and delete the file: sudo launchctl stop com.apple.syslogd sudo rm /var/log/asl.db sudo launchctl start com.apple.syslogd kind regards, MAJ

toleda, Thank you for providing this script for Clover audio. Got it to work for my ALC885/ALC889a sound on my GA-EX58-UD5 board. I had to make a change in your v100 script to get it to complete without errors. It would abort when installing the zml files. The following is the last few lines of the script's output: Install System/Library/Extensions/AppleHDA.kext/ALC885 zml files rm: /System/Library/Extensions/AppleHDA.kext/Contents/Resources/*.zml.zlib: No such file or directory not supported with this script No system files were changed To save a Copy to this Terminal session: Terminal/Shell/Export Text As ... Looking at the script, it appeared the 885 codec choice would fall through the case switch and exit, so I added (in red) the following, starting at line 825: I also changed the codec reporting variable. Not really sure this is all proper, but it worked for me. sudo install -m 644 -o root -g wheel /tmp/$gCodec/Platforms.xml.zlib $gHDAContentsDirectory/Resources/Platforms.zml.zlib sudo install -m 644 -o root -g wheel /tmp/$gCodec/layout1.xml.zlib $gHDAContentsDirectory/Resources/layout1.zml.zlib case $gCodec in # Added: 885);; 887|888|889|892|898 ) sudo install -m 644 -o root -g wheel /tmp/$gCodec/layout2.xml.zlib $gHDAContentsDirectory/Resources/layout2.zml.zlib sudo install -m 644 -o root -g wheel /tmp/$gCodec/layout3.xml.zlib $gHDAContentsDirectory/Resources/layout3.zml.zlib ;; 1150 ) sudo install -m 644 -o root -g wheel /tmp/$gCodec/layout2.xml.zlib $gHDAContentsDirectory/Resources/layout2.zml.zlib ;; * ) echo "$gCodec not supported with this script" echo "No system files were changed" echo "To save a Copy to this Terminal session: Terminal/Shell/Export Text As ..." exit 1 ;; esac Thanks for all the work you do! kind regards, MAJ EDIT: Bummer. Don't know how to add red color to text in code tags.

This is very interesting. But, I wonder if it just expects a capital "F" in "Fusion", because this is my output, drive created in Mavericks, but Terminal output from Yosemite: diskutil cs info D2C8C77B-CDDF-46F5-98E1-629405D40026 Core Storage Properties: Role: Logical Volume Group (LVG) UUID: D2C8C77B-CDDF-46F5-98E1-629405D40026 LVG Name: Fusion Drive LVG Version: 1 LVG Size: 1249576288256 B LVG Free Space: 0 B LVG Status: Online LVG Sparse: Yes Fusion Drive: Yes Is this output from Yosemite or Mavericks? I'm inclined to think "diskutil cs" has been updated in Yosemite, as the man page shows June 2014. 'diskutil info diskX' should reveal Fusion drive status, as well: (Last few lines): This disk is a Core Storage Logical Volume (LV). Core Storage Information: LV UUID: FC33E586-03D7-480A-B471-0E9B761B342C LVF UUID: 50389DB3-53A2-4C16-AF3A-38983B199A6C LVG UUID: D2C8C77B-CDDF-46F5-98E1-629405D40026 Fusion Drive: Yes Encrypted: No MAJ

I'm curious about where you got your DSDT file. MAJ

Ignore the sound assertion. It's not a problem. The issue is not loading FakeSMC.kext. Your log will show "Waiting for DSMOS...", followed by "DSMOS has arrived:" after a few lines. If "DSMOS has arrived" never occurs, the FakeSMC.kext is not doing its job - not loaded. MAJ EDIT: toleda is more likely correct.

bernito, A few things: 1. Make sure the bootloader on the drive that you are booting from has at least r2401. If it's older, it will not be able to correctly determine the kernel name and path based on the OS version. If you are booting from a drive with the older bootloader, it will always assume a Mavericks or earlier setup, looking for "mach_kernel" at the volume's root directory. 2. Make sure any of your boot plists that the updated bootloader is using does not have the "Kernel" key and string. It’ll look like this: <key>Kernel</key> <string>mach_kernel</string>Remove the entire key and string. This will let the bootloader find the kernel on its own, depending on the OS version. With it in place, it will always assume the "mach_kernel" name and root directory path, and that can only boot Mavericks or earlier. 3. I'm always a bit wary of using the very latest Chameleon commits and compiling them, as they have not had much testing done, compared to the public releases. I will only use it on a test environment. EDIT: 4. You can't roll back to an earlier version at the bootloader screen. But, the script allows you to revert to an earlier version you have used or installed. Just key in the bootloader number and use "r" like this: 2 r This will pull up the last 4 versions you have used and allow you to revert. Plus, if you are using the source code, you can choose any revision from the change log and revert to that revision. It's nice they finally fixed the compiling errors for the Chameleon bootloader! Yay. MAJ

UPDATE: 10/19/14 - version 8.5.3 Boot disk creator: Reworked script so that it will find the required kernel if it's still buried inside the Kernels directory. This will solve the issues where the Boot disk creator aborts due to not finding a kernel to install. This process goes through several steps: Check if an alternative kernel is being installed (if kernel in Kernels folder is placed directly outside its parent folder). Failing that, it is assumed no alternative kernel is desired and the vanilla kernel is to be installed. Therefore, check for a kernel directly inside the OS installer disk images. (This was where the kernels used to be located.) If not found, we'll assume it's located in BaseSystemBinaries.pkg (as is currently the case) and wait until it is unpacked. If a kernel is not found, because packages cannot be uncompressed (as is, also, currently the case), then go back and look for a buried kernel in the script's Kernels directory, based on the OS version number (e.g. 10.10_Yosemite) If none is found directly in this directory, check if there are child directories that match the OS minor version number (e.g. 10.1, 10.2, etc.) and use that kernel. The process is aborted if no kernel is found. I expect that at some future time we will be able to uncompress the payloads in the packages and extract the kernel, as we used to do, and none of the above will be necessary. In the meantime, we will have to have a separate kernel for each OS release (assuming kernel changes), each of which adding about 11MB to the overall size. Additionally, I can't expect each user to place the required kernel where needed for the installation. This is why the script is being implemented this way - to ensure the correct kernel is being used for the desired OS release. I'm including a modified and fixed version of Cruser's DSDT file for the GA-EX58-UD5 board and Core i7 920 CPU you can use. This DSDT file had native power management stripped in and was stripped down to the bare minimum by Cruser. This file should work better than the one I just released previously. It's located in the "Plists_and_other_files" folder, named "NPM_EX58-UD5.dsl," and will be visible within the DSDT Patcher as option #2. Do not use this if you do not have the same board and CPU! Please read all Known issues on first page before running the script or if you are encountering booting issues. Download will be ready about 9 a.m. Central Time. If you had downloaded the script at an earlier period this morning, please try again, as there was a bug found in that copy. itdoesnotwork, Chameleon development has really slowed down. There's only a trickle here and there, and only for major fixes. It's clear that everyone, okay most everyone, including the devs, are moving to Clover. Clover is a modern boot manager. It offers on-the-fly patching of files/kexts. This means many kexts don't need to be reinstalled after a software update. It does take quite a bit of tweaking to get running correctly, but, once there, you can just leave it. I'll let @ROBASEFR offer more info on this, due to his real-world experience. best of wishes, MAJ

If it's "Still waiting for root device", then the bootloader has not be properly installed for that partition/drive. MAJ

You can create the boot disk from any system or OS version. You just won't be able to run the script inside the OS installer environment. You'll need to boot into your other install to run the script. Hope that's clear. SCRIPT UPDATE: UPDATE: 10/17/14 - version 8.5.2 Tested with public release of OS X Yosemite. Native power management does not work via Chameleon's bootloader flags. Additionally, the final release of Yosemite will KP shortly after boot if the AppleIntelCPUPowerManagement.kext is loaded, necessitating that it be disabled. So, the NullCPUPowerManagement.kext is now part of the kext install process. Given that native power management has been moved into the kernel itself, the AppleIntelCPUPowerManagement.kext is not needed, anyway. Power management appears to work fine in Yosemite with the appropriate DSDT mods on this GA-EX58-UD5 board with the Core i7 920 CPU. See d00d's GA-EX58 and GA-X58A DSDT native power management modifications for info on this modification. I have a modified DSDT file with native power management stripped in for the GA-EX58-UD5 board and Core i7 920 CPU you can use. It's located in the "Plists_and_other_files" folder, named "NPM_EX58-UD5.dsl," and will be visible within the DSDT Patcher as option #2. Do not use this if you do not have the same board and CPU! Updated audio kexts: 13 AppleHDA.kexts (v266.5) for Yosemite (ALC662, ALC88x, ALC89x, ADI1988B-ADI2000B, and VT2020-2021), plus VoodooHDA.kext v287. See updated Known issues below if you are encountering booting issues.

Lucky-Eagle, This is a combination of Yosemite and bootloader changes. Of all the major updates I've worked with since Snow Leopard, this one is the most frustrating. I gave up a few times, only to return a couple weeks later to try again. It took me and many others a long time to figure out what's going on and what to do. Your KP looks like the infamous "Can't perform kext scan: no kext summary" KP. Here are my comments, posted on the front page: Known issues: Kernel panics on boot: I've been finding that in the latest Chameleon bootloader releases, it's no longer possible to boot with a mkext cache file in /Extra, unless you use the "ignore caches" flag (-f). An alternative is to use the "Combo Boot" option, where a cache made up of both the /System kexts and /Extra kexts is placed into /Extra. The best option, however, is to install all kexts into /System (S/L/E) and use the kernel cache (UseKernelCache=Yes). This is the Apple-approved method and will provide the fastest boot times, as all kexts are processed in advance and pre-linked to the kernel. If you install all kexts into /System, the script will automatically set this flag for you. Because of the enhanced security model of OS X Yosemite, modified kexts that are not signed will not be loaded (invalid or missing code signatures). To get around this issue and load the unsigned kexts, you need to add the kext-dev-mode=1 kernel flag. This is the Developer Preview mode that allows unsigned kexts to be loaded for testing. Also, notice this question with a similar response: Booting from the bootloader results in a immediate kernel panic, with "Can't perform kext scan: no kext summary" message. This can happen if the bootloader is unable to, or refuses to, load the kext cache and basically gives up going further. Try booting with the "-f" option (ignore caches and reload kexts). On a RAID or Fusion setup, try using the "Combo Boot" option, if you have kexts in /Extra. This will build a cache made up of both the /System kexts and /Extra kexts and place it into /Extra. Best results come from installing all kexts into /System (S/L/E) and using the kernel cache (UseKernelCache=Yes). This is the Apple-approved method and will provide the fastest boot times, as all kexts are processed in advance and pre-linked to the kernel. If you install all kexts into /System, the script will automatically set this flag for you. Hope this all hopes. MAJ Edit: Added the kext-dev-mode=1 flag note.

Sounds like a Monodevelop bug, just as you mentioned. Did you disable the Version Control plugins (or just "Git support"), as mentioned on the stackoverflow forum? This type of lag doesn't appear to be a symptom of a badly configured hackintosh. I don't see how a bad configuration would cause that type of lag. I, personally, don't think you have a issue with your system. Just a software (or plugin) bug with Monodevelop. best of wishes, MAJ

If you have a working system, I don't see any benefit from using the script. Can you elaborate on what you mean by lag on your hdd and apps? ryansimms, Can you post the contents of your SystemVersion.plist, located on your Hacky SSD? Path: /System/Library/CoreServices/SystemVersion.plist Should look like the following from mine: <dict> <key>ProductBuildVersion</key> <string>13F34</string> <key>ProductCopyright</key> <string>1983-2014 Apple Inc.</string> <key>ProductName</key> <string>Mac OS X</string> <key>ProductUserVisibleVersion</key> <string>10.9.5</string> <key>ProductVersion</key> <string>10.9.5</string> </dict> P.S. What is on disk4??? You have another disk, which appears to be a logical AppleRAID or Fusion drive, but there is no name or drive type??? Is your SSD the only drive that your OS is on, or did you attempt to create a Fusion drive at some point? regards, MAJ

How long did you wait? It can take a long time to verify a new disk image. If you try to mount it manually from the Finder, it'll do the same thing, but you get the option to cancel the verify. Try the manual approach: Select Yosemite Installer app and "Show Package Contents" Dig down through "SharedSupport" and mount the "InstallESD.dmg" disk image. See if the script can continue from there and mount the "BaseSystem.dmg" (The "BaseSystem.dmg" image is invisible, but can be opened manually via the Terminal. Let me know if you need more assistance.) regards, MAJ

Yes, it's loaded! You're kidding me! Do you have the OS installed on the partition you are working with? Would you post your install log for me? Here's my shot with the 10.9.5 volume selected as target: UPDATE: 10/12/14 - version 8.5.1 Kext/kernel installer and Boot cache updater: Removed the "System cache boot" option, as the current bootloader doesn't appear to want to load this cache (without the "ignore caches" option). Also, reworked script to prevent it from creating a Extensions.mkext in /System/Library/Caches... when a "Combo Boot" or "Extra Boot" option is selected. If one is present, it will be deleted by script, also. This is done now, because the current bootloader appears to have trouble booting with these basically duplicate caches, leading to a immediate kernel panic, with the "Can't perform kext scan: no kext summary" message. Plist Editor: Fixed a bug where renamed Apple RAID volumes would not appear and their plists were inaccessible. This was due to the fact that the original RAID name stays intact in the diskutil AppleRAID list command and the script was using that as the basis for RAID names. Made minor changes to user interface in Kext/kernel installer and Update boot caches function, as well as corrected misspellings in Bootloader installer. Updated FakeSMC.kext to 6.11.1328. Updated RealtekRTL8111.kext Mieze to v1.2.3. See Known issues in the OP if you are encountering booting issues.

If anyone is having Can't perform kext scan: no kext summary KPs at boot, just install ALL kexts into /System (S/L/E) and the script will enable the UseKernelCache flag and boot via kernel cache. kind regards, MAJ