[GUIDE] Scripted Yosemite/Mavericks Install on Gigabyte Mobos

[Dith]

I just finished loading SL on my X58-UD3R board using DD's script. The only kext change was to use IOFamily networking in S/L/E. I use an EFI string for the Nvidia 9500GT. I have found no audio kexts that will work - using a USB audio card for now.

 

I started with a working 10.5.7 install and added two HDs. I loaded 10.6 to HD1 while booted in 10.5.7. I then booted into 10.6 on HD1 and loaded 10.6 on HD2. On HD1 the 'hidden' files were visible, on HD2 they were truly hidden. I then reformatted HD1 and loaded 10.6 whole booted into HD2. I then updated both installs to 10.6.1.

You can get audio working using DSDT. See tutorial.

 

 

Hej Dith,

 

I moved the files to the -extra folder and run the script from the there (double clicking the executable (bonjourfix). I get this in termin.

 

/Special/X58_Mobo_Patch_Installer\ SL/\~extra/Bonjour/BonjourFix/BonjourFix ; exit;

/Special/X58_Mobo_Patch_Installer SL/~extra/Bonjour/BonjourFix/BonjourFix: line 23: $1: unbound variable

logout

 

what does it mean?

 

Thanx

 

You're using the wrong post. I actually meant this for DD to consider for his script.

Use these instructions.

[digital_dreamer]

I would call it a hassle, not a problem. Blackosx method requires you to build your own dsdt.aml from within windows or a windows emulator, then use a second tool to edit the dsdt for the CMOS reset. I suppose you only have to do this once per board, it stays the same across 10.5 and 10.6. He uses a tool from koalala. Its actually kind of interesting. But there are many steps to building it and it seems error prone.

 

I'm curious why Blackosx goes through this complex process by hand, versus DD here just embedding the invocation of an automatic tool in his script. Also curious if our DD script is using netkas' fakeSMC v2.

I don't know about "automatic tool," but the CMOS reset fix is actually scripted in by yours truly.

And, it's actually very simple. The basic portion that does the actual change of the "0x04" or "0x08" to "0x02" is here:

RTC_LINES=`echo "$RTC_LINES" | sed -e '/Length/s/0x04/0x02/g' -e '/Length/s/0x08/0x02/g'`

After the "Device (RTC)" scope (the portion that contains the error) had been extracted, this sed command line looks for any line that contains "Length" and replaces "0x04" with "0x02", or any line that contains "Length" and replaces "0x08" with "0x02".

 

The script also provides the feedback of changes to the log and removes the "IRQNoFlags" lines, if present.

Here's the full portion with added documentation:

(I separated the commands to make it easier to read.)

#### Add CMOS reset and KP fix
echo -e "\nPeforming CMOS reset fix..."
cd "$SCRPT_PTH/~extra/DSDT_Patcher"

# Grab entire dsdt text
ALL_LINES=`sed -e :a -e '/^\n*$/{$d;N;ba' -e '}' Debug/dsdt_fixed.txt`

# Extract everything from beginning to start of Device (RTC)
BEGIN_LINES=`echo "$ALL_LINES" | sed -n '/^\/\*$/,/Device (RTC/p'`

# Extract everything from end of Device (RTC) scope down to end of file
END_LINES=`echo "$ALL_LINES" | sed -n '/Device (SPKR/,/*$/p'`

# Extract just the Device (RTC) scope
RTC_LINES=`echo "$ALL_LINES" | sed -n '/Device (RTC/,/^$/p'`

# Dump to log the unedited version
echo -e "\nAttempting change of RTC length variables.\nRTC lines before edit:\n$RTC_LINES">> "$DSDT_LOG"

# Change variable length from 04 or 08 to 02
RTC_LINES=`echo "$RTC_LINES" | sed -e '/Length/s/0x04/0x02/g' -e '/Length/s/0x08/0x02/g'`

# Dump to log this change
echo -e "\nRTC lines after edit:\n$RTC_LINES">> "$DSDT_LOG"

# Remove the line containing IRQNoFlags, plus the following line
RTC_LINES=`echo "$RTC_LINES" | sed '/IRQNoFlags/,/}/d'`

# Dump to log this change
echo -e "\nRTC lines after \"IRQNoFlags\" removal:\n$RTC_LINES">> "$DSDT_LOG"

# Delete the first line in preparation of joining fixed lines
RTC_LINES=`echo "$RTC_LINES" | sed '1,1d'`

# Join together the first portion, plus RTC fix, plus the ending portion of the dsdt file
FIXED_LINES="$BEGIN_LINES
$RTC_LINES

$END_LINES"

# Save changes to file
echo "$FIXED_LINES">"Debug/dsdt_fixed.txt"

 

Yes, the fakeSMC v2 is included, but the update is not uploaded. I have the script all apart to make changes/fixes. I made a lot of changes to it while at work and emailed the changes back to me. However, the email never made it. :-(

So, I'm working on other portions of the script and will append those changes to the one made at work when I get back there next week.

 

regards,

MAJ

[rb3000]

Has anyone got a hardware Raid 0 to work with snow leopard? I currently have two disks I run in Raid 0 and 4 that I run in raid 10 on my ICH10R.

 

I found this post:

http://digitaldj.net/2009/09/05/ich10r-in-...leopard-part-2/

 

But then he says, "You might even be able to install Snow Leopard to a HARDWARE RAID volume...but I haven't tested this yet."

 

So it sounds like he can get os x to recognize a hard ware raid volume? Has anyone else reported this success or been able to install directly to a hardware raid 0?

 

Thanks!

 

I have a Highpoint 2640x4 which is a x4 PCIe SAS/SATA HBA. I have 2 300GB 15k SAS drives as a RAID0 boot volume. The way I set up my system was:

 

Get Leopard running on a SATA drive on the motherboard SATA.

Load the Highpoint driver, partition the SAS RAID volume & format it.

Use CCC to clone my SATA installation to the RAID volume.

Use DD's script to install the Cham. boot loader.

Reboot into smokin' fast SAS RAID!

 

I paid ~$150 for the card, but newegg has them now for ~$80. Get one of these, it's well worth it, does RAID 0/1/5/10/JBOD/single disks, and Snow Leopard has the driver built in. Comes w/4 SAS cables that work also w/SATA drives, or you can use regular SATA cables w/SATA drives.

 

Highpoint 2640X4 4-port SAS/SATA HBA at Newegg

 

There is also an 8-port version for $145 (you'll need 2 sets of cables; $25 each at newegg)

 

Highpoint 2680X4 8-port SAS/SATA HBA at Newegg

 

Then, if you want true hardware RAID (0/1/5/10/50/JBOD/single disks) w/cache, there's the HP 4320 for $299. It has an Intel IOP348 1.2 ghz RAID engine, 256MB onboard cache, and you can add a battery backup for the cache. I have one of these coming this monday, so I can report back if you're interested.

 

Highpoint 4320 8-port SAS/SATA RAID x8 PCIe at Newegg

 

 

I'm not affiliated in any way w/Newegg or Highpoint, I'm just a satisfied customer. This 2640X4 has worked flawlessly in my system for months using 10.5.7 & .8, and I have installed 10.6.1 last night to a SATA drive. If it works out for me as smoothly as 10.5 has, I will migrate the RAID in a few weeks as my boot volume. As it is, it works fine as a data drive in Snow Leo, I just need to know if Snow Leo works with my many apps, as I have a perfectly functioning system and need it to stay that way.

[colddiver]

I'm back and this is my first post to the new thread. Thank you MAJ. The new script is fantastic. I'm using Chameleon 2 RC3 for both Leopard and Snow Leopard (32-bit for now) on separate drives using the EFI partition. Simply amazing. I cannot thank you enough.

 

There is one small problem with the script however. When you up update the boot caches you update UUID.kext (or PlatformUUID.kext) with the UUID of the boot drive which is actually incorrect. In fact these are different.

 

The boot UUID in com.apple.boot.plist is the UUID of the drive partition that you would like the bootloader to boot. Every partition has its own own UUID and is created when the drive is partitioned.

 

The UUID is those kexts is your hardware UUID and should never change. You can see it in System profiler in the hardware tab. It also appears in /Volumes/YOURDRIVENAME/Users/YOURUSERNAME/Library/Preferences/ByHost/ in the name of the files. This is how a lot of software authorization happens.

 

Regardless of whether or not I boot Leopard or SL (which have different boot-uuid's), my hardware UUID is the same. That way any migrated software that is authorized to run on one partition will continue to run on the other partition. I hope that was a clear enough explanation.

 

Anyway, this really isn't your fault. It's a very common misconception. I only figured it out through some serious trial and error plus dumb luck. I look forward to a fixed version. Your hard work has made this easy for me and lots of other people.

 

Hello,

 

I believe the UUID things needs to be seriously looked at and well understood. It appears that changing the SMUUID in smbios will cause iTunes to no longer recognize an already authorized PC (a re-authorization will have to be done again, using up one of the 5 machines allowed). I suspect other softwares with activations schemes may experience related issues if the SMUUID changes.

 

Looking at my ByHost preferences, I can now see that 4 different SMUUID values have been used (I never changed mine manually). I never understood, until now, why some software (such as Aperture, iTunes, etc.) would apparently lose their licenses or activations (or Time Machine telling that a previous backup of this machine was done using another computer). This messing around with the SMUUID appears to be the cause... I now have to play around with various SMUUID to attempt to deauthorize several iterations of my hackintosh on the iTunes Music Store... Not pleasant!

 

DigitalDreamer: would highly recommend that you modify your script to avoid updating these values without the user knowing.

 

Colddiver

[ryansimms]

I now have to play around with various SMUUID to attempt to deauthorize several iterations of my hackintosh on the iTunes Music Store... Not pleasant!

 

Colddiver

 

Until the SMUUID issue is resolved you may want to check out this article on Apple's support pages. If you reach 5 authorizations and don't have access to the machines, you can reset all of the authorizations and start over. I don't think the option shows up in your account unless you have reached your 5 authorization limit, and you can only do it once a year, but it may be easier than trying to restore those IDs just to de-authorize them.

 

Ryan

[eetfunk]

I made a little change to the script to let us specify a custom UUID (/Extra/uuid). It doesn't solve the UUID problem but I think it's a change that should be incorporated in the script. It could be useful IMO.

 

Here's the diff.

 

diff --git a/~extra/X58_patch_installer.sh b/~extra/X58_patch_installer.sh
index 44e5f0d..1e619fd 100755
--- a/~extra/X58_patch_installer.sh
+++ b/~extra/X58_patch_installer.sh
@@ -776,7 +776,17 @@ if [ $SYSTEM_FLG == 1 ];then
       fi
fi
MSG=""
-NEW_UUID=`diskutil info "/Volumes/$TARGET_DRIVE_NAME" | grep "Volume UUID:" | awk '{print $3}'`
+
+UUID_PATH="$EXTRA_PTH/uuid"
+if [ -f $UUID_PATH ];then
+       echo -e "Reading UUID from $UUID_PATH." >> "$LOG"
+       NEW_UUID=`cat $UUID_PATH | tr -d '\n '`
+       echo -e "Using UUID $NEW_UUID" >> "$LOG"
+       echo "Using UUID '$NEW_UUID' from $UUID_PATH."
+else
+       NEW_UUID=`diskutil info "/Volumes/$TARGET_DRIVE_NAME" | grep "Volume UUID:" | awk '{print $3}'`
+fi
+
for ((INSTALL=1; INSTALL <= $FILE_CNT ; INSTALL++)); do
       INSTALL_FILE="${FILE_NAME[iNSTALL]}"
       INSTALL_SRC="$SCRPT_PTH/${FILE_ARRAY[iNSTALL]}"

[knightprozac]

Has anyone got a hardware Raid 0 to work with snow leopard? I currently have two disks I run in Raid 0 and 4 that I run in raid 10 on my ICH10R.

 

I found this post:

http://digitaldj.net/2009/09/05/ich10r-in-...leopard-part-2/

I'm highly skeptical of that method working for anything other than letting you boot with the sata controller mode set to RAID. I doubt you'll even be able to access a non-boot ICH10 RAID system on your SL install.

 

That Highpoint 2640X4 RAID card looks like a pretty good deal from newegg. Unfortunately newegg don't do sales for Australia and everyone seems to want to rip us off for those cards over here. The cheapest I could find was about AU$250 which translates to US$215 at the current exchange rate.

[colddiver]

Until the SMUUID issue is resolved you may want to check out this article on Apple's support pages. If you reach 5 authorizations and don't have access to the machines, you can reset all of the authorizations and start over. I don't think the option shows up in your account unless you have reached your 5 authorization limit, and you can only do it once a year, but it may be easier than trying to restore those IDs just to de-authorize them.

 

Ryan

 

Thanks a million for this tip! Much less painful indeed.

 

Colddiver

[luh3417]

I don't know about "automatic tool," but the CMOS reset fix is actually scripted in by yours truly.

Not to put too fine a point on things but, where do you get the dsdt.aml to start with that you apply the CMOS reset fix to? I guess I don't understand why blackosx goes to such a mess of detailed complicated trouble to get the DSDT happy, while the your DD script, you just run one option and you're done. Here is his DSDT guide http://redirectingat.com/?id=292X457&u...p%3Fmmqy2nzmgzd and here is his thread about it. http://www.insanelymac.com/forum/index.php?showtopic=177497 I mean you can spend hours just on DSDT there, while here it takes seconds, what's up with that?

 

Maybe the DD script is easier because its only for one board and all those boards have the same DSDT? But that doesn't make sense, first of all blackosx's primary concern is with one single board too, and second of all you could just ship out the one standard GA-EX58-UD5 dsdt with the script and not even need to run the sed script fix every time.

 

Lastly, wondering what your take is on the above "SL is happier when installed from SL, not when installed from 10.5". I know you do lots of installs, could it be that you are generally always fortuitously installing from SL to SL? Just wondering.

[colddiver]

Well... Looks like I did something stupid! I upgraded to the new fakesmc (v2), to 10.6.1 and to the newest beta BIOS (f9e) all over the weekend. Since I used DD's script to install the kext and update the boot cache, the UUID (see my previous post) was updated as well. I did test the setup (apparently too briefly) on my maintenance drive. My system has been very unstable since (random restart without any warnings, pointing (I think) to a BIOS issue).

 

I unplugged the power cord and it didn't improve stability. I just disabled the XMP1 memory profile and it seems a little bit better. Hopefully, this will do the trick. If you have any suggestions, let me know...

 

Colddiver

[Crypticus]

This is a quick Alternative Installation Guide I wrote using DD's script and a few other source.

 

http://www.projectosx.com/forum/index.php?...entry2539

 

It's a method of install SL from the INSTALL DVD (Kinda) instead of through the OSInstall.mpkg

 

The end result is a little more Mac like I think. Reason being, after using DD's script, there are a lot of permission issue and Disk Utility Doesn't know how to fix them because it appears that OSInstall.mpkg does not write a receipt of it's installed files.

 

I had to post in on ProjectOSX because the stupid forums here kept eating it and it never showed up.

[colddiver]

Well... Looks like I did something stupid! I upgraded to the new fakesmc (v2), to 10.6.1 and to the newest beta BIOS (f9e) all over the weekend. Since I used DD's script to install the kext and update the boot cache, the UUID (see my previous post) was updated as well. I did test the setup (apparently too briefly) on my maintenance drive. My system has been very unstable since (random restart without any warnings, pointing (I think) to a BIOS issue).

 

I unplugged the power cord and it didn't improve stability. I just disabled the XMP1 memory profile and it seems a little bit better. Hopefully, this will do the trick. If you have any suggestions, let me know...

 

Colddiver

 

Looks like the XMP memory profile may have been the culprit. Longest uptime yet (crossing fingers) since I disabled it (memory running at 1066 instead of its rated 1600 though).

 

Colddiver

[zeebeedee]

Maybe this is ridicolous but i've installed SL with DD's script for 5 times. When i booted into system for the first i make "Update boot caches" that described in the Guide. And when i updated i've never ever booted into system second time. I don't know why but i couldn't. (It always stucked at acpiplatformplugin bla bla timed-out) :/

 

My Rig is

ex58-ud3r

i7 920

3 x 1 gb. sticks

Asus 1g Radeon 4870

[mattrb4]

This is a quick Alternative Installation Guide I wrote using DD's script and a few other source.

 

http://www.projectosx.com/forum/index.php?...entry2539

 

It's a method of install SL from the INSTALL DVD (Kinda) instead of through the OSInstall.mpkg

 

The end result is a little more Mac like I think. Reason being, after using DD's script, there are a lot of permission issue and Disk Utility Doesn't know how to fix them because it appears that OSInstall.mpkg does not write a receipt of it's installed files.

 

I had to post in on ProjectOSX because the stupid forums here kept eating it and it never showed up.

 

This guide is inferior because it uses an old DD script. The solution to your permission issues is to reinstall BSD.pkg from the CD at /system/installation/packages/

old Leopard was incapable of installing this pkg installer which caused permission issues.

[LocusOfControl]

Hello,

 

I believe the UUID things needs to be seriously looked at and well understood. It appears that changing the SMUUID in smbios will cause iTunes to no longer recognize an already authorized PC (a re-authorization will have to be done again, using up one of the 5 machines allowed). I suspect other softwares with activations schemes may experience related issues if the SMUUID changes.

 

Looking at my ByHost preferences, I can now see that 4 different SMUUID values have been used (I never changed mine manually). I never understood, until now, why some software (such as Aperture, iTunes, etc.) would apparently lose their licenses or activations (or Time Machine telling that a previous backup of this machine was done using another computer). This messing around with the SMUUID appears to be the cause... I now have to play around with various SMUUID to attempt to deauthorize several iterations of my hackintosh on the iTunes Music Store... Not pleasant!

 

 

Colddiver

 

I had to re-register for itunes on SL when I moved to to SL on a new disk despite keeping the same login info etc.

 

I suspect you are correct re UUID, there is a bug which afflicts real macs that causes the Installer.app to stop working

which I came across. The solution is related to something in ~/Library/Preferences and probably ByHost. The workaround being delete of ByHost or even Preferences and reboot. ByHosts is probably being used for some

verifications (even if the error messages from OS X are totally misleading - ie installer runner not setuid)

 

 

 

Looks like the XMP memory profile may have been the culprit. Longest uptime yet (crossing fingers) since I disabled it (memory running at 1066 instead of its rated 1600 though).

 

Colddiver

 

 

 

 

I've got similar setup to you although I started with fakesmc v2, I updated to bios f9e last week (from the initial f4)

and I haven't had any problems, BUT like you I'm at 1066 since I have 12gb RAM and boot fails with

memory multiplier of 8. I read on tweaktown that for greater than 6gb you need to set the multiplier at 6 for

overclocking (I'm at 3.4Ghz but haven't tried higher)

 

The main gripe for me is the occasional non responsiveness of the apple usb keyboard at the chameleon screen

(this was there in f4 bios). It seems to be a USB issue since the keyboard works if I unplug and replug it.

(I have got legacy keyboard enabled in bios as the keyboard is unresponsive at chameleon without it - legacy mouse

disabled since it helped with mouse jitter in leopard).

 

regards

Steve

[colddiver]

I had to re-register for itunes on SL when I moved to to SL on a new disk despite keeping the same login info etc.

 

I suspect you are correct re UUID, there is a bug which afflicts real macs that causes the Installer.app to stop working

which I came across. The solution is related to something in ~/Library/Preferences and probably ByHost. The workaround being delete of ByHost or even Preferences and reboot. ByHosts is probably being used for some

verifications (even if the error messages from OS X are totally misleading - ie installer runner not setuid)

 

I've got similar setup to you although I started with fakesmc v2, I updated to bios f9e last week (from the initial f4)

and I haven't had any problems, BUT like you I'm at 1066 since I have 12gb RAM and boot fails with

memory multiplier of 8. I read on tweaktown that for greater than 6gb you need to set the multiplier at 6 for

overclocking (I'm at 3.4Ghz but haven't tried higher)

 

The main gripe for me is the occasional non responsiveness of the apple usb keyboard at the chameleon screen

(this was there in f4 bios). It seems to be a USB issue since the keyboard works if I unplug and replug it.

(I have got legacy keyboard enabled in bios as the keyboard is unresponsive at chameleon without it - legacy mouse

disabled since it helped with mouse jitter in leopard).

 

regards

Steve

 

I fixed all my issues. I created a UUID for my machine by using uuidgen in the terminal and adding my ethernet address (as described by FUT1L1TY). I will now ensure that this UUID does not change. I then added this UUID to info.plist located inside the PlatformUUID.kext and into smbios.plist (to be safe). I then rebuilt my boot caches manually (since DD's script attempts to change the UUID at these locations) by doing:

 

chmod -R 755 /Volumes/Snow/Extra/Stored_Kexts/

chown -R root:wheel /Volumes/Snow/Extra/Stored_Kexts/

kextcache -v 4 -t -l -m /Volumes/Snow/Extra/Extensions.mkext /Volumes/Snow/Extra/Stored_Kexts

 

I then deauthorized my machine from iTunes, trashed all my ByHost preferences and rebooted.

 

I also did the exact same thing on my maintenance drive (so that the UUID does not change depending on which OS I boot into).

 

Concerning the instabilities (random restarts) I experienced earlier, these were definitely due to the XMP profile (i.e. running my RAM at 1600 instead of 1066). Everything is rock stable again since I made these changes (and I will no longer run into random licences/authorizations issues since my machine UUID will no longer change).

 

Colddiver

[digital_dreamer]

DigitalDreamer: would highly recommend that you modify your script to avoid updating these values without the user knowing.

 

Colddiver

This is being fixed, but update is not available, yet.

 

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 alone
  
• 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.
    

I've thought long and hard on a solution that will be the most flexible and proper, trying to fit in with everyone's wishes: You can ignore it and it'll be taken care of, or you can add it and it'll preserve it.

 

Again, if you wish to carry over your existing UUID, add it to the smbios.plist and that will be synced to the installed kexts on each install. Or, if you don't want to bother with the smbios.plist, you can simply add it manually to your PlatformUUID.kext (ideally, the one in your script's folders, so that it'll be available on each install) and make sure there isn't one in the smbios.plist. That UUID will be preserved.

 

I know the smbios.plist is supposed to be a injector, too, but the UUID portion doesn't work for everyone, hence the kexts. Additionally, I find editing the UUID in the smbios.plist the easiest and the most visible, compared to digging two levels into the kexts. The install.log will always show the UUID on every install, as well, should you be interested in knowing what it is and it's not being based on the smbios.plist.

 

The injector kexts usually already have a fixed UUID inserted, which will be the same on all systems that don't have it modified - not a great solution, as it's supposed to be unique.

 

I propose to release this script update 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.

 

If this process appears too complicated (welcome to my world and the world of computers, where an endless variety of variables and scenarios can come into play and must be decided on), just add the UUID to the PlatformUUID.kext and be done with it. Just make sure if you ever copy another PlatformUUID.kext from somewhere else, it's going to have the same UUID. Most people don't care to look.

 

Sorry that this has been an issue, due to a misunderstanding on my part. I realize that each time one attempts to change the UUID now, the script will change it back on a install or update. It'll be released by midweek.

 

EDIT: If you want to know what the previous UUID was that your system was using prior to it be changed, it's usually the apple-installed software in the Preferences/ByHost folder, like iCal, AddressBook, iTunes, Mail, etc.

 

Not to put too fine a point on things but, where do you get the dsdt.aml to start with that you apply the CMOS reset fix to? I guess I don't understand why blackosx goes to such a mess of detailed complicated trouble to get the DSDT happy, while the your DD script, you just run one option and you're done. Here is his DSDT guide http://redirectingat.com/?id=292X457&u...p%3Fmmqy2nzmgzd and here is his thread about it. http://www.insanelymac.com/forum/index.php?showtopic=177497 I mean you can spend hours just on DSDT there, while here it takes seconds, what's up with that?

 

Maybe the DD script is easier because its only for one board and all those boards have the same DSDT? But that doesn't make sense, first of all blackosx's primary concern is with one single board too, and second of all you could just ship out the one standard GA-EX58-UD5 dsdt with the script and not even need to run the sed script fix every time.

 

Lastly, wondering what your take is on the above "SL is happier when installed from SL, not when installed from 10.5". I know you do lots of installs, could it be that you are generally always fortuitously installing from SL to SL? Just wondering.

The difference is that he is editing the file by hand, manually. I spent the time to script a solution after having edited it by hand to form a solution. I did the hard work already with the user benefiting from a fast solution. Not everyone is going to script or code a solution, it's just not their thing. But, I find this the perfect task to script for and is just what computers do best.

This solution should work for all boards, if they have the same scope "Device (RTC)". It'll break if the scope is slightly different, say "Device (_RTC)" or "Device (/RTC)". I don't know exactly what the code looks like on other boards, so I'm taking a chance that it may work.

 

The "SL is happier when installed from SL, not when installed from 10.5" comment is certainly true, which is why one has to resort to building caches in Single-User mode or installing x86_64 kexts in /System, have Unix files that don't get hidden automatically unless fixed in SL, and have file permissions repair broken unless fixed in SL.

 

Part of the reason for this is that we are trying to install from Leo and the only way to do that is to bypass the main installer application (which would force you to reboot into SL on the DVD which will not run on our Macs), and run one of the embedded installers, OSInstall.mpkg. Doing so skips the BSD.pkg install and other scripts, like hide Unix files.

 

For the last two months, I've installed SL from Leo many dozens of times. It's only been in the last 3 days I've setup a second SL install. Things are, indeed, much easier when using it as a maintenance drive, instead of Leo. The best install method is the USB install, where the SL ISO and bootloader is installed and booted into. In this case, one is installing from SL to SL, an ideal situation. I'm trying to incorporate this technique (Thanks, Proengin!) in the script as an option. This technique has been alluded to several times in this thread. It would simplify the installation process.

 

regards,

MAJ

[ZarathustraKael]

Hi, MAJ

 

Thanks for your hard work!

 

PC EFI v10.3 is out by netkas, can someone comfirm it workingin in our mobos? If installed 10.2, shall we need some extra work to make it boot SL (change com.apple.boot.plist, delete kexts etc.)?

 

regards,

 

Z.A.

[proengin]

I don't know if anyone has experienced missing USB mouse and keybord at boot and Chameleon boot screen when both are from Apple and the mouse is connected to the keyboard USB port even you have the newer F8x and F9x bios.

 

I thought it was because of overclocking or Bios issues but it wasn't. It can be resolved simply by plugging the Apple mouse and keyboard directly to motherboard USB ports.

[digital_dreamer]

I don't know if anyone has experienced missing USB mouse and keybord at boot and Chameleon boot screen when both are from Apple and the mouse is connected to the keyboard USB port even you have the newer F8x and F9x bios.

 

I thought it was because of overclocking or Bios issues but it wasn't. It can be resolved simply by plugging the Apple mouse and keyboard directly to motherboard USB ports.

Hi, proengin,

Are you talking about the M/K being ignored consistently or at random boots?

 

I have mine connected directly to mobo and on occasion I experience a missing keyboard and must unplug/plug. Odd thing, as I didn't have this issue at all until I installed a ATI 4870x2 a couple days ago (just to get CI/QE goodness! ).

 

regards,

MAJ

[FUT1L1TY]

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 alone
  
• 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.
    

I've thought long and hard on a solution that will be the most flexible and proper, trying to fit in with everyone's wishes: You can ignore it and it'll be taken care of, or you can add it and it'll preserve it.

 

Nice work MAJ. Thank you for a simple (for us that is) solution to a complex issue.

 

PC EFI v10.3 is out by netkas, can someone comfirm it workingin in our mobos? If installed 10.2, shall we need some extra work to make it boot SL (change com.apple.boot.plist, delete kexts etc.)?

 

I'm using it right now without any troubles at all although automatic property injection for nVidia cards still doesn't work for me. Does anyone have a fully working nVidia card without using a kext or EFI string?

[proengin]

Hi, proengin,

Are you talking about the M/K being ignored consistently or at random boots?

 

I have mine connected directly to mobo and on occasion I experience a missing keyboard and must unplug/plug. Odd thing, as I didn't have this issue at all until I installed a ATI 4870x2 a couple days ago (just to get CI/QE goodness! ).

 

regards,

MAJ

Hi MAJ,

 

No, it happened at bios boot screen and hence Chameleon drive selection screen. First I suspected it was the bios but even flashing to the newer F8x and F9x versions didn't help. Then I unplugged the Apple mouse from the Apple keyboard, I got keyboard back. I connected the Apple mouse to the motherboard, I got mouse and keyboard no matter what I did. As soon as I plugged the mouse to keyboard, the symptom came back again.

 

I don't know if this also happens to non-Apple keyboard and mouse combo. I would be interested to hear from anyone who can repeat this problem with the Apple combo.

[LocusOfControl]

Hi MAJ,

 

No, it happened at bios boot screen and hence Chameleon drive selection screen. First I suspected it was the bios but even flashing to the newer F8x and F9x versions didn't help. Then I unplugged the Apple mouse from the Apple keyboard, I got keyboard back. I connected the Apple mouse to the motherboard, I got mouse and keyboard no matter what I did. As soon as I plugged the mouse to keyboard, the symptom came back again.

 

I don't know if this also happens to non-Apple keyboard and mouse combo. I would be interested to hear from anyone who can repeat this problem with the Apple combo.

 

Happens to me as stated before, I get this most cold boots. Unplugging the keyboard works (as does rebooting).

 

I have my logitech mouse plugged into the motherboard (I'll try plugging it into the keyboard next time - I also

have an apple mouse but don't use it often as I'm not keen on the small scroll ball)

 

It seems to happen more often now that I have 2 sata drives with OS X. When I only had 1 drive it didn't happen as

much (is there a usb voltage?). In any case with 1 drive I had the timer on so got auto startup. This doesn't seem

to work with 2 drives even with hd preference set.

 

I also use a 4870 by the way

 

regards

Steve

 

 

PS just tried plugging mouse in keyboard - boots first time. On tweaktown there is a similar issue booting windows.

suggestion is turn legacy storage off

[proengin]

Happens to me as stated before, I get this most cold boots. Unplugging the keyboard works (as does rebooting).

 

I have my logitech mouse plugged into the motherboard (I'll try plugging it into the keyboard next time - I also

have an apple mouse but don't use it often as I'm not keen on the small scroll ball)

 

It seems to happen more often now that I have 2 sata drives with OS X. When I only had 1 drive it didn't happen as

much (is there a usb voltage?). In any case with 1 drive I had the timer on so got auto startup. This doesn't seem

to work with 2 drives even with hd preference set.

 

I also use a 4870 by the way

 

regards

Steve

 

Hi Steve,

 

FYI, this problem occured even my hack always had 2 SATA hard drives and GTX-285 but honestly I didn't observe the difference between 1 and 2 drives. I thought it was a bios issue but turned out I could at least get around it.

 

The loss of usb mouse or keyboard in 10.61 did occur by was at a rate like once every 100 boots. It seemed to happen much less frequently in 10.6x and with newer F8x and F9x bios for Extreme motherboard.

 

 

Did you mean turning the USB storage or USB Legacy mode off?

 

 

Regards,

 

 

 

Patrick

[LocusOfControl]

Did you mean turning the USB storage or USB Legacy mode off?

 

 

Regards,

 

 

 

Patrick

 

Hi Patrick

 

keyboard freeze is (was) quite common for me, before when I only had 1 drive I got the same problem

but the workaround was to set the chameleon timer to 1s (which actually took about 20!!!) so I didn't

have to press anything. This doesn't seem to work with 2 drives attached?

 

I just tried plugging the mouse in the keyboard as suggested and it worked first time from cold boot - fingers

crossed it may be the workaround I need. (at least it's easier to pull the cable out from there than reaching over

to the pc)

 

wrt USB - I read storage - haven't tried it myself but google. I think if you turn legacy mode off all the legacy

usb stuff gets turned off and the keyboard doesn't work in chameleon (apparently they are for dos support or

pre windows which is where I guess chameleon sits)