[GUIDE] Scripted Yosemite/Mavericks Install on Gigabyte Mobos

[BiTRiP]

BiTRiP - please post where in the DSDT need to change it?

Please write what ever altered in DSDT?

 

 

Device (PCI0) { … Name (_UID, One) … }

 

change to

 

Device (PCI0) { … Name (_UID, Zero) … }

[callumj09]

Hmm, I'm having a weird ethernet problem which I think I caused myself. I booted with verbose and another network device was detected on top of what I already had, instead of ignoring/deleting it I deleted both and now I don't seem to have any ethernet at all. I don't think it's even detected... I have tried reinstalling kexts and other things, but it just won't detect it.

 

Can anyone help me on this? Thanks.

[CruiSAr]

Hmm, I'm having a weird ethernet problem which I think I caused myself. I booted with verbose and another network device was detected on top of what I already had, instead of ignoring/deleting it I deleted both and now I don't seem to have any ethernet at all. I don't think it's even detected... I have tried reinstalling kexts and other things, but it just won't detect it.

 

Can anyone help me on this? Thanks.

 

Did u try rebuilding the boot cache after the kext reinstallation? Just a thought, give it a try.

[callumj09]

Did u try rebuilding the boot cache after the kext reinstallation? Just a thought, give it a try.

 

Yeah I did. I installed it using the script so it automatically updates the caches after installing. Thanks for the thought though.

[@ROBASEFR]

Yeah I did. I installed it using the script so it automatically updates the caches after installing. Thanks for the thought though.

 

Like D_D said in post1 it is recommended to do :

 

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: /sbin/mount -uw / followed by the return key. This mounts the startup volume with read/write access.

Type: buildcache followed by the return key. 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.

 

And:

 

GENERAL SYSTEM BEHAVIORMy Ethernet ports are not working. What can I do?

 

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.

 

 

PS There was an error in post 1 (Type: /sbin/mount -wu /)!

[callumj09]

Pulling the power solved the problem. Thanks so much!

 

Edit:

 

I've just booted into 64-bit mode and I'm getting some ethernet trouble again. I think it's the kext, so I have a few more questions:

 

• Is the RealtekR1000.kext supplied with this script 64-bit compatible (and has that recently changed?)
  
• If the answer to the above is no, what's the 64 bit solution?
  
• Everything seems to be working unexpectedly well in 64-bit mode... How do I know if I'm actually running the 64 bit kernel?
  

 

That's it. As always, all help appreciated. Thanks!

[morganpl]

Device (PCI0) { … Name (_UID, One) … }

 

change to

 

Device (PCI0) { … Name (_UID, Zero) … }

BiTRiP thanks for the tip but when I change the value in the section on PCI0 Name (_UID, Zero) after the reboot my graphics falls. (I use efi string in com.apple.boot.plist)

[BlueSky2000]

Thank you dd! everything seems to be working fine including sleep/wake with 2 24" monitors.

Successfully updated to 10.6.1. Thanks again!

[digital_dreamer]

MAJ I hope you don't mind but I wrote something for the Bonjour Fix. I also created a Startupitem for it.

<SNIP>

Hey, Dith,

Thanks for that contribution. Very appreciated!

Cool workaround.

 

PS There was an error in post 1 (Type: /sbin/mount -wu /)!

Whoops! LOL!

Thanks for that catch! Fixed.

 

regards,

MAJ

[Obiwantje]

I have this mobo fully working without any use of scripts, without any modded or added kext in /S/L/E.

Everything working with latest kexts and dsdt in /Extra together with Chameleon RC3.

 

Here is my Extra folder for the ppl who still can't get this mobo working. No support by PM included

 

Good Luck,

BiTRiP

 

Extra_GA_EX58_UD5_BiTRiP.zip

 

@BiTRiP: Would you mind sharing some screenprints of your BIOS settings, somehow I can't seem to get return from sleep working, as a matter of fact, I am running the F9 bios, and I am wondering if I have a setting there that needs to change.

 

Thanks!

[@ROBASEFR]

I've just booted into 64-bit mode and I'm getting some ethernet trouble again. I think it's the kext, so I have a few more questions:

 

• Is the RealtekR1000.kext supplied with this script 64-bit compatible (and has that recently changed?)
  
• If the answer to the above is no, what's the 64 bit solution?
  
• Everything seems to be working unexpectedly well in 64-bit mode... How do I know if I'm actually running the 64 bit kernel?
  

 

Try for kernel info this:

http://www.macupdate.com/info.php/id/32252...p-mode-selector

 

I'm running only in 32 bit mode.

 

Try this one ! Perhaps you might be lucky

 

http://www.insanelymac.com/forum/index.php?showtopic=181133

 

ifcong method

 

EDIT: Latest for Bonjour Networking is this.....If your onboard ethernet it working as en0 then you don't need RealtekR1000.kext.

Thorias posted a link to Daniel U.Becker's Homepage at Standford University who has rebuilt Apple's Darwin ifconfig implementation to force a network interface to enter or leave promiscuous mode, which is needed for Bonjour.

 

Run it with the command in the Read Me and it will activate Bonjour Networking with the kernel in both 32bit & 64bit mode.

 

Incase the original webpage ever goes offline, I have saved it as a webarchive along with the original binary and sources, zipped it up and posted here.

 

Good luck

 

arobasefr

[edvardlee]

hey maj,

this is a boot screen i get trying to upgrade from 10.5.8 to SL. if i do a fresh install i can boot just fine. I think it's something to do with the bootcache?

[BiTRiP]

BiTRiP thanks for the tip but when I change the value in the section on PCI0 Name (_UID, Zero) after the reboot my graphics falls. (I use efi string in com.apple.boot.plist)

 

You have to remove the device-properties key+string from your com.apple.Boot.plist.

Just use the GraphicEnabler key from Chameleon.

 

I know it works for your card because I had it working on friends machine as well with the same card.

 

BiTRiP

[rappinkapc]

I myself am currently using the RealtekR1000.kext.

 

I noticed the bonjour issue when trying to get the iTunes Remote app working on my iPhone. So I started to look around and found a thread where the solution was posted.

 

Thread where I learned about it: http://www.insanelymac.com/forum/index.php...181903&st=0

Direct copy paste of instructions found by Eliade:

 

 

I can confirm it working, my remote is now connected to iTunes and I can access my files on the hackintosh using my MacBook and vice versa.

 

Thanks Dith,

This sort of solved my problem. I wanted to get both sleep and Bonjour working at the same time (obviously not exactly the same time, though .) The solution you posted does indeed get Bonjour to work. And using the RealtekR1000.kext allows sleep to work.

However, after the computer wakes from sleep, Bonjour stops working properly. I think this must have something to do with network adaptor no longer being in promisc mode after sleep??? How do I check whether this is the case? Is there a way to automatically force the network adaptor into promisc mode upon wake from sleep? Or am I completely misreading the situation? Any other solutions?

 

Thanks.

 

EDIT: Running the ifconfig command again after waking from sleep does not seem to fix this issue, so my guess is that my original thought was wrong.

I am using the version 1.8.1 of the RealTekR1000.kext in S/L/E, and I have also added a LAN EFI string to my boot.plist using the script (In order to get Netflix streaming to work properly).

[Hakintos]

As 64-bit detect yes.

 

[Dith]

Thanks Dith,

This sort of solved my problem. I wanted to get both sleep and Bonjour working at the same time (obviously not exactly the same time, though .) The solution you posted does indeed get Bonjour to work. And using the RealtekR1000.kext allows sleep to work.

However, after the computer wakes from sleep, Bonjour stops working properly. I think this must have something to do with network adaptor no longer being in promisc mode after sleep??? How do I check whether this is the case? Is there a way to automatically force the network adaptor into promisc mode upon wake from sleep? Or am I completely misreading the situation? Any other solutions?

 

Thanks.

 

You can check if the network card is in promiscuous mode by executing ifconfig again. If it's in promisc mode it shows PROMISC under flags as you can see below:

en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.x netmask 0xffffff00 broadcast 192.168.1.255
ether xx:xx:xx:xx:xx:xx 
media: autoselect (<unknown type>) status: active
supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 100baseTX <half-duplex> 100baseTX <full-duplex> 1000baseT <half-duplex> 1000baseT <full-duplex>

By issueing: ./ifconfig en0 promisc again it should re-enable bonjour. However I would not know how to do this automatically after returning from sleep. Perhaps a cronjob that issues the ifconfig command every 5 mins?

 

I don't use sleep myself

[rappinkapc]

You can check if the network card is in promiscuous mode by executing ifconfig again. If it's in promisc mode it shows PROMISC under flags as you can see below:

en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.x netmask 0xffffff00 broadcast 192.168.1.255
ether xx:xx:xx:xx:xx:xx 
media: autoselect (<unknown type>) status: active
supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 100baseTX <half-duplex> 100baseTX <full-duplex> 1000baseT <half-duplex> 1000baseT <full-duplex>

By issueing: ./ifconfig en0 promisc again it should re-enable bonjour. However I would not know how to do this automatically after returning from sleep. Perhaps a cronjob that issues the ifconfig command every 5 mins?

 

I don't use sleep myself

 

Oddly enough, running ./ifconfig shows that PROMISC is still activated after sleep, but Bonjour doesn't work. However disabling promisc using

 

./ifconfig en0 -promisc

 

then re-enabling it:

 

./ifconfig en0 promisc

 

brings Bonjour back. I guess that's going to have to be my work-around until I find a suitable kext that makes Bonjour work and doesn't have problems with sleep.

[callumj09]

Oddly enough, running ./ifconfig shows that PROMISC is still activated after sleep, but Bonjour doesn't work. However disabling promisc using

 

./ifconfig en0 -promisc

 

then re-enabling it:

 

./ifconfig en0 promisc

 

brings Bonjour back. I guess that's going to have to be my work-around until I find a suitable kext that makes Bonjour work and doesn't have problems with sleep.

 

I noticed that same problem as well. Although I probably won't be using sleep anymore since it doesn't work when my CPU's overclocked. After waking up my bluetooth mouse, although connected, didn't work either. But strangely the keyboard (which is also bluetooth) did work.

 

Edit:

 

Also, I still need some help getting ethernet working properly in 64-bit mode. Ethernet appears under my Network tab in 64-bit mode the same as it does in 32-bit. However, this is how it looks both using DHCP:

 

32-bit

 

 

64-bit

 

 

I'm guessing RealtekR1000.kext isn't 64-bit compatible, so the question I'm asking is what's the alternative?

 

Thanks.

[jhrfc]

Hello all,

I just thought I'd add my experiences of networking using the ud5.

To begin, as far as I know nobody has yet got this working in 64bit mode.

 

In my opinion forcing the interface into promiscuous mode to get bonjour working is a bad idea, the nic and your cpu will have to process all packets on your subnet, plus it seems the nic doesn't stay in promisc mode after sleep.

 

I have managed to get the nic and bonjour and sleep working (in 32bit mode) by using dd's script, and putting ionetworkingfamily.kext from the 10.5 folders into system plus sleepenabler.ket into extra.

 

This setup seems pretty rocksolid, i always use sleep rather then powering off, plus have time machine running every hour, and all seems to work just great. i have also never had any problems with the nic disappearing.

Thanks

 

Jon

[FUT1L1TY]

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.

[everdone]

Today I ran DDs script on my EP45-DS3L board. The only kexts needing to be changed in the script was audio for the ALC888 and IONetworking for networking. It was also necessary to remove the AppleTyMCE kext to prevent a KP while loading. The video card is Nvidia 9400GT, I equipped an EFI string in the boot.plist to enable translucent menus. The install is working in 32 bit mode. It was a short and sweat install, about an hour from start to finish.

 

Thanks again to DD for his script.

[rappinkapc]

Hello all,

I just thought I'd add my experiences of networking using the ud5.

To begin, as far as I know nobody has yet got this working in 64bit mode.

 

In my opinion forcing the interface into promiscuous mode to get bonjour working is a bad idea, the nic and your cpu will have to process all packets on your subnet, plus it seems the nic doesn't stay in promisc mode after sleep.

 

I have managed to get the nic and bonjour and sleep working (in 32bit mode) by using dd's script, and putting ionetworkingfamily.kext from the 10.5 folders into system plus sleepenabler.ket into extra.

 

This setup seems pretty rocksolid, i always use sleep rather then powering off, plus have time machine running every hour, and all seems to work just great. i have also never had any problems with the nic disappearing.

Thanks

 

Jon

 

 

Thanks. That works great! The only thing I will say is that putting sleepenabler.kext into Extra causes kernel panics for me upon wake from sleep in certain instances (e.g. plugging in a usb thumb drive after wake up). Keeping sleepenabler.kext to system seems to work, though.

[LocusOfControl]

Hi

 

Just thought I'd mention I've never had a problem with bonjour, worked out of the box but I did my install

slightly differently to most people and never had any kernel panics or spotlight issues

 

As you can see bonjour is working - starting at boot with no help from me. Apple TV synchronises with

ITunes (bonjour required for this)/ IPods etc

 

Doing ifconfig shows that I'm not using any of these Promiscuous hacks, to me it works the way it did in

Leopard.

 

I've never really bothered fixing sleep, when I tried sleep it goes to sleep, wakes up when I hit keyboard but

monitor doesn't wake, everything else appears awake (board goes back to FF)

 

bash-3.2# ps -ef | grep mDNSResponder
  65    17     1   0   0:00.09 ??         0:00.16 /usr/sbin/mDNSResponder -launchd
bash-3.2# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
inet 127.0.0.1 netmask 0xff000000 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::224:1dff:fe11:8109%en0 prefixlen 64 scopeid 0x4 
inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255
ether XX:XX:XX:XX:XX:XX 
media: autoselect (<unknown type>) status: active
supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 100baseTX <half-duplex> 100baseTX <full-duplex> 1000baseT <half-duplex> 1000baseT <full-duplex>
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:dc:af:57:00:00:1f:d0 
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether YY:YY:YY:YY:YY:YY 
media: autoselect (<unknown type>) status: inactive
supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 100baseTX <half-duplex> 100baseTX <full-duplex> 1000baseT <half-duplex> 1000baseT <full-duplex>
bash-3.2# 

 

 

By the way, I'm only using 32 bit, not too interested in 64 bit - running 32 bit Eclipse Java ports in 64 bit jvm's is

bad enough!

 

regards

Steve

[khaosnz]

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.

 

Cheers FUT1L1TY

Bear in mind to all. PlatformUUID.kext > Contents > info.plist sets your Hardware UUID: in System Profiler so if you have a Partition UUID: in there you will have to remove it first to get the true UUID. Then update with correct Hardware UUID: possibly after a reboot. May also apply to UUID.kext.

Can anyone confirm if Hardware UUID: is the correct UUID to enter in smbios.plist?

As I understand it correctly it should be

Partition UUID: for com.apple.boot.plist

Hardware UUID: for UUID.kext PlatformUUID.kext smbios.plist

[digital_dreamer]

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.

FUT1L1TY,

Thanks for that explanation!

And, will fix, but it begs the question, as I'll note below...

 

Cheers FUT1L1TY

Bear in mind to all. PlatformUUID.kext > Contents > info.plist sets your Hardware UUID: in System Profiler so if you have a Partition UUID: in there you will have to remove it first to get the true UUID. Then update with correct Hardware UUID: possibly after a reboot. May also apply to UUID.kext.

Can anyone confirm if Hardware UUID: is the correct UUID to enter in smbios.plist?

As I understand it correctly it should be

Partition UUID: for com.apple.boot.plist

Hardware UUID: for UUID.kext PlatformUUID.kext smbios.plist

khaosnz,

Thanks for that info.

 

Now, here's my question:

If removing the current (albeit, incorrect) UUID from smbios.plist will allow the correct UUID to appear, why isn't the smbios.plist retrieving it this way? Basically, you appear to be saying we really don't need that Platform UUID there, as it can be retrieved from hardware anyway, where ever that is.

But, I don't think there is one for hackintoshes. It seems to me that the hardware or platform UUID is planted in EFI firmware by Apple. So, we need to create and settle on a never changing platform UUID for use in the smbios.plist.

This will give me something to research and think about.

 

MAJ