Jump to content

[GUIDE] Scripted Yosemite/Mavericks Install on Gigabyte Mobos

digital_dreamer

By digital_dreamer,
in Tutorials (The Genius Bar)

 Share
4,696 posts in this topic

Recommended Posts

  • Popular Post
digital_dreamer
digital_dreamer
Posted
  • Popular Post
Posted

USING THE HACKINSTALLER SCRIPT
TO INSTALL MOUNTAIN LION/MAVERICKS/YOSEMITE
ON INTEL-BASED MOTHERBOARDS:


NOTE: This thread will not be for posting common installation and booting issues for which you can find solutions in a variety of places on this forum. (See the FAQs in this post for common issues.) This thread exists for unique issues regarding a specific board or issues regarding script bugs. If you are convinced that the problem you are having is in regards to script behavior and can replicate or duplicate the issue, it is in my best interests to solve this issue for you.

This is a full vanilla install with a handful of modified kexts that are added to a special folder (/Extra/_Kexts_For_Extra, either on your main boot partition or the EFI partition) for full functionality. This setup supports full Apple Software Updates without issues. An added bonus is a fully-featured script that provides a comprehensive set of options and features, such as the following:

INSTALL MODES/SETUPS:
Full Apple RAID and Fusion drive support! Install kexts and custom kernels on any Apple RAID/Fusion drive system.
Automatically detect both Boot cache and /Extra/Extensions modes and switch between both modes during drive selection
Supports both bootloader install methods: Standard Extra install (GUID or MBR) or EFI boot install (GUID only)
BOOTLOADERS:
Choose from various bootloaders, including Chameleon v2.2 RC5 and Chimera, with updates for precompiled builds or source code.
Compile source code automatically, revert to any revision, view change logs, and change config switches.
Includes installation option for special Stage-0 booter (boot0hfs or boot0md) for Windows installations on the same volume
Detects installation of multi-stage Chameleon bootloaders (boot0, boot0hfs, boot0md, boot1h, boot1f32, and boot file)
Select various available bootloader themes (extra download) Choose from a selection of 146 boot pictures (extra download)
Install, uninstall, or ignore available Chameleon modules
OSx86 INSTALLATION:
Auto OS X DVD installer Install kexts and/or kernels Update boot caches, including kernelcache
Easily change kext install destination (/Extra or /System) in a couple keystrokes Drag 'n Drop kext install fully supported
Automatically patch AppleHDA.kext with layoutXXX.xml and Platforms.xml files Allow the installation of VoodooHDA.kext into /Extra
Easily modify kexts' "OSBundleRequired" string (mkext filter) and "CFBundleVersion" string (version number)
Fully automatic UUID handling when using a UUID injector kext Automatic video ROM installations
Includes CPU ID patcher for AMD CPUs when installing a kernel
PLIST EDITING:
Powerful plist editor that allows you to edit any boot.plist or smbios.plist in common locations
Plist editor allows you to select from a list of common keys, create a custom key, or modify kernel flags
Full EFI strings support: Create strings for Graphics devices on over 160 graphics cards
Automatic parsing and naming of each device in string for easy verification
Import/append/remove individual devices in string, with automatic checks for valid device trees and corrupted EFI strings
BOOT DISK CREATION:
Boot Drive (DVD, USB, SATA, Flash) install methods with EFI strings, DSDT, and custom kernel support
Create boot disks from a DVD, ISO, or ESD App Store download
Perform entire install within the OS X install environment - no need for an extra reboot or another install drive
Automatic modification of installer's distribution script in the OSInstall.mpkg
DSDT PATCHING:
Flexible DSDT fix/hack selector and patcher with fixes that can be navigated and enabled/disabled via arrow keys
Several DSDT fixes available: CMOS reset, CPU Alias, Sleep fix, Power button hack, Length too large and many more
OTHER TOOLS/UTILITIES:
Modify "About This Mac" graphics Time Machine Restore
Create/defuse Fusion drives Enable/disable TRIM support
Make user library visible/invisible Make System files visible/invisible
Check native power management status on running system


RETIREMENT:
I will be retiring from this project shortly. It has consumed 4 years of my time and I need to move on with other things. The script has served its purpose with regards the Chameleon bootloader and there isn't any need to maintain a script that supports a dead-end development project.
The Clover boot manager is where the future is and development continues to move swiftly there. Additionally, all the tools are already in place:If I find a need for some helpful script to speed up the Clover installation and setup, I may consider making a bare-bones script to help in that regard.
Best of wishes!

SCRIPT UPDATE:
UPDATE: 10/20/14 - version 8.5.4
  • Chimera bootloader has been updated to v4.0.0.
  • The Default theme now includes device icons for Yosemite. Couldn't find the original PSDs from BlackOSX, so made my own in Photoshop. If the Default theme is already installed on your system and you wish to use the new Yosemite icons, copy over the "device_hfsplus_yos_o.png", "device_hfsplus_yos.png", "device_hfsraid_yos_o.png", and "device_hfsraid_yos.png" files from the script's Themes/Default folder to your install's /Extra/Themes/Default folder. The other option is to reinstall the bootloader and replace all contents of /Extra folder (key in "N" for No when prompted to preserve contents). You'll need to reinstall all kexts, plus the DSDT file.
  • I've become aware that quite a few are experiencing boot issues where the bootloader isn't able to find "/mach_kernel." This clearly indicates that users are booting from an older bootloader or are still using a boot plist with the Kernel key and string. Please update any bootloaders you are booting from with, at least, the r2401 revision. Only the this version will identify the Yosemite kernel that is now in a different location (System/Library/Kernels/) with a different name (kernel). Also, make sure the Kernel key and string is removed from the boot plist, as it is no longer needed. The bootloader will determine the kernel name and location based on the OS version.
  • Please read all Known issues below before running the script or if you are encountering booting issues.
Known issues:
  • WiFi: As has been the case in the last few releases of Yosemite, WiFi was not available on my system after a install. After checking cache build logs, it was discovered that the IONetworkingFamily.kext was somehow corrupted. After extracting a fresh copy from the installer via Pacifist and reinstalling it and setting permissions, all was fine.
  • Chameleon bootloader r2401: Only the latest Chameleon bootloader release (r2401 at this time) will boot OS X 10.10 Yosemite. Additionally, only this bootloader will recognize the correct kernel name and path, depending on the OS version: System/Library/Kernels/kernel for Yosemite or the volume's root directory for "mach_kernel" in Mavericks or earlier. It has been suggested to not use the "Kernel" key in the boot plist, as the bootloader will determine the correct name and path. If you use do not update your Chameleon bootloader and the "Kernel" key is missing from the boot plist, like in the current script, boot failure is likely.
  • Native power management does not work correctly via Chameleon's bootloader flags in Yosemite. Additionally, the final public release of Yosemite will KP shortly after boot if the AppleIntelCPUPowerManagement.kext is loaded, necessitating that it be disabled. So, the NullCPUPowerManagement.kext should be part of the kext install process, if you do not have native power management enabled via modified DSDT. See d00d's GA-EX58 and GA-X58A DSDT native power management modifications for info on this modification if you are using this motherboard.
  • 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.
  • Code signing: 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.
  • Compressed packages in Yosemite: At this time, we are unable to uncompress the payload of the Yosemite installer packages. Although the latest version of Pacifist can extract the kernel and command-line utilities that the script needs, it is not possible to do so within the script itself, via BASH command-line. This means the kernel will need to be installed separately during the boot disk creation process. Additionally, you will not be able to install the script to run inside the installer environment.
  • DSDT files in Yosemite: It is no longer possible to extract the ACPI table from a ioreg dump. This means we are not able to generate a new DSDT file within Yosemite. The current workaround is to copy over a existing one or generate one within an earlier OS X version.
  • Apple RAID/Fusion drive: Currently, Mavericks/Yosemite boots into a Apple RAID/Fusion drive only using the script's Combo boot or using the kernelcache method. To use the kernelcache, all kexts need to be installed into /System and the script will set the kernelcache flag as "Yes."
  • EFI partition setups: Mountain Lion 10.8.5 and Mavericks 10.9 changes the behavior of the EFI partition. Previously, we were initializing the EFI partition as a HFS file system, but this doesn't appear to be possible now. The script will still work with existing EFI partitions that were setup as HFS, but will no longer be able to mount and view them in the Finder.
    The new method now is to leave the EFI partition as is, as a MS-DOS FAT32 partition on a freshly partitioned GUID drive. The v8 script will work with this setup now. So, going forward, I recommend existing users with HFS formatted EFI partitions to re-partition their drives. A simple erase will not suffice. For Yosemite: I have not been successful booting from the EFI partition in Yosemite.
  • Kernel cache: Keep in mind the Chameleon bootloader uses the kernel cache by default. The latest version of HackInstaller automatically modifies the UseKernelCache flag depending on whether kexts are installed into /Extra or not. If any kexts are installed in /Extra, UseKernelCache is set as "No". If all kexts are in /System, then UseKernelCache is set as "Yes".
OS X 10.8 Mountain Lion/10.9 Mavericks/10.10 Yosemite Installation:
Script can do a full Mountain Lion/Mavericks/Yosemite install, with sound implemented via modified AppleHDA.kext. AppleRAID is fully supported in the latest Chameleon releases.
  • If using a hard drive or flash drive, partition it as MBR. (GUID partitions cause the BIOS to lock up in my experience on Gigabyte boards.)
  • Mount Mountain Lion/Mavericks/Yosemite ISO/DVD. If you have a ESD download from the App Store, make sure it is in the default Applications folder or place it on the Desktop.
  • If installing OS X 10.10 Yosemite, the kernel needs to be installed separately, as the script is unable to extract it from the installer packages at this time. The Yosemite kernel (v14.0.0) is provided with the script in the Kernels folder. Move the kernel outside its parent folder so that it is immediately within the Kernels directory. (After the boot disk creation process has completed, return the kernel to its original location, so that the script does not install it unnecessarily when running the kext/kernel installer at a later time.)
  • From script, run OS X Installer (menu #1) and select the default Boot Disk option.
  • Select a boot drive from the list of the storage devices and create the boot disk, skipping EFI strings setup. No other steps are needed to prepare this boot drive. However, you may install a DSDT patch file, if you wish or need to.
  • You have the option of setting up your install using the HackInstaller script within the installer environment. If you do not have another drive to boot from, use this method and the script will install the necessary BASH command-line utilities and copy over the script folder. For Yosemite: Do not install the script, as we are not able to extract the command-line utilities needed from the install packages at this time. To complete the install process, you will need to run the script from a different install or another Mac.
  • Restart and boot into new drive, "Mac OS X Base System," using the BIOS drive selector (F12).
  • Make sure your target drive has been partitioned in Disk Utility using the GUID Partition Table (Options button).
  • Install Mountain Lion/Mavericks/Yosemite on the target drive.
  • If installing within the installer environment: After the install and before system reboots (there is a 10-second countdown), select Terminal from the Utilities menu. (If you miss the 10-second countdown period, simply reboot into your boot disk again. A good tip is to open the log window from the Window menu and make sure the log window is active during the install. This will prevent the installer from counting down and restarting automatically.)
    Type hackinstaller and press RETURN/ENTER. Script will prompt you for the desired target drive, install type, and kext loading type, and then proceed to copy the script folder to that drive. After the copy, the script will restart from that location. (Some script features are disabled in this installer environment.)
  • If not installing from the installer environment, reboot into your current OS or maintenance drive.
  • Install the Chameleon v2.2 bootloader (menu #2 and bootloader selection #2).
  • Run Kext/kernel installer (menu #3). For Mountain Lion/Mavericks/Yosemite, install all the audio kexts into /System.
  • Install DSDT patch (menu #5). For Yosemite:] It is not possible to generate a new DSDT file within Yosemite at this time. Either copy over an existing DSDT file to use or generate a new one while booted in Mavericks or any earlier OS X version.
  • Boot into your new install.
NOTE: For additional support, go to Graphics Cards forum for graphics related issues. There are also subforums: Installation - OSx86 10.8 (Mountain Lion), Installation - OSx86 10.9 (Mavericks), and Installation - OSx86 10.10 (Yosemite), as well as Post-Installation/OSx86 10.8 (Mountain Lion), Post-Installation/OSx86 10.9 (Mavericks), and Post-Installation/OSx86 10.10 (Yosemite).

DOWNLOADS:
HackInstaller script package UPDATED! - 10/20/2014 - v8.5.4
(92MB)
Selection of 39+ bootloader themes EXTRA
(180MB) - for use with HackInstaller script v7.1 and up.
Selection of 146 awesome boot pictures EXTRA
(217MB) - for use with HackInstaller script.
Mac OS X 10.7 Lion Kexts
(42MB) - These kexts are no longer part of the standard script download. Just drop the "Kexts_10.7" folder into the script folder and the script will use these kexts for any Lion install.
Mac OS X 10.8 Mountain Lion Kexts
(32MB) - These kexts are no longer part of the standard script download. Just drop the "Kexts_10.8" folder into the script folder and the script will use these kexts for any Mountain Lion install.

All that's really needed to boot into OS X on this board is a disabler (i.e. NullCPUPowerManagement.kext), if you don't have native power management enabled, a decryptor (i.e. FakeSMC.kext) and graphics support. If your card is one Apple makes available, then it should work OOTB or with EFI strings. That's it. Everything else are little fixes for hardware reporting, updated device IDs, audio, network, etc.


DETAILED INSTRUCTIONS AND TIPS ON USING THE SCRIPT IN FULL-FEATURED MODE (not in installer environment):
  • Double-click RUN_HACKINSTALLER and select your target drive from the list. Only GUID and MBR volumes with HFS partitions, including Apple RAID and Fusion drives, will appear on this list. Confirmed target drive name is saved for future use.
  • (The following only applies if you have enabled the "Install/Kext loading selection" option in Preferences.)
    NOTE: On a new install, by default, the script will install kexts on your main System drive in /Extra and create a boot cache based on them. If you wish to be able to choose different install types/modes, enable the preference, "Enable install/kext loading selection (Extra or EFI; cache or E/E)." This will allow one to choose between installing in /Extra or on the EFI partition, as well as installing using the default boot cache mode or /Extra/Extensions mode.
    Select your install type (/Extra or /EFI). This selects the destination of your kext installation - EFI partition or system partition (/Extra). (MBR volumes can only work with /Extra install type and, therefore, this option is skipped.) Default choices are highlighted in bold type and are selectable with the RETURN/ENTER key. (This rule applies throughout the script.)
    Select your Kext loading type (Boot cache or Extensions directory). This selects the way the bootloader will load the kexts at boot. The boot cache mode is the "Apple" way and is arguably faster, as parsing of the kexts' boot data is already done prior to booting (only the boot data is stored in the boot cache if you use the "Normal" cache build option). The Extensions directory mode does not use a boot cache. Instead, the bootloader parses each kext in /Extra/Extensions at boot time. This method may be suitable for situations where a kext doesn't load at boot (OSBundleRequired string is not "Root"), but you still need it available to the system and you don't want it installed in /System (or S/L/E).
  • If no OS has been installed, yet, now is the time to do so. After mounting your Mac OS X Install DVD, ISO, or downloading a ESD from the App Store, select OS X installer (menu #1).
    If using a hard drive or flash drive, partition it as MBR. (GUID partitions cause the BIOS to lock up in my experience on Gigabyte boards.)
    Mount Lion/Mountain Lion/Mavericks ISO/DVD. If you have a ESD download from the App Store, make sure it is in the default Applications folder or place it on the Desktop. (If you have more than one ESD, placing one on the desktop will give it top priority.)
    From script, run OS X Installer (menu #1) and select the default Boot Disk option.
  • Select a boot drive (USB, SATA, or Flash) from the list of the storage devices in use and create the boot disk, skipping EFI strings setup. No other steps are needed to prepare this boot drive. However, you may install a DSDT patch file, if you wish or need to.
  • Restart and boot into new drive, "Mac OS X Base System," using the BIOS drive selector (F12).
  • Make sure your target drive has been partitioned in Disk Utility using the GUID Partition Table (Options button).
  • Install Lion/Mountain Lion/Mavericks on the target drive.
  • Reboot back into your OS X maintenance drive (the drive or system you were using to run the script in).
  • Select Bootloader installer (menu #2) to install your bootloader of choice. The script will determine if a bootloader has already been installed and, if so, which one it is. If you already installed a bootloader, you will be given the option of preserving the contents of /Extra or removing it and starting with a fresh copy.
  • Select Kext/kernel installer (menu #3) to install the kexts (and custom kernel, if desired). This is preconfigured to install the required kexts for the Gigabyte EX58-UD5 motherboard or any motherboard with the same chipsets, with audio being a likely exception. The kext/kernel installer automatically updates the boot caches for you.
    Note that some kexts just do not work in /Extra and must be installed into /System (or S/L/E), instead. These include some audio and networking kexts (The included IONetworkingFamily.kexts have been modified to work in /Extra), as well as the ATY_Init.kext, if needed. So, toggle them from the /Extra destination to /System by keying in their corresponding number in the list and pressing 'ENTER' or 'RETURN.'(i.e. press 6, ENTER). This procedure will change the install destination of the respective kext. If this sounds confusing, just try the script out and it'll make sense as you use it.
    What gets installed are kexts outside their respective repository folders in the Kexts_10.X directory. If you wish to remove and prevent a kext from being installed, place it inside its repository folder or remove it entirely. Likewise, other kexts you wish to add can be placed in the appropriately named category, but outside the repository folder (i.e. IONetworkingFamily.kext in Networking, HDAEnabler.kext in Audio, etc.). When installing for Snow Leopard, the script will automatically select the "Kexts_10.6" folder in the script directory. Likewise, if installing for Mavericks, the script uses the kexts in "Kexts_10.9".
    This rule applies to custom kernels, as well, although there are no folders named "repository" in Kernels. Any kernel (and accompanying System.kext, if available) placed outside of their home folder will be installed when running the Kext/kernel installer. After placing the kernel back inside its home folder, the kext/kernel installer will keep it installed, until you decide uninstall it and restore the original vanilla kernel by pressing "K". Custom kernel installation works for both /EFI, /Extra, RAID, and Boot Disk installs.
  • Boot cache updater* (menu #4) is not necessary if you have just run the kext/kernel installer, as the boot caches have already been updated for you. However, Boot cache updater provides a means for one to update the caches if the kexts have been manipulated outside the script. If one decides to add or remove kexts inside the /Extra/_Kexts_For_Extra folder via Finder drag and drop, he can simply run Update boot caches to complete the process. Additionally, kexts inside the /Extra/_Kexts_For_Extra/_Kexts_For_System folder are installed into /System (or S/L/E) after running Update boot caches.
    If you delete kexts from _Kexts_For_System or transfer them to /_Kexts_For_Extra, they will get uninstalled from /System after updating boot caches. Basically, if the _Kexts_For_System folder is present, the contents of S/L/E will stay in sync with the contents of _Kexts_For_System.
    If, however, you decide not to use the _Kexts_For_System folder, you can disable it via Preferences via "Always include _Kexts_For_System folder in /Extra/kexts directory." The script will still keep track of kexts installed in /System. In either case, the script will "flag" any kexts installed into /System so that their presence is easily seen. This folder provides a convenient way to quickly view what the script has installed (or will install) into /System.
    So, two installation methods exists for kexts - install from via script's folders by running kext/kernel installer or install via drag and drop in Finder and run Boot cache updater.
    * Only available in boot cache mode. In the /Extra/Extensions mode, this menu becomes System boot cache updater.
  • Run the DSDT patcher (menu #5) ONLY on the system it's intended for and the patched DSDT file will be installed in the appropriate location.
    The DSDT patch includes the CMOS reset fix, removes extra CPU 'alias' lines (for ASUS motherboards), and fixes the length difference error (Length is larger than Min/Max window) that pops up on the new ASL compiler.

    ADVANCED FEATURES:
    The following script features are available in the Kext/kernel installer and Boot cache updater routines:
    Change kext's "CFBundleVersion" string (version number): Enter the number of the kext in the list, followed by a separator (space, colon, or hyphen), followed by the desired number string (e.g. 9.99, 2.00b2, etc.). Change this string by increasing the number if you wish to ensure this kext has loading priority over another version that may be installed in elsewhere. It should be noted that kexts in /Extra will always be loaded by the bootloader before those in /System anyway. However, in some situations, when presented with two versions of the same kext, the kernel may prefer the latest version and ignore the other. In these situations, you can have control by changing the version number. The script will highlight in purple the version number of any kext that has an equivalent Apple version already installed in /System (e.g. IONetworkingFamily.kext, AppleHDA.kext, etc.). To the side of this kext's version number will be a "greater than", "less than", or "equal" symbol, highlighting its relationship to the one installed in /System. And, yes, this includes kext PlugIns in /System, as well.
    Change kext's "OSBundleRequired" string (mkext filter): Enter the number of the kext in the list, followed by a separator (space, colon, or hyphen), followed by the desired string (e.g. Root, Local-Root, Network-Root, Safe Boot, etc.). This change will also update all Plugins, if any are included. NOTE: Modifying this string should be done sparingly, as not all kexts respond favorably with this change. The IONetworkingFamily.kext and it's associated networking PlugIns are good candidates. On the other hand, the ATY_Init.kext that's commonly used for graphics injection should not be changed from its default string, "Safe Boot." Changing it to "Root" will prevent proper operation and you'll unlikely be able to see your desktop at boot time.
  • If you experience any issues or have questions, please review the FAQs, posted below, or post to this thread.
Being human, I may have goofed somewhere, so provide feedback in this thread if there are issues.
Disclaimer: I will not be held responsible for any damages, non-working systems, explosions, dead kittens, screaming monkeys, etc. that may result from following these instructions.

FAQs:

BOOTING
  • When I boot, I get the following message:
    boot 0: GPT
    boot 0: testing
    boot 0: testing
    boot 0: error
    What's wrong?
    This message appears when the BIOS cannot find a bootable system. Double-check your BIOS drive priority or make sure the BIOS is instructed to boot from the proper drive with a installed bootloader. This can also happen with Advanced Format/4K Sector drives. The best way around this issue is to install the bootloader with the target drive unmounted.
  • I get the multi-language restart message when I boot. How can I fix the problem?
    This description is basically a kernel panic, but we have no information as to why the kernel panic has occurred. For us to troubleshoot the system, we need to boot in verbose mode using the (-v) flag at the bootloader prompt. This will provide a real-time boot log that is helpful in diagnostics. General practice is to take a picture of where the boot log stalls and post it for your forum members to analyze.
  • All I get is "Still waiting for root device" message. It's been that way for hours!
    Your system is waiting for a bootable system drive to appear and is not able to find it. Make sure AHCI mode is enabled in the BIOS. Double-check your BIOS drive priority. If you are using a IDE or PATA drive (not recommended), you may need to change the Master/Slave arrangement. This can also happen on a multi-partition drive where the boot partition is not "set active." In a multi-partition drive, the BIOS needs to know which partition you want to boot. The HackInstaller script takes care of the partition activation process automatically, which includes the EFI and RAID partitions.
  • I get a short boot log and the last message reads, "Still waiting for root volume." What is it waiting for?
    It's waiting to access the rest of the System files, but is not able to. If the log appears to show that all the kexts in /Extra have loaded, but no other activity is forthcoming and nothing else in the /System directory is loading, it may be that the SATA controller isn't in AHCI mode. This can also happen in EFI setups (kexts are stored on EFI partition) where the boot.plist may be missing the boot-uuid flag that points to the System partition. This shouldn't happen when using the script, as the flags are always installed with the bootloader.
  • 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, however, 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.
  • When I try to boot into my system, nothing happens.
    In order to resolve any issues, we need as much information as possible. "Nothing happening" is too little information. Make sure you are booting with the verbose flag (-v), so that a progress log is provided during boot. Posting pictures of where progress appears to stop is an invaluable aid in troubleshooting problems.
    If you get a black screen, video corruption, or seemingly no boot progress (but, no kernel panic) upon booting into your new install, you likely have a graphics issue where the system is unable to display the video. Because there are so many variables at play here with the many graphics cards in use, it's advisable that you search the InsanelyMac Graphics Card forum for some answers. Most likely, there are others who have already gone down this path and posted solutions to follow.
    Graphics injectors for nVidia cards include NVEnabler.kext, NVinject.kext, or NVkush.kext, all found in the Kexts/Graphics/repository. Other options include inserting EFI strings into the boot plist, something the HackInstaller script can, also, do for you.
  • I just installed a new OS and bootloader. Now I can't boot back into my old install. What happened?
    You have different and, therefore, incompatible, bootloaders installed. Ideally, each bootable partition needs to have the same bootloader installed. If that is not attainable, then you need to select the desired OS/partition via BIOS drive/partition selector (F12), not bootloader, to ensure your system boots just the bootloader installed for that partition/drive. If you select a partition in the bootloader screen that has a different bootloader installed, you may experience instability or unpredictable behavior, including kernel panics.
GENERAL SYSTEM BEHAVIOR
  • My Ethernet ports are not working. What can I do?
    First verify whether this is a hardware or software issue. If you have another working OS to boot into, do so and check for network access. If you don't have another OS to boot into, the BIOS may feature a LAN check that you can use. Consult your motherboard manual for instructions. NOTE: On the Gigabyte GA-EX58-UD5 motherboard, LAN failure is a common problem. The remedy is to simply pull the power cord (or turn the PSU switch off, if it has one) for 10 seconds. Failing that, you may clear the CMOS using the CMOS Clear Switch on the back panel after the system is powered off. Make sure you have saved your BIOS setting, so you can load them after the clear.
SCRIPT
  • Can the script work for other motherboards?
    Absolutely. The main difference between the setup of one motherboard and another are the choice of kexts needed for full functionality. One needs to know what chipsets the board uses (e.g. Audio, Ethernet, Firewire, Northbridge and Southbridge) and whether there are kexts that support them. Other matters may include the choice of modified kernel, use of EFI strings, and device-specific DSDT patching, all of which the script supports.
  • What is the difference between the /Extra install and the boot from EFI partition install?
    The /Extra install method installs the bootloader support files in a folder named "Extra" right in the root directory of your boot volume, easily visible to the user. The /EFI boot method installs the support files in a special 200MB partition that's created on all GUID partitioned drives. This EFI partition is normally invisible to the user and is generally unaccessible, except by the Terminal.
  • Which install method is superior?
    This is mostly a matter of personal preference, as the technical advantages/disadvantages are small. For some, having the /Extra folder visible and accessible makes management and troubleshooting a cinch. For others, having such patched files invisible is a priority and provides a more Mac-like appearance.
    At the current time, there are some bugs and annoying behaviors exhibited by the EFI boot setup:
    • EFI partitions in Snow Leopard and up are treated like regular partitions once they have been formatted as HFS. This means they get automounted at boot time. The latest script version (starting from v4.5) will now modify the file system descriptor and prevent EFI partitions from automounting. This is no longer the case, as we no longer repartition the EFI partition as HFS. It remains a MS-DOS (FAT32) partition.
    • Bootloader doesn't display and pre-select the OS partition on multi-partitioned drives at startup. (This can be resolved by using the "Default Partition" key in the smbios.plist and setting it to the proper disk ID in the form of hd(1,2). However, note that if you are adding/removing volumes, this ID will change and the key/string will need to be updated to reflect this change. Additionally, disk ID ordering is dependent on which drives spin up first and are readable by the BIOS.)
  • Must I update boot caches after I run the Kext/Kernel Installer?
    No. The boot caches are automatically updated at the end of the Kext/Kernel Installer routine. The separate Boot Caches Updater step is for when you add, delete, or move kexts in the Finder without involving the Kext/Kernel Installer.
  • I have a dual graphics card setup. When I import my EFI string using your script, it warns, saying the device trees are not for this system. However, when I let the script fix it, the EFI string no longer works. What's wrong?
    The script currently doesn't support dual graphics cards, yet. This is a unique setup where you have two devices sharing the same device type. Use a third-party EFI string creator (i.e. EFIStudio) and paste the results in the boot plist or EFI_string.txt and import. But, this time, just ignore any warnings about the device trees, until dual-card support is provided.
    When you let the script 'fix' the string, it will currently place the same device tree in both places; not what you want.
  • When I set 'active' a partition, I notice the install log displays, "fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory" Is there something wrong?
    Nothing is wrong and this is normal behavior. Note that 'fdisk' is a 'DOS partition maintenance program' and includes features not designed for our Macs. In our case, that error is meaningless, as we are not writing with a new MBR file, but merely editing existing MBR sectors. The error simply states that the boot code isn't available for writing Intel bootable partitions. Apple doesn't use that code anyway, as the EFI boot code is built into the firmware.
  • The install log also shows the following error message when I set a partition active, "fdisk: 1> Invalid command 'y'. Try 'help'." Why is there a invalid command?
    The 'fdisk' program is in 'interactive' mode. If the partition you are wishing to set active is not able to unmount (as would happen if the partition is the working boot partition), fdisk will ask if you want to write the update anyway, at which point we would say "yes" with a 'y'. However, because the partition was able to successfully unmount, the "yes" response is invalid in this case and, therefore, ignored. We try to cover all cases.
  • Can someone provide a simpler and more easily understood tutorial, one without all the terminology and terms I don't understand? I don't want to read all these pages!
    Probably, but I certainly won't. The simple reason it that it's a recipe for failure and harbinger for disaster. Building a 'hackintosh' is a technical achievement; it requires a computer-related background and technical foresight. Going the 'easy' way now won't help you in the long term. If you manage to get your system running without such understanding, you have learned nothing in return to prepare you for future challenges, such as when your system goes down. Which position would you rather be in: one where you are at the mercy of others each time something goes wrong with your system, or one who, with manly determination, is resolved to work through such issues on his own with thorough research and study, while building up confidence and pride of accomplishment in return? I often wonder if we're doing the community a favor by writing such scripts. But, my rationale is that I enjoy using such tools myself, to say nothing of the joy of scripting such a project and seeing it develop and progress.
SCRIPT CHANGE LOG:
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 below before running the script or if you are encountering booting issues.
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.
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 below if you are encountering booting issues.
UPDATE: 10/8/14 - version 8.5.0
  • Support for OS X 10.10 Yosemite: Lots of script changes were required, mostly dealing with the kernel path being changed from the drive's root directory to /System/Library/Kernels, as well as the kernel's default name from "mach_kernel" to "kernel". Much of the script has been rewritten and commented.
    Another issue creating more work is the new compression type used for the OS install packages and kernelcache. This means that the script is unable to unpack the install packages to extract the kernel, as is usually done. So, the vanilla kernel (version 14.0.0), located in Kernels, needs to be installed separately.
    Making Yosemite bootable in the Chameleon bootloader would not be possible without the dedication and hard work of a number of developers: Andy Vandijck, Pike R. Alpha, and MinusZwel, to mention a few.
  • Enabling/disabling TRIM support for third-party SSDs has been added for OS X 10.10 Yosemite - located in Utilities.
  • Check native power management status on running system in Utilities: Fixed some bugs and updated script to show Turbo Boost calculations for both Nehalem and Sandy Bridge/Ivy Bridge microarchitecture in log.
  • Create Fusion drive: Reworked the confirmation reply to be safer. This is one area where mistakes cannot be tolerated. After confirmation, the selected drive(s) will be destroyed to create or defuse a drive.
  • Updated VoodooHDA.kext to 2.8.5 for Mavericks.
  • Updated FakeSMC.kext to 6.10.1323 for compatibility with OS X 10.10 Yosemite.
  • Added and updated the following themes: Mavs, Mavs Style, Universe, idisplay, and LoginToLion.
UPDATE: 5/29/14 - version 8.1.2
  • DSDT patcher in OS install environment: Fixed a bug where the script attempted to update the DSDT log in the read-only OS install environment. This would create a long list of lines in the Terminal when running the DSDT patcher.
UPDATE: 5/28/14 - version 8.1.1
  • Assorted utilities: Fixed another bug that would cause the Native Power Management check to fail.
UPDATE: 5/27/14 - version 8.1.0
  • Full Fusion drive support: Finally got a SSD (Samsung 840 EVO 250GB) to build a Fusion drive on my system. So debugging is no longer guesswork. I recommend installing this setup, if you haven't already. Very fast boots, even on the older 3Gb SATA II ports (260MB/s writes and 270MB/s reads). When using sleep, boot time is just a minor inconvenience. But, when you're doing lots of testing, it becomes a significant factor.
  • Assorted utilities: Added ability to create or defuse Fusion drives. Automatically selects the drives, if only one of each is present, then prompts you for confirmation.
    FYI: This Fusion drive build procedure uses the entire drive (all partitions), so all partitions are destroyed in the process. It is my understanding that Apple does not intend to use drive partitions as part of the Fusion drive building process and may completely remove such support in the future. So, if you wish to have additional partitions, repartition the Fusion drive in Disk Utility after it's created.
    FYI: It appears that adding the Logical Volume UUID as a boot argument for Fusion drives causes issues - either it may fail to boot or iCloud, iMessage, and Facetime accounts fail at login. So, no boot UUID is added for Fusion drives when the bootloader and support files are installed.
  • Modify plists: Fixed a bug that caused Fusion drives to appear twice in the plist lists.
  • Assorted utilities: Reworked and reenabled the SSD Trim Enabler feature with OS 10.9 Mavericks support.
  • Bootloader: Added ability to rename bootloader's bootbanner name for binary downloads. So, instead of Chimera reading as "Chameleon v2.2svn r2378", it's renamed as "Chimera v3.0.1 r2378", based on the binary file's name.
  • Bootloader: Added ability to access bootloader webpage, even with access fails. If check fails, just use bootloader number, followed by "U" (Update) or "D" (Download) to open webpage.
  • Boot disk creator: Fixed a bug that would allow a user to attempt a boot disk install without any kexts available for that OS version. Thanks, Paul! :D
  • Assorted utilities: Fixed a bug that would cause the Native Power Management check to fail, as it failed to parse the OS version correctly.
  • Select boot picture: Fixed a bug that prevented users from selecting from the list.
  • Updated Kexts:
    • FakeSMC.kext updated to v6.8.1307.
    • AppleHDA.kext for ALC885/889a updated to 10.9.3 version (2.6.1f2). If you are still on 10.9.2 or earlier, look in the Audio/Repository for the correct version to install.
    • RealtekRTL8111.kext to v1.2.0
    • Updated IONetworkingFamily.kext to 10.9.3 (version is same, but build number has changed)
(All previous updates are included in script's change log.)

HELPFUL LINKS: kind regards,
MAJ
  • Like 20
darkenedreality
darkenedreality
Posted
Posted

The script is trying to install the kexts within the individual _repository folders. Don't know if this is just me though......

 

edit: ....just me :P copied from my FAT usb drive to my HFS+ one and now it works.......

rappinkapc
rappinkapc
Posted
Posted

OK. I am a complete newbie at this. I just got my hardware, and luckily for me, this thread is ready right at the same time I am. So, I hooked up my new HDD to my MBP running Snow Leopard, formatted and ran the script. After asking for my password the first thing I see is:

 

"IMPROPER OS! This script will only run on Leopard or Snow Leopard OS!"

 

Interestingly, the 4.0(RC) version doesn't give me this message, but I would rather try out the new installer. Any advice?

duomaxw
duomaxw
Posted
Posted
After asking for my password the first thing I see is:

 

"IMPROPER OS! This script will only run on Leopard or Snow Leopard OS!"

 

I've got the same problem on my 10.6 install.

 

I also had the same message using this on 10.5.0 but after upgrading to 10.5.7 the improper OS message went away.

darkenedreality
darkenedreality
Posted
Posted

Had the same problem.

Could be wrong but I don't think the string would have to be formatted. As the output of 

sw_vers -productVersion

should meet the CASE statement of "10.6".

So I Removed the line: 

RUNNING_OS=${RUNNING_OS%.*}

from the script and it worked for me.

taylorutah
taylorutah
Posted
Posted

Updated:

I have a hard drive with SL 10.6 installed and ethernet works, but only when i set this hard drive to boot as priority in bios.

 

I am installing a new drive with 10.6, this will be my main the other was a test. I have it installed but ethernet isn't working. I set this drive as priority and still no ethernet. Everything else seems solid.

 

what did i miss on this one?

 

I have swapped DSDT.aml and com.apple.boot.plist files and can't get it to work. seems to have something to do with booting and possibly boot loader. I am using the /Extra install and the RC3 boot loader.

 

ideas?

matinee
matinee
Posted
Posted

DD, thanks for the amazing work.

 

Another newbie question: I've already successfully installed (and been using) 10.5.7 using your previous script+guide but have been overwelmed by the 140+ pages of subsequent conversation which might answer this: can I use any of this new script to UPGRADE my current 10.5.7 install? Otherwise, do I need to start over with a fresh volume using this new script+guide?

 

2nd (also newbie) question: If I do have to start over using this script+guide, when you refer to to RETAIL here, are you referring to the new 10.6 Snow Leopard Retail DVD or do I need to utilize both my orig 10.5 Leopard Retail DVD as well as the new 10.6 Snow Leopard DVD, and if so, how?

 

Thanks in advance for your patience.

eggfoam
eggfoam
Posted
Posted

Thanks for all this great work, MAJ! I've been looking through your script to learn more in advance of my mobo arriving for my first build on Thursday, and I'm really impressed with the sheer amount of functionality you built in. (I'm a pretty experienced programmer, but I haven't done much shell scripting. The if/fi construct always weirds me out a little. :wacko: )

 

Anyway, I have a quick question. Since the DSDT patching must be run on the machine it's intended for, and Snow Leopard borks the CMOS if you boot without a patched DSDT, does that mean I need to install Leopard on my new rig before Snow Leopard so that I can create a patched DSDT? Or is there a way around that that I'm missing? It seems like a chicken-and-egg problem if you're trying to install only 10.6 and not bother with 10.5. I have a MacBook running SL that I can use for all other steps of the scripted install.

 

Or can we use koalala's DSDT patcher from Windows to generate an acceptable DSDT before attempting to boot SL for the first time?

 

Thanks!

-eggfoam

digital_dreamer
digital_dreamer
Posted
  • Author
Posted
Had the same problem.

Could be wrong but I don't think the string would have to be formatted. As the output of 

sw_vers -productVersion

should meet the CASE statement of "10.6".

So I Removed the line: 

RUNNING_OS=${RUNNING_OS%.*}

from the script and it worked for me.

Ah! No trailing zero after "10.6".

Sorry about that.

 

I'll fix it right up.

 

MAJ

 

EDIT: Fixed and uploading...

Here's the updated script file for those that just want to replace the file in /~extra, instead of downloading the entire package.

digital_dreamer
digital_dreamer
Posted
  • Author
Posted
Thanks for all this great work, MAJ! I've been looking through your script to learn more in advance of my mobo arriving for my first build on Thursday, and I'm really impressed with the sheer amount of functionality you built in. (I'm a pretty experienced programmer, but I haven't done much shell scripting. The if/fi construct always weirds me out a little. :) )

 

Anyway, I have a quick question. Since the DSDT patching must be run on the machine it's intended for, and Snow Leopard borks the CMOS if you boot without a patched DSDT, does that mean I need to install Leopard on my new rig before Snow Leopard so that I can create a patched DSDT? Or is there a way around that that I'm missing? It seems like a chicken-and-egg problem if you're trying to install only 10.6 and not bother with 10.5. I have a MacBook running SL that I can use for all other steps of the scripted install.

 

Or can we use koalala's DSDT patcher from Windows to generate an acceptable DSDT before attempting to boot SL for the first time?

 

Thanks!

-eggfoam

eggfoam,

Thanks for your comments.

I used to program in machine and assembly 20 years ago, and never have done anything since, until now (well, it's scripting, I know). So, I'm trying to make up for those 20 years. :P

 

I think the PC-EFI v10 bootloader will allow you to boot without the DSDT file (if it's possible). So, if you use that bootloader, you should be able to boot into it without a DSDT patch, but I can't confirm and haven't tested. Anyone know about this?

If true and it works, then you can patch and reboot.

 

The other bootloaders are known to stall without the file. Here's the bug log from PC-EFI v10.1, posted on July 29:

Just a small fix for booting system without DSDT.aml system was stalling on motherboards like gigabyte, where bootloader fails to find pointer to acpi 2.0 table, fixed.

 

I might test this out and get back to you, but it's 2:30 a.m. now and need to get to bed (off to work at 6).

 

regards,

MAJ

digital_dreamer
digital_dreamer
Posted
  • Author
Posted
YEAH!!!

I ♥ DD

btw: I really loved that heart to the left of the topic. It makes things simplier to find it. Want it here too :<

ADDED! :P

 

Hi, proengin!

Good to 'see' you. :)

knightprozac
knightprozac
Posted
Posted

Hey DD. I was gonna send this RAID info as a PM but I couldn't figure out how to use attachments for PM

 

Curiously the RAID_list.txt says no RAID sets found. This might have something to do with Mac OS X recognising my hardware RAID as one disk from my JMicron Ports.

 

Anyway awesome work man. I might try and figure out how to do things with RAID before you get your script up for it but hopefully these files can help anyway. If I'm successful I'll certainly post my methods/experiences.

disk_list.txt

RAID_list.txt

eggfoam
eggfoam
Posted
Posted
eggfoam,

Thanks for your comments.

I used to program in machine and assembly 20 years ago, and never have done anything since, until now (well, it's scripting, I know). So, I'm trying to make up for those 20 years. :P

Wow, assembly programming ... I took a couple classes in college where I needed to do that, and that was plenty for me. :) I don't know if you've checked out the Cocoa/Obj-C environment at all, but it's one of the most pleasant language+framework combos I've ever used. It's a far cry from assembly or even straight C (though you can always use that if you need maximum speed) and it doesn't beat you over the head with its object-orientation like Java does...

 

I think the PC-EFI v10 bootloader will allow you to boot without the DSDT file (if it's possible). So, if you use that bootloader, you should be able to boot into it without a DSDT patch, but I can't confirm and haven't tested. Anyone know about this?

If true and it works, then you can patch and reboot.

 

The other bootloaders are known to stall without the file. Here's the bug log from PC-EFI v10.1, posted on July 29:

(snip)

 

I might test this out and get back to you, but it's 2:30 a.m. now and need to get to bed (off to work at 6).

Thanks for this info, MAJ. I'm planning to do a couple of different install methods later this week before I set up my system for real work. I'll see what approaches work best and post here. I suspect koalala's Windows-based DSDT patcher (http://www.insanelymac.com/forum/index.php?showtopic=142434) might help, since it doesn't need to run on the target box as long as you can extract the initial DSDT from the target box (which is also possible under Windows). But it's unclear to me exactly what types of modifications it can do, so I'll have to wait until I can sit down and fiddle with the various tools.

 

Yes, PC-EFI 10.1 booter can boot without DSDT but obviously you will get CMOS reset. I guess it is ok for 1st boot.

Thanks, proengin, good to have confirmation. The CMOS reset becomes relevant *next time* you boot after booting SL without the DSDT fix, right? So is there any problem with generating the DSDT during that first-boot session that resets the CMOS?

 

Much obliged for all the advice --

Best,

eggfoam

Nargilem
Nargilem
Posted
Posted

I just flashed the new BIOS (F9e) and it has a new option which seems to be great for OSX.

Instead of SATA/AHCI mode: Disabled / RAID / AHCI it replaced Disabled by IDE.

 

I selected IDE as SATA/AHCI mode and also IDE as SATA/IDE Ctrl mode and Leopard is working fine now (with intel chipset driver from iAtkos v7). I'm now trying to make snow leopard work in this mode as it boots a lot faster (you don't get the AHCI window after BIOS).

 

Just thought this might be useful to some :D I'll post further updates here.

krypto
krypto
Posted
Posted

I Have Raid 0 setup on the ICH10 Sata ports , is there any way of installing Snow leopard without changing the Raid option?

 

IE :

2 x HDD raid 0 mode

1x HDD in non raid mode

 

Can i use the single hdd thats not part of raid to install OSx SL?

 

:)

morganpl
morganpl
Posted
Posted

Sleep works, but probably my system there is something wrong ... this is not a rule that every time I wake up the KP, is once and another time the system wakes up properly. I attach a screen with KP, and a list kexts. Please Write down where to look ...?

 

Than you!

 

post-315211-1252498343_thumb.jpg

post-315211-1252568551_thumb.png 

MATTkiller
MATTkiller
Posted
Posted

Hello,

 

To begin, Thanks you very very much for your work and excuse my language because I'm Frech .

Okay, I followed all steps exept one.

I have a macbook who's running SL and I do all step from that.

Then I can't create a DSDT.aml file.

When I boot on SL after running all step, I get this message :

:/ root# panic(cpu 0 caller 0x2f7d1f60): "No HPETs available...CPU(s) configured incorrectly\n"@/SourceCache/AppleIntelCPUPowerManagement-90/pmThread.c:148

Debugger called: <panic>

Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)

0x2f70bf08 : 0x21acfa (0x5ce650 0x2f70bf3c 0x223156 0x0)

0x2f70bf58 : 0x2f7d1f60 (0x2f7dd3a8 0x8 0xc120e4db 0x4)

0x2f70bfc8 : 0x29c68c (0x0 0x0 0x222334 0x222334)

Kernel Extentions in backtrace (with dependencies):

com.apple.driver.AppleIntelCPUPowerManagement( 90.0.0)@0x2f7cd000->0x2f7e4fff

 

BSD process name corresponding to current thread: kernel_task

 

Mas OS version :

10A432

 

Kernel version :

Darwin Kernel Version 10.0.0:Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386

System model name: MacPro4,1

 

System uptime in nanoseconds: 20613344669

HeartQ8
HeartQ8
Posted
Posted

DD,

 

Script report Snow wrongly (I am using Snow on my recovery disk to install Snow to main disk) so I have to edit it in this way to run :

 

case "$RUNNING_OS" in

"10.5") OS_NAME="Leopard";;

*) OS_NAME="Snow Leopard";;

*) echo -e "${yellow}${bold}${rev} IMPROPER OS! This script will only run on \

Leopard or Snow Leopard OS! ${plain}\n"; echo -e "Running OS version: $RUNNING_OS ($OS_BUILD)" >> "$LOG"; exit;;

 

I found permission issue with installing any program to S/L/E (try Soundflower-1.4.3.dmg).

last the Bonjour Networking protocol not working and I can not see my printers and Ext Hard Disks.

 

DD Thank you and keep up the good working up.

knightprozac
knightprozac
Posted
Posted
I Have Raid 0 setup on the ICH10 Sata ports , is there any way of installing Snow leopard without changing the Raid option?

WTF

 

I tried to get my RAID 0 to work on the Blue ICH10 ports and couldn't on 10.5.7. I searched the net for ages for a solution but only found info saying there were no Apple ICH10 RAID drivers so it was impossible to use RAID with those ports.....

 

In answer to your question some people have managed to install SL onto RAID. You can find the info on their relatively recent posts in the old 10.5.8 thread by DD.

 

Please tell me how you got RAID 0 working with the Blue ICH10 Sata ports. Having to use JMicron has taken away my Sleep functionality (something I used to use alot on my old G5).

 Share
Go to topic listing
×
×
  • Create New...