Jump to content

[GUIDE] Scripted Retail Mavericks/Mountain Lion Install on Gigabyte Mobos


  • Please log in to reply
4371 replies to this topic

#1
digital_dreamer

digital_dreamer

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,077 posts
  • Gender:Male
  • Location:Missouri USA

USING THE HACKINSTALLER SCRIPT
TO INSTALL LION/MOUNTAIN LION/MAVERICKS
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


SCRIPT UPDATE:
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)
Known issues in Mavericks:
  • Bootloaders: Compiling builds in Xcode 5.0 in Mavericks fails. Some are bugs in Chameleon and some are bugs in the compiler. Xcode 5.0.1 fixes some things. Download the precompiled builds for Chimera, for the time being.
  • Native power management: Unless the DSDT is modified further, the AppleLPC.kext will not load at boot and CPU temperatures will be roughly 10 degrees C hotter. The script will fix/patch this issue, even if it's been previously modified.
  • Apple RAID/Fusion drive: Currently, Mavericks 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.
  • 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.
OS X 10.7 Lion/10.8 Mountain Lion/10.9 Mavericks Installation:
Script can do a full Lion/Mountain Lion/Mavericks 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 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.
  • 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.
  • 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.
  • 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.)
  • 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.)
  • Install the Chameleon v2.2 bootloader (menu #2 and bootloader selection #2).
  • Run Kext/kernel installer (menu #3). For Mountain Lion/Mavericks, install all the audio kexts into /System.
  • Install DSDT patch (menu #5).
  • 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.7 (Lion), Installation - OSx86 10.8 (Mountain Lion) and Installation - OSx86 10.9 (Mavericks), as well as Post-Installation/OSx86 10.7 (Lion), Post-Installation/OSx86 10.8 (Mountain Lion), and Post-Installation/OSx86 10.9 (Mavericks).

DOWNLOADS:
HackInstaller script package UPDATED! - 5/29/2014 - v8.1.2
(82MB)
Selection of 36+ bootloader themes EXTRA
(128MB) - 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.

All that's really needed to boot into OS X on this board is a disabler (i.e. NullCPUPowerManagement.kext), 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.
  • 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 discriptor and prevent EFI partitions from automounting.
    • 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: 2/8/14 - version 8.0.9
  • Reenabled the SSD Trim Enabler feature in Assorted Utilities with OS 10.9 Mavericks support.
UPDATE: 2/8/14 - version 8.0.8
  • Fixed a bug related to Fusion drive setups. Script did not correctly identify Fusion drive and insert proper boot UUID when installing bootloader. If there are any other issues regarding HackInstaller script behavior with Fusion drive setups, please let me know. I don't have a Fusion drive, so it's very hard to simulate this setup and test.
UPDATE: 1/13/14 - version 8.0.7
  • No actual updates to script - just bootloader and kext updates for 10.9.1. (However, script is updated to v8.0.7 to reflect the following kext updates.)
  • Updated Chameleon v2.2 bootloader to r2327.
  • Updated AppleHDA.kext to 2.5.3fc1 for Mavericks 10.9.1 (ALC885/889a). Note that this 10.9.1 audio kext is part of the default install, so if you are still running 10.9.0, use the older kext in the repository folder.
  • Updated FakeSMC.kext to 6.0.1067, which includes new HWMonitor app.
UPDATE: 11/11/13 - version 8.0.6
  • Fixed an issue where the native power management check in Utilities would fail when checking the system.log for messages from the AppleIntelCPUPowerManagement.kext. This resulted in the status recorded as "failed" and was due to Mavericks OS using gzip to compress the system log, instead of bzip2 as in previous releases.
  • Fixed "About This Mac" graphic installer. Now works with Mavericks, which requires the 4-character extension .tiff. Also works with Mountain Lion, which requires that the included .tif graphic files be converted to PNG format with the .png extension. I never thought Apple would keep changing the formats or naming convention on these files with each major OS release.
  • Included a 64-bit version of the lspci command so the native power management patch in the DSDT script will function correctly in the OS install environment. The previous version was 32-bit only and didn't work with the 64-bit libraries in the OS Install environment.
  • Moved all logs to /Library/Logs so that they are easily accessible in Console. Mavericks made it a pain managing the logs, as the window positions are never saved and the open log is not saved to the Log List. Additionally, keeping the logs at the "Now" position was broken and unpredictable. Accessing them in /Library/Logs appears to fix these issues.
UPDATE: 11/1/13 - version 8.0.5
  • DSDT Patcher: Script should be able to recognize incomplete LPC edits and strip in the complete fix, so that the AppleLPC.kext will load and Native Power Management will function properly. Script will also recognize if more values were previously injected than the minimum 4 and just move on, rather than replace all previous values with the 4 required.
  • Fixed an issue where the script would not correctly remove the previous conflicting bootloader setup when switching between /Extra and EFI setups, as well as RAID setups. Now, the bootloader files are correctly removed and the stage-1 Partition Boot Record is restored to its original virgin state. This applies to all install setups: /Extra, EFI, RAID, and Fusion.
  • Fixed an issue that prevented the "Show System files as visible/invisible" from working in OS X 10.8 Mountain Lion.
UPDATE: 10/28/13 - version 8.0.4
  • Added “Remove” feature to kext installer for temporary uninstall/ignore: kext number followed by “x” or “r”
  • Fixed an issue where the script would not recognize a MBR partitioned drive for use as a install target.
  • Fixed an issue in the Boot Disk Creator where on some systems extracting a package failed, resulting in the kernel not being found and copied over. This was due to an older version of the tar command that lacked the --include option. The command has been reworked to function without the --include option.
  • Fixed a bug that occurred when the script attempted to change the bootbanner name when compiling source.
  • The included IONetworkingFamily.kext has been updated to work in /Extra.
  • Added warning message for when a EFI partition is failing to mount and repairs must be done. If EFI partition is unable to be repaired, a new MS-DOS (FAT32) file system is created. The warning message also alerts the user that all data on this partition will be lost and must be recreated.
  • Added "Make System files visible/invisible" to Utilities.
UPDATE: 10/22/13 - version 8.0.3
  • OS X 10.9 Mavericks ready.
  • Bootloaders: Includes latest Chameleon v2.2 RC5 bootloader (r2266).
    Added modules install option where user can install, remove, or ignore available modules. Use arrow keys to navigate, much like the DSDT fixes.
    Changed bootloader update checking and download behavior: Website authentication via command line (curl) has become way too difficult to reverse engineer and the goalpost is always changing. Not worth spending more time and effort on this! However, the script will attempt to determine if an update is available and then open the target webpage in the default browser where the user can download the binaries. The update package can then be dropped into the HackInstaller's ~extra folder for automatic processing.
  • Fusion drive: Support for Fusion drive setup. Would appreciate additional feedback.
  • Apple RAID: Support for nested RAID drives (RAID within RAID). Not fully tested, as I don't have such a setup and didn't think this was possible at first. But, I've had users attempt to use the script with such a setup and it was a disaster. Would appreciate any brave volunteers.
  • Advanced Format/4K Sector drives: Support for these drives (Most hard drives sold since 2011). These drives make it hard to install the stage-1 bootloader, which can lead to a "boot 0: GPT" message at boot (in the case of a single drive install) or the bootloader switching to another drive where it finds a valid bootloader. The best way around this issue is to install the bootloader with the target drive unmounted.
    Auto method: If the script determines the target partition is not the booted drive and the HackInstaller script is not running on that drive, it will attempt to unmount said drive and perform the stage-1 bootloader install. If it is not able to unmount the drive for some reason (open file, app, etc.), the install will fail and the log will show "Resource busy" at that point.
    Manual method: After entering the Bootloader installer, you can eject the target drive and then proceed with the installation.
    Install environment: Attempting to install the bootloader on this type of drive within the installer appears to be only possible if it is done prior to installing the OS. (Once the installer has installed the OS files, the script is unable to unmount the drive.) So, try installing the bootloader from the script first by getting the script to copy itself to a drive other than the target drive. This is important, as the script cannot unmount itself! Again, select a different "target" drive and allow the HackInstaller to be copied to it, then change your install target back to the desired install drive. This way, the script can safely unmount the target drive for a successful bootloader install.
  • Menu has been reordered: It is in the sequence one would use when installing, starting with OS Installer. Boot Disk Creation has now been moved to OS Installer, as it is the main feature used to install OS X.
  • Added updated Default theme that include Mavericks icons.
  • DSDT Patcher: Added native power management patches. After running this routine, you should be able to uninstall the NullCPUPowerManagement.kext and SleepEnabler.kext, and add two bootloader flags (GeneratePStates and GenerateCStates) to enable the built-in power management features. As for OS 10.9 Mavericks, some extra DSDT editing was required to get the AppleLPC.kext to load for fully functional native power management.
    If the script is not able to create a complete fix here (it will tell you one way or another), reboot without loading a DSDT file and rerun the HackInstaller patcher to generate a clean DSDT with fix.
  • DSDT Patcher: The script no longer uses fassl's DSDT Patcher utility, as many fixes are now built into the script (but not all). This required that a common fix be scripted in for the "Method local variable is not initialized (Local0)" error.
  • Added fix in Assorted Utilities for "Valid DVD Drive could not be found -70012" when using the DVD player in Mountain Lion or Mavericks.
  • Script recognizes and works with the Growl 2.0 and the new notification system introduced in OS X 10.8 Mountain Lion and 10.9 Mavericks. Growlnotify 2.0 for the command line is included.
  • Updated FakeSMC.kext to v5.3.901, which includes an updated HWMonitor app (in Misc_Patches repository).
  • Added updated AppleRTC.kext for 10.9 Mavericks.
  • Added Slice's RealtekR1000SL.kext v3.0.4 network driver, which includes support for RTL8168E,F/8111E,F. This is supposed to be better than Realtek's native driver.
  • Added AHCI_3rdParty_SATA.kext to fix the "A valid DVD drive could not be found [-70012]" error. This fix is recommended over the framework patch that is used in Utilities. As an alternative to this, one could use the Sata.dylib module that is provided by the bootloader.
  • Fixed permissions setting of installed kexts so that permissions repair doesn't complain. Permissions of kexts have become rather picky. It's no longer chmod 755 all the way through, but 644 applied to specific files.
  • The script will now work in the OS install environment if its folder has been renamed on the boot disk installer. This took a couple hours of rework. LOL.
  • Improved kext cache build error detection.
  • Added cp -p command-line option for RAID copies, so that all RAID files have same modification times. This will ensure to user that all copied files on each helper partitions are the same.
  • Updated ASL Optimizing Compiler (iasl) with version Dec 29 2012.
  • Made a number of changes to the DSDT script, as the new compiler adds lots of extra comments to the code, causing parsing issues.
  • Added 11 new bootloader keys for the Plist editor.
(All previous updates are included in script's change log.)

SCRIPT TO-DO LIST:
  • Add Clover boot manager install option.
  • Add a feature to highlight the main menu options that are currently required to complete or fix install process.
  • Add support for multiple graphics cards and dual GPU cards.
  • Add ability to modify EFI string parameters, like RAM, NVCAP, and card name.
HELPFUL LINKS:kind regards,
MAJ


#2
darkenedreality

darkenedreality

    InsanelyMac Protégé

  • Members
  • Pip
  • 32 posts
Wow that was quick! Nice work DD and many thanks! I'm trying it out right now. I'll let you know how it goes........

#3
Mozgovvert

Mozgovvert

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 4 posts
  • Gender:Male
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 :<

#4
darkenedreality

darkenedreality

    InsanelyMac Protégé

  • Members
  • Pip
  • 32 posts
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.......

#5
rappinkapc

rappinkapc

    InsanelyMac Protégé

  • Members
  • Pip
  • 15 posts
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?

#6
duomaxw

duomaxw

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts

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.

#7
darkenedreality

darkenedreality

    InsanelyMac Protégé

  • Members
  • Pip
  • 32 posts
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.

#8
vintageawv

vintageawv

    InsanelyMac Protégé

  • Members
  • Pip
  • 26 posts
DD,

Script worked perfect. Used /Extras with RC3. Also finally got my Quadro FX 580 card working thanks to aquamacs guides.

Success!

You guys rock.

A

#9
mattrb4

mattrb4

    InsanelyMac Protégé

  • Members
  • PipPip
  • 55 posts
DD, your the best.

#10
taylorutah

taylorutah

    InsanelyMac Protégé

  • Members
  • PipPip
  • 60 posts
  • Gender:Male
  • Location:Salt Lake City, Utah
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?

#11
matinee

matinee

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 3 posts
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.

#12
eggfoam

eggfoam

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 3 posts
  • Location:Oakland, California
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

#13
digital_dreamer

digital_dreamer

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,077 posts
  • Gender:Male
  • Location:Missouri USA

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.

#14
digital_dreamer

digital_dreamer

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,077 posts
  • Gender:Male
  • Location:Missouri USA

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

#15
proengin

proengin

    InsanelyMac Protégé

  • Members
  • Pip
  • 13 posts
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.

#16
digital_dreamer

digital_dreamer

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,077 posts
  • Gender:Male
  • Location:Missouri USA

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. :)

#17
knightprozac

knightprozac

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 108 posts
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.

Attached Files



#18
eggfoam

eggfoam

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 3 posts
  • Location:Oakland, California

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.insanelym...howtopic=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

#19
Nargilem

Nargilem

    InsanelyMac Protégé

  • Members
  • PipPip
  • 60 posts
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.

#20
star-affinity

star-affinity

    InsanelyMac Protégé

  • Members
  • PipPip
  • 67 posts
Many thanks to DD for the new script for Snow Leopard! :D
Will try to install it this weekend.

One question: will sleep work?





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy