USING THE X58 MOBO PATCH INSTALLER
TO INSTALL SNOW LEOPARD ON
X58 (Core i7) MOTHERBOARDS:
TO INSTALL SNOW LEOPARD ON
X58 (Core i7) MOTHERBOARDS:
A continuation of our OS X tutorial for
the Gigabyte GA-EX58-UD5 motherboard, which can be adapted
to running Snow Leopard on other modern boards.
the Gigabyte GA-EX58-UD5 motherboard, which can be adapted
to running Snow Leopard on other modern boards.
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/Stored_Kexts, 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:
 Choose from two install methods: Standard /Extra install or EFI boot install 
 Choose from 3 different bootloaders: PC-EFI v10.3, Chameleon v2.0 RC3 or Chameleon v1.012 
 Set partition as active  Auto OS X DVD installer  Install modified kexts/kernels  Update boot caches 
 Easily change kext install destination (/Extra or /System) in a couple keystrokes  Drag 'n Drop kext install fully supported 
 Run DSDT patcher with CMOS reset fix  Modify Mac model name  Modify processor info  Modify "About This Mac" graphics 
 Full EFI strings support: Create strings from Audio, Ethernet and Graphics devices (over 150 graphics cards) 
 Automatic parsing and naming of each device in string for easy verification 
 Import/append/remove individual devices in string  Automatic checks for valid device trees and corrupted EFI strings 
 Select various bootloader themes  Choose from a selection of 27 boot pictures 
 Powerful plist editor that allows you to edit any boot.plist or smbios.plist in various locations 
 Plist editor allows you to select from a list of useful keys, create a custom key, or modify kernel flags 
 Automatically add a UUID as "boot-uuid" key or kernel flag from any of your installed drives 
 Choose from 3 different bootloaders: PC-EFI v10.3, Chameleon v2.0 RC3 or Chameleon v1.012 
 Set partition as active  Auto OS X DVD installer  Install modified kexts/kernels  Update boot caches 
 Easily change kext install destination (/Extra or /System) in a couple keystrokes  Drag 'n Drop kext install fully supported 
 Run DSDT patcher with CMOS reset fix  Modify Mac model name  Modify processor info  Modify "About This Mac" graphics 
 Full EFI strings support: Create strings from Audio, Ethernet and Graphics devices (over 150 graphics cards) 
 Automatic parsing and naming of each device in string for easy verification 
 Import/append/remove individual devices in string  Automatic checks for valid device trees and corrupted EFI strings 
 Select various bootloader themes  Choose from a selection of 27 boot pictures 
 Powerful plist editor that allows you to edit any boot.plist or smbios.plist in various locations 
 Plist editor allows you to select from a list of useful keys, create a custom key, or modify kernel flags 
 Automatically add a UUID as "boot-uuid" key or kernel flag from any of your installed drives 
SCRIPT UPDATE:
UPDATE: 9/25/2009
- Includes PC-EFI 10.3 bootloader update.
- Includes new fakesmc.kext v2.0
- Added ability to set visible Unix files as invisible after OS install, if installing from Leopard.
- Changed exit routine when modifing plists.
- Improved EFI partition setup. Discarded EFI partitions are now erased as "free space," so they no longer have the tendency to automount.
- Devised a method to keep 'buildcache' script current with updates. No longer need to issue 'mount' command in Single-user mode, just type 'buildcache' and it'll be done for you.
- Stopped EFI partitions from showing up in drive selection (they have become HFS partitions, also).
- Added some boot cache options:
- 1. Normal cache build (separate caches): Build boot caches from /Extra & /System separately.
- 2. Combo cache in /Extra: Build a single boot cache from /Extra & /System for /Extra.
- 3. Super combo cache in /Extra: Build large cache from /Extra & /System for /Extra. Build includes more than just what's typically included for boot. Can improve boot times. This has taken 5 seconds off my boot times. YMMV, however.
- Revamped platform/hardware UUID setup:
- UUID injector kexts (UUID.kext or PlatformUUID.kext) are synced with UUID string in smbios.plist, if present.
- This will make it easy to update your UUID injectors – keep the SMUUID string current in smbios.plist
- However, if no UUID is present in the smbios.plist, any UUID string present in the injectors is left as is.
- If you wish to have a new UUID generated, you have two options:
- 1. Use the script to generate a new UUID for the smbios.plist (SMUUID key). This UUID string will be copied to injectors.
- 2. Or, remove any UUID strings from injectors (do not remove key and string tags!) and smbios.plist. Script will generate a new one.
- NOTE: This script is released without the UUID string present in the kext or smbios.plist. This will allow one of two things to happen: User can add his UUID to the smbios.plist via script (or manually), which will be synced to kexts, or a new and unique UUID will be generated and inserted by script if user doesn't add one. In the latter case, the UUID will get copied to kext in the script folder and smbios.plist, so that a new UUID isn't generated every time a kext gets installed. This method will prevent a different UUID from being introduced into the system should the user replace his existing PlatformUUID.kext with another one from who-knows-where, or if the user deletes the SMBIOS key/string from the smbios.plist. In any situation, you can choose to ignore it and it'll be taken care of for you or you add it yourself and it'll preserve it.
- Partial RAID support: Can detect RAID drives, but no further support exists, yet. Useless, I know, but we're getting there.
- Added new keys introduced by Chameleon 2.0 RC3
DOWNLOADS:
Gigabyte GA-EX58-UD5 motherboard kexts for Snow Leopard
(10.7MB) - includes Modbin Kernel.432 (Snow Leopard replacement for AMD/Older Intel CPUs.)
X58 Mobo Patch Installer UPDATED! - 9/27/2009 v4.10
(29.3MB) - includes includes Modbin_Kernel.432 (Snow Leopard replacement for AMD/Older Intel CPUs.)
Selection of 27 boot pictures EXTRA
(26.6MB) - for use with the X58 Mobo Patch Installer.
All that's really needed to boot into OS X on this board is a disabler (i.e. Disabler.kext or NullCPUPowerManagement.kext.) and a decryptor (i.e. dsmos.kext or, possibly, fakesmc.kext). That's it. Everything else are little fixes for hardware reporting, updated device IDs, audio, network, etc. In my case, I also needed the ATY_init.kext for ATI graphic card support, as without it I just got video corruption and couldn't see the desktop.
USING THE SCRIPT:
INSTALLING OS X SNOW LEOPARD RETAIL DVD AND BOOTLOADER:
The download includes the Chameleon v2.0 RC3, PC-EFI v10.3, and v1012 bootloaders, a large assortment of kexts, a variety of kernels (for those still on Mac OS X 10.5.6 or non-Intel systems), and Kext/Kernel Installer script.
PREPARATION
- It is ideal to have two physical drives (not two partitions on the same drive) or, at least, another Mac system to work from.
- One drive must already have OS X installed and running.
This may mean using another Mac or installing a easy-to-use distro like Kalyway on the smaller/slower drive. (I only mention Kalyway, because it is the only distro I'm familiar with and know works well with this board. There are certainly more recent distros that can achieve equal success.) - Partition your target drive in Disk Utility using the GUID Partition Table (in Options button).
- Make an ISO of your Retail DVD and download the Combo update, if needed.
(The ISO of your DVD is not really neccessary, but it will shorten your install times dramatically. Trust me, when things go wrong (and they will) and you have to do an emergency install, more time spent waiting is directly proportional to higher blood pressure.
)
INSTALLATION
- Double-click RUN-PATCH_INSTALLER and enter your password.
- Select from the list of valid HFS drives to work with. (Confirmed target drive name and install type (Extra or EFI) is saved for future use.)
- Select the type of install (Extra or EFI). Default choices are highlighted in bold type.
- Install your choice of bootloader (option #2). For Snow Leopard, use either Chameleon 2.0 RC3 or PC-EFI_v10.3. Observe the note in step #8, as it may affect your choice of bootloader.
- An option is provided to set target partition as active (option #3 in Extra mode). This option is only available for the Extra install type, in case one has more than one OS X install on a drive and would like to set one particular partition as active. (The EFI partition is set active automatically and this process is mandatory.)
- The script will check for the presence of a mounted "Mac OS X Install DVD" (or ISO) and prompt you if you wish to run that installer (option #3 (EFI), or #4 (Extra)). Install from your Retail DVD.
NOTE: If you're installing from Leopard, you'll need to go into the Customize panel and turn off the optional installs, as they may create a "Install Failed" error otherwise. - Run the kext/kernel installer (option #4 (EFI), or #5 (Extra)). This is preconfigured to install the required kexts for the Gigabyte EX58-UD5 motherboard (including the ATY_Init.kext (ATI graphics card injector), which you may not need), or any motherboard with the same chipsets, with audio being a likely exception. The kext/kernel installer automatically updates the boot caches for you.
If installing from Leopard for Snow Leopard, the script will automatically install all x86_64 (64-bit) kexts in /System, as 64-bit boot caches cannot be built into Leopard. Also, note too, that in Snow Leopard some i386 kexts (32-bit) just do not work in /Extra and must be installed into /System. These include current the selection of audio and networking kexts, so toggle them from the /Extra destination to /System by keying in their number and pressing 'Enter.' (i.e. press 4, Enter, 5, Enter, 7, Enter)
If installing for Snow Leopard, the script will automatically select the "Kexts_10.6" folder in the script directory. Likewise, if installing for Leopard, the script uses the kexts in "Kexts_10.5". - Run the DSDT patcher (option #7) ONLY on the system it's intended for and the patched DSDT file will be installed in the appropriate location.
The DSDT file is automatically copied to the appropriate location and includes the CMOS reset fix for Snow Leopard users.
NOTE: If you are unable to create a DSDT patch for your target system, because you are using a different Mac, you should use the PC-EFI v10.3 bootloader, as it will not allow the boot process to stall as a result of a missing DSDT file. - For those installing Snow Leopard, I would suggest turning off Spotlight in your current system by opening System Preferences/Spotlight/Privacy and dragging your Snow Leopard volume to the window. This should disable Spotlight indexing for Snow Leopard when you first boot into it, a major cause of 'mdworker' kernel panics when first starting. Your other option is to disable it when you boot into it, but you have limited time and we'll get to that later.
- Some using older ATI graphics cards, like the 2600XT or 3000 series, will have to delete the ATI-related kexts in /System/Library/Extensions, otherwise you will experience graphics corruption. For the ATI 2600XT, you would need to delete the ATIRadeonX2000.kext
- Your system is ready for rebooting!
BOOTING
- Reboot and enter -v -x32 at the boot prompt. If you are using the Chameleon 2.0 RC3 bootloader, you'll need to use the arch=i386 flag, instead of -x32.
Most bootloaders will attempt to boot the 64-bit kernel by default, but I would suggest you boot in 32-bit mode first, as most kexts work in that mode. The kernel flags in the boot plist are already set for verbose (-v) and 32-bit mode (-x32), but I may suggest using these flags at this point in the boot process anyway, in case such flags were removed from the boot plist or the bootloader chooses to ignore the boot plist in your setup. If you have determined that such flags are, indeed, being used in the boot plist and the boot plist is not being ignored by the bootloader, then you may proceed without entering them at the prompt.- RECOMMENDED PROCEDURE FOR SNOW LEOPARD:
(If you follow these steps here, you can avoid all of the Post-Installation steps! Additionally, some graphics-related kexts require inclusion in the boot cache, otherwise you may experience a black screen or corrupted video on boot.)
If you are booting into Snow Leopard for the first time from Leopard (or any time you have updated the kexts for Snow Leopard from a Leopard install), enter Single-User mode with the -s flag at the boot prompt. After a bit of scrolling logs, you will reach the command prompt.
Type: buildcache followed by the return key. (No need to mount the volume with read/write access, as the script will do this.) This will execute a shell script to build the boot cache for the Extra or EFI directory, plus the /System/Caches/.../Startup directory.
When script finishes, type reboot followed by the return key.
(If, on occasion, the system log continues writing while you are typing, just ignore it and continue typing as if it didn't happen or you can hit "Enter" and try again.)
POST_INSTALLATION
(The following assumes you are booting from Leopard and not another Snow Leopard install.)
- DISABLE SPOTLIGHT: If Spotlight had not been disabled previously and the boot caches were not built in Single-User mode (as discribed above):
You should immediately disable Spotlight before it finishes indexing, otherwise you will experience a 'mdworker' kernel panic.
Type the following in Terminal to disable Spotlight for all volumes:CODEsudo mdutil -a -i off
Or, drag the startup volume to the System Preferences window in System Preferences/Spotlight/Privacy. - BUILD CACHES: If boot caches were not built in Single-User mode (as discribed above): Run Update boot caches in script and Reboot.
(If boot caches were't built prior to this time, it's only a matter of time before you will get another 'random' kernel panic, so work quickly.) - AFTER REBOOT: Now you can relax and move at your own pace.
If you had previously disabled Spotlight by means of the Terminal, you can now enable it for all volumes:CODEsudo mdutil -a -i on
POST_INSTALLATION EXTRAS
- IMPORTANT UPDATE: You won't be able to repair permissions (should you ever need to), until you re-run the BSD installer in Snow Leopard to add the installer packages needed to repair permissions. (This can be done even after the 10.6.1 update.)
Mount DVD (or ISO). Paste the following in a new Terminal window and hit "Enter":CODEsudo open "/Volumes/Mac OS X Install DVD/System/Installation/Packages/BSD.pkg" - MOVE KEXTS TO /EXTRA AND REBUILD CACHES: Many of the kexts can remain in /System. However, that defeats the value of having a vanilla install. The following are the kexts I know will work in /Extra:
Run kext/kernel installer and toggle (key in the kext's corresponding number) all the kexts in Misc. Patches and one ATA kext back to /Extra:
AppleIntelPIIXATA.kext (Type 1, Enter)
dsmos.kext (Type 8, Enter)
NullCPUPowerManagement.kext (Type 9, Enter)
OpenHaltRestart.kext (Type 10, Enter)
PlatformUUID.kext (Type 11, Enter)
Sleepenabler.kext (Type 12, Enter)
Press "Enter" and reboot. - Install any updates for your system.
- After booting into your system, you have the option to change your Mac model name, CPU type, custom About This Mac graphic, as well as custom boot picture, bootloader theme, and boot plist.
- The script's folders has basically 5 categories for the kexts - ATA, Audio, Graphics, Networking, and Misc. Patches. There is a _repository folder in each to store your collection of files. Kexts outside this _repository folder will get installed by the Kext/Kernel Installer. Likewise, the same true for kernels moved outside their parent folder.
- After your initial install, you can continue to use the script folders (ATA, Audio, Graphics, Networking, and Misc. Patches) to install kexts or you can simply drag and drop kexts in the /Extra/Store_Kexts (and _For_System folder, if included) and run the script's Update boot caches.
- The included _For_System folder inside /Extra/Stored_Kexts is installed by default and kexts that get copied to it will get installed to /System when you Update boot caches. If you delete kexts from _For_System or transfer them to /Stored_Kexts, they will get uninstalled from /System after updating boot caches. Basically, if the _For_System folder is present, the contents of /System will stay in sync with the contents of _For_System. This method is an easy way to keep track of patched kexts that have been installed into /System.
If, however, you decide not to use the _For_System folder, you can simply delete it and 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. - The script is pretty much fool-proof, so if anything goes wrong, it should inform you gracefully.
- If you have any questions or issues, please post to this thread.
Script features:

smbios.plist contents:
If using the Chameleon 2 bootloader, this picture shows just what to include in the smbios.plist for best results.

Current Integrated Peripherals settings in the BIOS:

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. - 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
- Where is the EFI string feature in the script?
Select Modify plists, then the boot plist you wish to modify. EFI strings are contained in the device-properties string of the plist. If the current plist doesn't have one, add it by entering in "a" (for "add") from the keyboard and select device-properties from the list (typically at the bottom). - 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. Other matters may include the choice of modified kernel, use of EFI strings, and device-specific DSDT patching, all of which the script supports. - Would the script support my RAID set (softRAID or AppleRAID) on my system? (There is no support for hardware RAID in Mac OS X, other than Apple's own offerings.)
Not at this time. Given that I don't have a RAID setup, it's hard for me to build in support for it in the script. If someone has such a setup and would like support, send my way the files produced by the following Terminal commands from your system:
diskutil list > ~/Desktop/disk_list.txt
diskutil listRAID > ~/Desktop/RAID_list.txt
If you have more than one RAID set, that would be even better, as the produced files would enable me to figure out how to support more than one RAID set. - 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:- 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.)
- On multi-partitioned drives, bootloader doesn't appear to load the boot.plist in the EFI partition (in my experience with PC-EFI v10.3), thus causing some unpredicable behavior, if you system depends on special boot.plist flags. The current workaround is to only use one-partition setups or key in the flags at boot time.
- The Finder doesn't always allow you to view the EFI partition. This appears to be more of a issue in Leopard, as I haven't experienced it in Snow Leopard, yet. In fact, in some cases where you're not able to view the EFI partition from the Finder in Leopard, booting into Snow Leopard and viewing it there will fix the issue, even allowing you to view it after booting back into Leopard.
I'm using the EFI boot method, but when I boot into Single-User mode and try 'buildcache' it says, "/Volumes/EFI: No such file or directory" Why is this not working?Fixed. Found a better work-around.
For some reason the 'buildcache' script didn't get the correct disk ID of your EFI partition. Try to run the Kext/kernel installer for that EFI partition again, but cancel out ("n"), if you need to. This will update the ID.
Each time you enter the Kext/kernel installer, the script will check the disk ID of EFI partition you are working on and pass that info to the 'buildcache' script, if it needs to be updated. That way, when you execute the 'buildcache' script in Single-User mode, it will know which EFI partition to work on. If, however, you add or remove a hard drive, flash drive, etc., this ID will change, thus affecting the operation of the 'buildcache' script. The solution is to have this ID updated by entering the Kext/kernel installer routine. You can then cancel the install by entering "n", if desired.- 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 Update Boot Caches step is for when you add, delete, or move kexts 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 suppport 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, 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 acheivement; 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 bit by bit.
SCRIPT CHANGE LOG:
UPDATE: 9/9/2009
- Minor update to fix running software version check.
UPDATE: 9/7/2009
- Major update to v4.01 - rewritten for Snow Leopard, but fully compatible with Leopard.
- Now featuring EFI boot install setup.
- Built-in target OS detection can automatically switch between 10.5 and 10.6 kexts when installing.
- Added Alias shell script to build kext cache for SL in Single-User mode, if needed. The 'buildcache' command builds the cache for the Extra, EFI, and /System/Caches/.../Startup directories.
- After each install, all UUID injectors are updated with proper UUIDs (includes UUID.kext, PlatformUUID.kext, and smbios.plist).
- Multi-device EFI strings support. Automatically parses EFI strings and names each device. Can add/remove devices within strings. Support for >150 graphics cards, LAN string, and (in progress) HDA strings. (Sorry, no dual graphics card support, yet.)
SCRIPT TO-DO LIST:
- Add USB boot drive setup.
- Full RAID support.
- Add selection of DSDT fixes.
- Add ability to increase version numbers in kexts for loading priority.
- Add symbolic link for modified kernels in root directory
- Add selector for list of kernel flags.
- Clean up log.
HELPFUL LINKS:
Â¥ Marcel Bresink's Temperature Monitor
Â¥ Great Internet Mersenne Prime Search (GIMPS) - Prime95 CPU torture test in OS X binaries.
Â¥ Great Internet Mersenne Prime Search forum
Â¥ Gigabyte GA-EX58-UD5 product page
Â¥ Gigabyte X58 BIOS Features
Â¥ Virtual BIOS
Â¥ TweakTown: Gigabyte Technical Support Forum
Â¥ BIOS F4 binary update
Â¥ BIOS F5 binary update
Â¥ BIOS F6 binary update
Â¥ BIOS F7 binary update
Â¥ BIOS F8 binary update
kind regards,
MAJ
