[GUIDE] Scripted Yosemite/Mavericks Install on Gigabyte Mobos

[digital_dreamer]

I know for certain my system uses the bootPlist in Library/Preferences/Systemconfiguration.

 

When you find it, copy it to your desktop, then replace the one in L/P/SC with the one from your Extra folder that is assuming you already have your efi strings present in the bootPlist in your Extra folder

Okay, this is interesting and not the first time I've seen this mentioned.

Can we confirm from other 64-bit users that their system is not using the boot plist in /Extra? A simple test would be to modify the plist at L/P/SC with a change that is clearly visible, like adding or removing -v. I'm just wondering if there are other conditions besides 64-bit mode that causes this behavior. I can't test it myself as I depend on a 32-bit kext for graphics.

It may be helpful to mention what bootloader and version you're using, but I'm sure they would all be from the Chameleon base (which includes PC-EFI).

 

My plist editor is designed to ignore the plist in L/P/SC if there is one present in /Extra, basically in an effort to make it less confusing for n00bs. But, if 64-bit bit mode really uses the plist in that location, then I may edit the script to just make it visible all the time.

(A inside tip: If you have a EFI install, switching to the /Extra install will cause the plist editor to ignore the boot plist in /EFI/Extra, making all boot plists in L/P/SC visible.)

 

regards,

MAJ

[mangopeach]

Okay, this is interesting and not the first time I've seen this mentioned.

Can we confirm from other 64-bit users that their system is not using the boot plist in /Extra? A simple test would be to modify the plist at L/P/SC with a change that is clearly visible, like adding or removing -v. I'm just wondering if there are other conditions besides 64-bit mode that causes this behavior. I can't test it myself as I depend on a 32-bit kext for graphics.

It may be helpful to mention what bootloader and version you're using, but I'm sure they would all be from the Chameleon base (which includes PC-EFI).

 

well... I assume mine is using the plist in extra because otherwise how would it be loading my graphics kexts, resolution during bootup, and toggling between 32/64 bit? How could it not be? I'm using chameleon from your latest script, extra, and running 64bit. Apple raid works like a charm btw. My heart goes out to poor zoro. I have had nothing but success with several disks running 10.5 and 10.6 using DD scripts. I have never gotten sleep mode to work perfectly ever though. I just dont care anymore. when you have a stable system at 13k+ geekbench for under $1000 there isnt much to complain about.

[tsunoo]

Okay, this is interesting and not the first time I've seen this mentioned.

Can we confirm from other 64-bit users that their system is not using the boot plist in /Extra? A simple test would be to modify the plist at L/P/SC with a change that is clearly visible, like adding or removing -v. I'm just wondering if there are other conditions besides 64-bit mode that causes this behavior. I can't test it myself as I depend on a 32-bit kext for graphics.

It may be helpful to mention what bootloader and version you're using, but I'm sure they would all be from the Chameleon base (which includes PC-EFI).

 

My plist editor is designed to ignore the plist in L/P/SC if there is one present in /Extra, basically in an effort to make it less confusing for n00bs. But, if 64-bit bit mode really uses the plist in that location, then I may edit the script to just make it visible all the time.

(A inside tip: If you have a EFI install, switching to the /Extra install will cause the plist editor to ignore the boot plist in /EFI/Extra, making all boot plists in L/P/SC visible.)

 

regards,

MAJ

 

 

OK I just found (!?!?!) the right solution (after more than 40 boots..) to have the right monitor/graphic card/Nvidia EFI-string working.

 

First: /Volumes/XXXX/Library/Preferences/SystemConfiguration/com.apple.Boot.plist does NOT help.

 

2nd: I did have an EFI Install but now I use Chameleon. The right solution is to make a copy of com.apple.Boot.plist in /Volumes/EFI/Extra.

 

Now I can have 1600x1200 again

[iCore]

*** Sleep problems:

If sleep doesn't work properly (computer restarts or getting KP after awake)

- delete: /Library/Preferences/SystemConfiguration/com.applePowerManagament.plist

- reboot and move two sliders inside EnergySaver preferences to desired positions.

- make sure that "Start up automatically after power failure" is checked.

- reboot with -s and update caches with buildcache commannd.

 

I tried this, but I still have KP on wake up (when launching rosetta apps)

By the way, I did not have the "Start up automatically after power failure" in the energy saver preferences... why ? could it be the cause of the problem ?

[CruiSAr]

Okay, this is interesting and not the first time I've seen this mentioned.

Can we confirm from other 64-bit users that their system is not using the boot plist in /Extra? A simple test would be to modify the plist at L/P/SC with a change that is clearly visible, like adding or removing -v. I'm just wondering if there are other conditions besides 64-bit mode that causes this behavior. I can't test it myself as I depend on a 32-bit kext for graphics.

It may be helpful to mention what bootloader and version you're using, but I'm sure they would all be from the Chameleon base (which includes PC-EFI).

 

regards,

MAJ

Yeah I also thought it weird because your very first SL script used the boot plist in Extra. I will perfrom more tests on an external drive I have to confirm this weird behaviour.

[LocusOfControl]

Yeah I also thought it weird because your very first SL script used the boot plist in Extra. I will perfrom more tests on an external drive I have to confirm this weird behaviour.

 

I only have boot.plist in EFI/Extra and it is definitely using that (64 & 32 bit)

 

When I first installed 10.5 I didn't really know how things connected, I had several attempts at installing

chameleon because 'it never worked the first time'. In the end I ended up with couple of installs of different

boot loaders, one in /Extra one in EFI/Extra. Never knew which one was going to work

 

Perhaps people may inadvertently got multiple installs and boot files?

[Josvdp]

Like you LocusOfControl, I have another installation (on another harddisk though). Sometimes the Chameleon bootloader seems to hang at it's startup (when you see the /...|..\...-... turning in the top left corner of the screen). But a reboot resolves that.

 

Anyway, DD, you asked user experience with the boot plist files. Well, all I can say is that I had a clean install. As soon as I tried to boot in 64-bit mode (using the arch=x86_64 at bootloader prompt) it ignored the boot plist in Extra and started using the one in L/P/SC, even when I returned to 32-bit again.

 

My full story can be found here step 9 is where my system seemed to suddenly use the boot plist in SC.

 

d00d has already provided the patched DSDT for the GA-EX58-UD5 which allow u to run native power managment and working sleep. I have a working SL 64 bit using this workaround with only these 4 kexts in Extra

 

fakesmc

IOAHCIBlockStorageInjector

EvoReboot

PlatformUUID

 

I have Realtek1000 in S/L/E for ethernet

 

How not advanced do you want it to be? Just stick to DD's if you find d00d approach to be too cumbersome

Thank you CruiSAr for stating this, it was helpful to see that I only need those 4 (+ Network) kexts with d00d's guide. But does that mean I can follow DD's guide (this topic) but when installing kexts, I install only the above kexts? Or do I have to install differently?

[tsunoo]

I only have boot.plist in EFI/Extra and it is definitely using that (64 & 32 bit)

 

When I first installed 10.5 I didn't really know how things connected, I had several attempts at installing

chameleon because 'it never worked the first time'. In the end I ended up with couple of installs of different

boot loaders, one in /Extra one in EFI/Extra. Never knew which one was going to work

 

Perhaps people may inadvertently got multiple installs and boot files?

 

it seems that the com...plist file have to be in the first partition to work.

 

I had SL at disk0s4 and the com...plist wasn't active. Copying it to EFI/Extra was the solution.

Now I reformated my HD and put SL to disk0s2 and it works without EFI/Extra.

 

So If you have SL at the first partition it works easier than when you put it on the 2nd/3rd/4th partition

[CruiSAr]

Thank you CruiSAr for stating this, it was helpful to see that I only need those 4 (+ Network) kexts with d00d's guide. But does that mean I can follow DD's guide (this topic) but when installing kexts, I install only the above kexts? Or do I have to install differently?

Yes you can use DD's script and install only the Kexts I mentioned. I did things differently for this specific setup, I installed everything myself and the good thing is I have gotten a broader perspective on how things work under the hood.

 

it seems that the com...plist file have to be in the first partition to work.

 

I had SL at disk0s4 and the com...plist wasn't active. Copying it to EFI/Extra was the solution.

Now I reformated my HD and put SL to disk0s2 and it works without EFI/Extra.

 

So If you have SL at the first partition it works easier than when you put it on the 2nd/3rd/4th partition

I doubt it has anything to do with what partition the install is on. I have a hard drive each for every OS. Will run tests tonight and post the results tomorrow

[zoro2]

No Sound

 

RealtekR1000SL.kext is installed: Extra/Stored_KEXTs/_For_System/RealtekR1000SL.kext

 

And still I Have no sound. Had it before, but not since resetting my boot files.

 

What do I need to install, and where? Is there another key sound file that I should be looking for?

 

And, to be clear, I assume I can drag the correct file into place so long as I give the admin password and then reset permissions.

 

Thanks.

[Josvdp]

No Sound

 

RealtekR1000SL.kext is installed: Extra/Stored_KEXTs/_For_System/RealtekR1000SL.kext

 

And still I Have no sound. Had it before, but not since resetting my boot files.

 

What do I need to install, and where? Is there another key sound file that I should be looking for?

 

And, to be clear, I assume I can drag the correct file into place so long as I give the admin password and then reset permissions.

 

Thanks.

I'm not sure what you're talking about (didn't follow your problems) but the Realtek kext is for your network to work, not audio. I'm not sure what will fix your audio (I'm too much of a n00b) but one thing I know is that after adding (and removing) a kext from the Extra folder, you always have to update boot caches with DD's script. So, no, you can't just drag the file and repair permissions. You have to update boot caches as well.

[zoro2]

I'm not sure what you're talking about (didn't follow your problems)

To be clear, I have redone this drive many times now. Some of the time it gets working sound perfectly. Some of the time, like now, it has no sound. What this means is the sound slider on the menu bar and in sound prefs is greyed out at the bottom of the slider. THere is no sound, at all.

... the Realtek kext is for your network to work, not audio. I'm not sure what will fix your audio (I'm too much of a n00b) but one thing I know is that after adding (and removing) a kext from the Extra folder, you always have to update boot caches with DD's script. So, no, you can't just drag the file and repair permissions. You have to update boot caches as well.

Hmm, OK, thanks for that info, I guess I had it wrong then. AppleHDA then must be the missing piece? Here is a thread just to that, although it is more 10.5 stuff. I wonder if it is also relevant?

 

AppleHDA Thread

 

Oddly, I have followed the DD script and some ways I have gone, the sound gets correctly installed. Other ways I go, it does not. As I am still trying to get stable again, it has been hard to tell exactly with method has been working (with so many install attempts). I believe this was a 1) System 2) PCI/EFI with DSDT patching and cache rebuild after.

 

Because of this I Was thinking that there must me something right in front of me that didn't get installed. I haven't gotten any responses to my query about my board may going bad but I am pretty sure this is s relatively simple software install problem, but there have been so many things to sort through, I appreciate the feedback.

 

UPDATE:

I got the EFI boot loader to work on the start volume and the RAID volume just booted. Yay, first time in a couple weeks.

 

Weird thing is, it feels much zippier than the external SNL volume I just migrated to. I guess that is the difference RAID throughput can make? I suppose I could install SNL back on the RAID array .. naw, rest a while first. LEar5n what I did and how it got to where it is not first.Can anyone suggest a utility or command line tool to recognize a drive? I have an old USB backup drive which should now be made bootable, for emergency if nothing else. But it isn't seen as a drive or mounted at all anywhere. Not with DW, or DD script, or DU. IT seems to run as it's little blue drive light is on. Used to be long ago in system 9 days there were utilities which could take a drive open even if it wasn't mounting, etc. ANy ideas with this one?

 

Thanks

[El_Rocko]

Check out my post, just click on the link in my signature. I have described how to fix this issue with NTFS 3G

 

Hi There CruiSAr!

 

Thanks for your answer! Now, there is a bit of a problem... the linkt that previously should have direct me to the macFuse Google Group where I should be able to download MacFuse 2.1.7 is no longer there!!

 

Could you upload the one you have to rapid{censored} or something like that? I have searched for an online link to download it but I can not find it.

 

I would really appreciate your help on this!

 

Thanks a lot!

 

 

EDIT: I found it! and it works!! It even solved a restart issue I had running in 64 bit mode... weird, isn't it?

 

anywar, THANKS A LOT!! now I'm ready to rumble!!!

[CruiSAr]

Hi There CruiSAr!

 

Thanks for your answer! Now, there is a bit of a problem... the linkt that previously should have direct me to the macFuse Google Group where I should be able to download MacFuse 2.1.7 is no longer there!!

 

Could you upload the one you have to rapid{censored} or something like that? I have searched for an online link to download it but I can not find it.

 

I would really appreciate your help on this!

 

Thanks a lot!

 

Get the new version of NTFS 3G from the developers site here

it inclides the 64 bit Macfuse Version

[zoro2]

Sorry to persist and don't mean to be a bother but, not getting it folks. Wish I did. I found a tutorial on LifeHacker that suggested a download for KEXT Utility and a driver that was said to fix the sound problem in snow leo. But it may have been specialized for a board with their build (not sure). It did not work.

 

The thread I referenced in my last post was for Leopard and it was using the language of Linux code dumps, which is still a bit above my head.

 

I would love to get back to having a productive day. Without sound, I can't. I have tutorials to watch and I have a sound recording that I have to make for an audio book. I can at least boot into my old raid setup, that has working sound. But booting back and forth is problematic with the way this machine keeps hanging on boot and besides, trying to stay organized on two different working disks is going to be not good for my organizational skill level.

 

I know others have had trouble with sound issues in Snow leo. I apologize but I Cant seem to find a working answer, or a well lit path to find an answer.

 

A little help would be greatly appreciated.

[CruiSAr]

I know others have had trouble with sound issues in Snow leo. I apologize but I Cant seem to find a working answer, or a well lit path to find an answer.

 

A little help would be greatly appreciated.

The 2 kexts in DD's script should suffice for you otherwise you can try VoodooHDA, install it to S/L/E

[zoro2]

The 2 kexts in DD's script should suffice for you otherwise you can try VoodooHDA, install it to S/L/E

Thanks. I just did as you suggested, found the VoodooHDA and used Kext Utility to install it. REbuilt permissions and AFAIK it would now work if it was going to? Or should I rerun the script and rebuild boot caches now? I will try and see if that helps.

 

What I have discovered is that the script offers few different ways to assemble boot-loaders. 1) System vs EFI, 2) Chameleon v4, v3, PCI/EFI, older. For some reason, I have used the DD script and gotten perfect sound working. And I Have used the script and had no sound working, like now. I was having so many problems that I was not tracking scientifically which method was producing what results. I apologize for that. I believe I used 1) System and 2) PCI/EFI to get it working this time.

 

That is why I was looking to see just what KEXT if any was missing. My thinking wast that rather than start throwing this way and that way to redo the entire boot loader install process, just see what didn't get installed that should have.

 

I do appreciate the help. I will run the script on the boot cache now and recheck. If no repost or edited post, please assume I am still in silence.

 

Thanks again.

 

ADDED: No, rebuilding the boot cache did not work, still no sound. I also reran the DSDT patcher, this machine is still making me reset the bios each and every time it boots.

 

I would have thought there was just a file missing but perhaps it would save time to simple try again to install boot-loaders with the script?

[LocusOfControl]

ADDED: No, rebuilding the boot cache did not work, still no sound. I also reran the DSDT patcher, this machine is still making me reset the bios each and every time it boots.

 

It sounds like you have the dreaded CMOS bug

[zoro2]

It sounds like you have the dreaded CMOS bug

Are you teasing me? WHat CMOS bug? Never did it before all the troubles I started having.

[LocusOfControl]

Are you teasing me? WHat CMOS bug? Never did it before all the troubles I started having.

 

Type CMOS bug in the search box at the top of the page

 

then go here and fix it http://www.insanelymac.com/forum/index.php?showtopic=196771

[zoro2]

Type CMOS bug in the search box at the top of the page

 

then go here and fix it http://www.insanelymac.com/forum/index.php?showtopic=196771

Oh durn, I was hopping you were kidding. OK, thanks. Looks like some future fine tuning then.

 

I am systematically going through each install of DD scripted boot loaders now. Staying with 1) SYstem partition (/Extra), then Chamo v4, v3. About to reboot and try PCI-EFI then Chamo 1012.

 

The only other possible variable is the options for rebuilding cache. Can you comment on what those differences are and why they should matter to me at the moment? I have been selecting super as opposed to normal cache rebuild, thinking I wanted to throw all the effort on it as I could and super sounded a bit more complex than normal.

 

I will return after another boot.

 

ADDED: No joy with the sound. Last boot to try is the v1012. Unless the way I have chosen to rebuild the cache has been a variable? I can try that next I guess.

 

Added Latest: OK, no sound. Been through all the install options after 1 is system. I even tried super and normal cache rebuilds on the most promising boot loader, the PC-EFI option. What makes sound on the machine? I know I Have had it apparently accidentally with this script process.

 

Added Final: Tried again with EFI instead of system. No sound. Can't get sound. REally would like to get sound. Guess I will have to boot back and forth a while longer. If you have any thoughts on the subject, I would be delighted to entertain them.

[LocusOfControl]

Oh durn, I was hopping you were kidding. OK, thanks. Looks like some future fine tuning then.

 

I am systematically going through each install of DD scripted boot loaders now. Staying with 1) SYstem partition (/Extra), then Chamo v4, v3. About to reboot and try PCI-EFI then Chamo 1012.

 

The only other possible variable is the options for rebuilding cache. Can you comment on what those differences are and why they should matter to me at the moment? I have been selecting super as opposed to normal cache rebuild, thinking I wanted to throw all the effort on it as I could and super sounded a bit more complex than normal.

 

I will return after another boot.

 

ADDED: No joy with the sound. Last boot to try is the v1012. Unless the way I have chosen to rebuild the cache has been a variable? I can try that next I guess.

 

Added Latest: OK, no sound. Been through all the install options after 1 is system. I even tried super and normal cache rebuilds on the most promising boot loader, the PC-EFI option. What makes sound on the machine? I know I Have had it apparently accidentally with this script process.

 

Added Final: Tried again with EFI instead of system. No sound. Can't get sound. REally would like to get sound. Guess I will have to boot back and forth a while longer. If you have any thoughts on the subject, I would be delighted to entertain them.

 

Are you connecting through the line outputs? Have you configured your sound in system prefs?

Have you enabled sound in bios if it is being reset every boot?

 

After all your previous issues are you saying you have a working SL apart from sound and cmos reset bug?

It isn't clear from what you are saying what you are using, one week you didn't have a working system and

now you seem to have fixed everything apart from the above two issues?

 

If the answer is yes to the last question, stop fiddling with boot-loaders etc. install the DSDT fix and sound kext by

hand, that way you will learn what you are doing and you wont override anything else that you don't know about.

 

It shouldn't matter if you use Chameleon Rc3, Rc4 or PCEFI, they are just boot files and wont affect your sound.

You need either an appropriate sound kext for your board with the permissions set correctly in the correct place,

or a correctly configured DSDT file containing sound support - I use the latter and I don't have any 3rd party sound

kexts (but I only use front speakers).

 

Your board (UD4P?) has the Realtek ALC889A codec so you should be able to use the following kext in Extra/Extensions

which worked for me. It was the only one that gave me sound when I did the SL install video

I don't know what you may have done in terms of kext caching, personally I just do that in /S/L/E and don't bother

doing Extra/Extensions. You may need to check that out on your system after all your rebooting.

ALC889A.Fix.kext.zip

[zoro2]

Are you connecting through the line outputs? Have you configured your sound in system prefs? Have you enabled sound in bios if it is being reset every boot?

As far as I know there is no sound configuration settings in bios. And besides, it has working sound when I boot to the RAID (older working) drive. When I say, "not working", I mean that the sound volume slider is at the bottom of it's range and it is also grayed out. Normally I have one line out on the back of the board that runs a small subwoofer and speakers (quite nicely). I can also run a digital sound processor via firewire for recording purposes. But the hardware, or the motherboard sound drivers (KEXTs?), don't seem to have activated.

 

After all your previous issues are you saying you have a working SL apart from sound and cmos reset bug? It isn't clear from what you are saying what you are using, one week you didn't have a working system and now you seem to have fixed everything apart from the above two issues?

Yes, sorry, to clarify; Yes I am almost 100% back now. I am now booting back onto my old RAID array drive. Because I can now do this, I no longer have a lost database and that issue has been resolved. I have been in hell with all the problems I Had to deal with. SLowly I have been correcting them. I still don't know what got me there in the first place though.

 

Right now I have almost a fully working system again. Even the reset bug is waning. Of course, the way it's been I will give it a week minimum of various restarts before I trust that, but after all the rebuilds of the boot-loader today, not once has it had to be reset in bios. I was doing that so often I can almost reset the bios by the rhythm of the keys instead of looking at it (don't worry, I look first).

 

And that leaves sound not on as the final problem. Assuming I don't fall into whatever got me down this road in the first place again, I am (almost) in the clear now.

 

If the answer is yes to the last question, stop fiddling with boot-loaders etc. install the DSDT fix and sound kext by hand, that way you will learn what you are doing and you wont override anything else that you don't know about.

I appreciate that. I was told by DD to run the DSDT patcher again and I did, but then I could not get into my RAID drive and so I ran it from my old G4, running leopard. SO it really should have worked. But perhaps it just did not take? Yes, I am open to learning what the dsdt patching does and to learn how I Can get this as it should be for now and for the future. I can get all the data from a dump but as yet I am not sure what I should do with it or where to save it and affect changes. If you could suggest a tutorial I would try to absorb it.

 

It shouldn't matter if you use Chameleon Rc3, Rc4 or PCEFI, they are just boot files and wont affect your sound. You need either an appropriate sound kext for your board with the permissions set correctly in the correct place, or a correctly configured DSDT file containing sound support - I use the latter and I don't have any 3rd party sound kexts (but I only use front speakers).

 

Your board (UD4P?) has the Realtek ALC889A codec so you should be able to use the following kext in Extra/Extensions which worked for me. It was the only one that gave me sound when I did the SL install video

I don't know what you may have done in terms of kext caching, personally I just do that in /S/L/E and don't bother doing Extra/Extensions. You may need to check that out on your system after all your rebooting.

I first tried using a KEXT install utility, but it stuck the KEXT in the system folder. I dragged the file you shared instead by hand into the extras folder (like you said to). Then I ran DU to repair permissions. Rebooting, still no sound. But I did see a somewhat ominous looking repeating lines of code on boot (booting verbose). IT was about the VoodooHDAdevice and something about deactivate all sound. I removed the VoodooHDAdevice KEXT and rebuilt permissions and rebooted again.

 

Still no sound.

 

I am going to upload two screen shots of my extras folder. IF anything looks weird or is missing ... (?)

 

Thanks

[AppleIIGuy]

I appreciate that. I was told by DD to run the DSDT patcher again and I did, but then I could not get into my RAID drive and so I ran it from my old G4, running leopard. SO it really should have worked. But perhaps it just did not take? Yes, I am open to learning what the dsdt patching does and to learn how I Can get this as it should be for now and for the future. I can get all the data from a dump but as yet I am not sure what I should do with it or where to save it and affect changes. If you could suggest a tutorial I would try to absorb it.

 

You MUST run the DSDT patcher on the system you are installing onto. A DSDT from a G4 will not help you at all I may even cause more problems.

 

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.

[digital_dreamer]

zoro2,

You have two kext installations in your /Extra folder:

1. Kexts in a "Extensions" folder

2. Kexts in mkext file (boot cache)

 

You can only have one of these at a time. This can be a cause of much confusion for the bootloaders. So, I'd get rid of the "Extensions" folder and its accompanying kexts and just rely on the boot cache, which is created from the kexts in "Stored_Kexts" directory.

 

That'll be a good start.

 

MAJ