[GUIDE] Retail OS X Install (10.5.8) on Gigabyte GA-EX58-UD5 (Core i7) Mobo

[Asterra]

Okay. Here's the latest thing I'm trying to do in my quest to get the 4870 working fully with Digital Dreamer's scripted install. There is a certain recent natit.kext (as of April 22) which has been the subject of a number of success stories. My problem is that I apparently don't understand how to go about replacing Digital Dreamer's natit.kext (residing in /Extra/Extensions) with the newer natit.kext, which Kext Helper is told to place in /System/Library/Extensions. Replacing the natit.kext in the install package? Kernel panic. Deleting one and installing the other, after OSX installation? That doesn't seem to work. There must be some sort of post-fudging process that needs to be sorted out.

 

Anyway, that's what I'm after: The precise method of replacing an older /Extra/Extensions/natit.kext with a newer /System/Library/Extensions/natit.kext.

[joeblough]

Okay. Here's the latest thing I'm trying to do in my quest to get the 4870 working fully with Digital Dreamer's scripted install. There is a certain recent natit.kext (as of April 22) which has been the subject of a number of success stories. My problem is that I apparently don't understand how to go about replacing Digital Dreamer's natit.kext (residing in /Extra/Extensions) with the newer natit.kext, which Kext Helper is told to place in /System/Library/Extensions. Replacing the natit.kext in the install package? Kernel panic. Deleting one and installing the other, after OSX installation? That doesn't seem to work. There must be some sort of post-fudging process that needs to be sorted out.

 

Anyway, that's what I'm after: The precise method of replacing an older /Extra/Extensions/natit.kext with a newer /System/Library/Extensions/natit.kext.

 

D_Ds script makes /Extra/Extensions.mkext from the stuff in /Extra/Extensions. if you put new kexts in /Extra/Extensions but don't create a new /Extra/Extensions.mkext, i'm reasonably certain you won't see the new kexts you've put in /Extra/Extensions. you need to regenerate /Extra/Extensions.mkext as i showed in my previous post.

 

kext helper is problematic because as you said it wants to install stuff to /System/Library/Extensions and that's not where we want to put stuff when we are using Chameleon (unless we absolutely have to - there seem to be some kexts that won't load from any place but /S/L/E.) its bad news to have duplicate kexts in /Extra/Extensions.mkext and /S/L/E, because if the version numbers of the two kexts are the same, its random as to which one actually gets picked up.

 

so i'd say just manually fix the permissions in /Extra/Extensions and create Extensions.mkext with the code i gave above.

[FUT1L1TY]

for people that are messing with putting new kexts in /Extra/Extensions:

 

are you just dumping the kexts in that directory? it seems to me like this might not actually work. i always make an Extensions.mkext and put that in /Extra, and in fact i usually rename the /Extra/Extensions directory to something else so that Chameleon can only see the Extensions.mkext.

 

i dont know why, but this seems to work better than just putting the extensions in /Extra/Extensions.

 

if you read d_d's script you can find the line that creates Extensions.mkext - its a program called mkextcache.

 

Thank you joeblough. You solved my problem. My machine booted for the very first time thanks to your tip. If anyone else is having problems similar to mine (see my previous post), you can try the following procedure assuming you have run the 4/26 DD script (steps 1-5) on a freshly formatted drive.

 

My drive is called "OSx86" so you will need to substitute the name of YOURHARDDRIVE wherever it occurs below.

 

1. (in Finder) trash "Extensions.mkext" located in your /Extra folder

2. (in terminal window type) sudo su -

3. (in terminal window type) cd /Volumes/OSx86/Extra

4. (in terminal window type) mv Extensions Stuff

5. (in Finder) trash all your caches in both /System/Library/Caches/ and /Library/Caches/

6. (in terminal window type) kextcache -a i386 -m "/Volumes/OSx86/Extra/Extensions.mkext" "/Volumes/OSx86/Extra/Stuff"

7. There will be some warnings. I ignored them.

8. (in terminal window type) cd ..

9. (in terminal window type) chmod -R 755 Extra

10. (in terminal window type) chown -R root:wheel Extra

11. (in terminal window type) diskutil repairPermissions /Volumes/OSx86

 

In conclusion: For whatever reason, it seems that we may need to keep our kexts away from Chameleon 2. I'm too much of a noob to have any real insight into the matter. I built my machine 3 days ago. I'll leave the real fix to the professionals.

 

Thanks again everyone.

[joeblough]

Thank you joeblough. You solved my problem. My machine booted for the very first time thanks to your tip.

 

that's good news. i think i should expand on what i was saying... my belief is that if /Extra/Extensions.mkext exists, then chameleon will not load anything from /Extra/Extensions. since D_D's script creates /Extra/Extensions.mkext, if you do not recreate it after putting in new kexts, chameleon will never load the new extensions.

 

that implies that if you are not going to rebuild /Extra/Extensions.mkext, you at least have to delete it if you have put new stuff in /Extra/Extensions. however i found that chameleon did not reliably load everything in /Extra/Extensions even with the mkext deleted, so i just started making my own /Extra/Extensions.mkext.

 

Yeah, I'm noticing that bit by bit. The thing about the dependencies messages I'm not sure about is whether those messages appear when the kernel cannot resolve the dependencies within that directory, or whether it's when it has searched all possible directories (in this case, /Extra and S/L/E). When you pack Extensions in /Extra, for example, there are dependency warnings on all kexts, in spite of the presence of S/L/E. So, it appears to be a dependency issue for that directory, at least as far as packing extensions are concerned.

 

i don't have a solid understanding of how chameleon works. but reading between the lines, it looks like it 'fools' the kernel into considering extensions from /Extras/Extensions.mkext or /Extras/Extensions/ as well as the default /System/Library/Extensions.

 

so at boot time when it throws the dependency warnings/errors, my feeling is that the kernel can see every single kext that's in both of those two places. part of IOKit's functionality is to resolve the kext deps and arbitrate between any duplicate kexts.

 

as far as the warnings go when you are making /Extra/Extensions.mkext, i think that's normal because kextcache can only see the extensions in /Extra/Extensions while it's building /Extra/Extensions.mkext.

 

 

 

Additionally, I'm under the impression that some of these issues occur because there are plugsin (basically, kexts) within the kexts in /Extra that have unchanged version numbers. There have never been any attempts to up those version numbers that I know of. Is this because those plugins inherit the higher version number of its parent and, therefore, version number increases are not needed (for the plugins)? I'm not inclined to believe that, as it looks like the system is not consistently loading all plugsin of a kext with a increased version number. Witness the System.kext issue. Few of those plugins in /Extra get loaded, likely because the one in S/L/E has the same version number, in spite of its parent version. Which get loaded depends on the roll of the dice. This would explain why some users experience working Bluetooth, USB, etc., on some boots and no working devices on other boots. But, then again, we didn't have this System.kext issue in the older bootloaders. So, it may be the way the bootloader is handling the child kexts. I wouldn't know.

 

this is a very good point. again, assuming that IOKit sees all extensions in a single 'address space' as it were, its very likely that it tries to load some Plugin kexts from /System/Library/Extensions because they have higher version numbers than the ones in /Extras. a lot of these hacked kexts came from earlier versions of OSX and as a result they have lower versions than what's in /S/L/E, which is of course why we tweak the version numbers in Info.plist. but as you say it seems that no one has ever tweaked the version numbers of the PlugIn kexts that live inside some of these hacks. so IOKit tries to load the non-hacked plugin, but then that plugin can't load due to the fact that the hacked kext does not have the version number that the plugin is expecting.

 

Funny thing is about that System.kext is that not everyone is experiencing the loading issue. I have the 9.6.0 System.kext in S/L/E on both of my installs have experienced none of these issues in Cham2. Why is that? It appears there may be a little overlooked situation that must occur to make this work, or not work. I haven't determined what it is, yet.

 

The IP over Firewire service is odd, because I'm using the same kexts from EFI boot and don't recall missing that service in Network. But, it's certainly missing now. Not that I need it, however.

 

One thing for sure, the bootloader release appears to be a whole different kettle of fish.

 

regards,

MAJ

 

i think i might at least take a look at all the version numbers of the Plugin kexts in the stuff in /Extras and see how they compare to the 10.5.6 versions. maybe these problems can be resolved by tweaking the plugin extension versions in /Extra.

 

edit: that's interesting. these "legacy" kexts that are used for /Extra or the EFI boot-132 method are mostly empty... there aren't really many plugins in there, except for inside of System.kext. i don't have a 10.5.6 System.kext handy but it would be interesting to compare the versions of the plugin kexts there with the 9.6.3 one - this could still explain some problems if some System.kext plugins were loading from the wrong place.

 

edit again:

 

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

 

this thread explains the "legacy" kexts. basically they are just the Info.plists of hacked kexts. the original author says that in fact the IONetworkingFamily stuff does cause dependency problems unless you boot with -f. i just tried this and i still see the firewire kext complaining, and furthermore it's now hanging at /usr/sbin/ocspd[73]: starting !

 

yikes.

[digital_dreamer]

Script has been updated:

• Script has been updated to include the older Chameleon v1012 bootloader for those who wish to use something more stable. If you wish to revert from Chameleon 2.0 RC1 to the older v1012, simply installing/overwriting the newer bootloader (pre-patch) may create serious issues, leading to a unmountable partition. (It did in my case, but that may have been a fluke, so be aware.) It's recommended to do a backup, erase, install, and restore. This older bootloader still uses the /Extra directory, but does not include Themes or a boot.plist in that directory. Rather, the boot.plist is in it's conventional location. The script automatically copies the boot.plist to the proper location, depending on the bootloader in use.

 

• IMPORTANT: Those wishing to use the older bootloader (any older version, actually), will need to use the Voodoo-based 9.6.0 kernel and include the busratio=20 kernel flag in the boot.plist if they want to avoid the system clock speed-up issue, until a future time this issue is resolved.

 

• Regardless of bootloader in use, the kernel's matching System.kext is copied to S/L/E, with the original renamed, thereby improving system behavior. This action makes this kext the only file copied into the vanilla OS install.

 

• The Natit.kext has been updated.

 

regards,

MAJ

[neils]

there is some doubt as to whether System.kext can be picked up properly from /Extra, which is why i copied it to both places.

 

as i mentioned above it seems to me that one has to make an mkext of the stuff in /Extra/Extensions or sometimes all of your extensions do not load.

 

Are you saying I should delete the original mxkext before I run the suggested commands to create/modify the mkext ?

 

I'm gonna try that tomorrow.

 

The good news is, I ordered a nice and shiny 25,5 inch HP Monitor.

 

Thanks for you reply Joe !

[Crash4419]

1. (in Finder) trash "Extensions.mkext" located in your /Extra folder

2. (in terminal window type) sudo su -

3. (in terminal window type) cd /Volumes/OSx86/Extra

4. (in terminal window type) mv Extensions Stuff

5. (in Finder) trash all your caches in both /System/Library/Caches/ and /Library/Caches/

6. (in terminal window type) kextcache -a i386 -m "/Volumes/OSx86/Extra/Extensions.mkext" "/Volumes/OSx86/Extra/Stuff"

7. There will be some warnings. I ignored them.

8. (in terminal window type) cd ..

9. (in terminal window type) chmod -R 755 Extra

10. (in terminal window type) chown -R root:wheel Extra

11. (in terminal window type) diskutil repairPermissions /Volumes/OSx86

 

WORKS PERFECTLY my setup now successfully boots 9.7.0 w/ Chameleon 2.0!

 

You can even add other kexts to the 'stuff' folder and simply rebuild the mkext.

 

I tried reversing the process (mv Stuff Extensions) and it seems really odd that the bootloader can load kexts from 'Stuff' but can't from a folder named 'Extensions'

 

Anyway I'm glad SOMETHING has been worked out.

 

Also I am able to confirm that Mac4,1 is read from smbios.plist and Ram speed is read from the AppleSMBIOS.kext's Info.plist.

 

Gotta love bugs!

[digital_dreamer]

ahhhh, Too bad i just left the office or else i would have been testing this.

 

I'm gonna revert bios back to default and then do the changes I have logged in my notebook from initial boot up.

 

Aalways up this late, I need more than 24hrs a day.

 

Should I get off the voodoo 9.6.0 kernel? is the vanilla 9.7.0 or 9.6.3 more stable?

 

Thanks Digital_Dreamer, you the man!

I haven't had any issues with the newer vanilla kernels, but you'd need to use them with the new bootloader to get around the system clock issue.

Although I am using the 9.7.0 kernel, I personally feel the 9.6.0-based version (Voodoo, in this case) would be the most stable with 10.5.6, as it's designed with that OS version in mind. Version 9.6.3 is likely for 10.5.7 and 9.7.0 is for the yet unreleased Snow Leopard. There may be certain hooks or APIs that the newer versions rely upon for added functionality, which may cause some instability or KPs when in use. These issues would most certainly be the case if one were using, say, Snow Leopard, with an older kernel.

 

Guys, I need a hand for sure. It seems whatever I do, my system just wont work. I've been working on it for another 7 hours today, but no luck. I guess it's gonna be a long night again.

 

<snip>

neils,

What can I say? The description of your install sounds flawless.

The script does most of the work for you. It comes pre-configured for the Gigabyte UD5 board - with the exception of possible graphics drivers and/or graphics-related kexts. The kernel and its System.kext is also installed in its proper location, as well. The new script (released today) will install the System.kext into S/L/E. The packed mkext file is created and file permissions are repaired.

So, it's basically click and go.

Do you have AHCI enabled in your BIOS?

 

Okay. Here's the latest thing I'm trying to do in my quest to get the 4870 working fully with Digital Dreamer's scripted install. There is a certain recent natit.kext (as of April 22) which has been the subject of a number of success stories. My problem is that I apparently don't understand how to go about replacing Digital Dreamer's natit.kext (residing in /Extra/Extensions) with the newer natit.kext, which Kext Helper is told to place in /System/Library/Extensions. Replacing the natit.kext in the install package? Kernel panic. Deleting one and installing the other, after OSX installation? That doesn't seem to work. There must be some sort of post-fudging process that needs to be sorted out.

 

Anyway, that's what I'm after: The precise method of replacing an older /Extra/Extensions/natit.kext with a newer /System/Library/Extensions/natit.kext.

You got a kernel panic putting the updated Natit.kext in the _to_be_installed folder and installing it via script? Something doesn't sound right. I got a newer in there now. Try it out

 

best regards,

MAJ

[joeblough]

Are you saying I should delete the original mxkext before I run the suggested commands to create/modify the mkext ?

 

I'm gonna try that tomorrow.

 

The good news is, I ordered a nice and shiny 25,5 inch HP Monitor.

 

Thanks for you reply Joe !

 

no if you are regenerating it then you don't have to delete it first. of course since it was created the first time as superuser, when you recreate it you have to use sudo!

 

i was just wondering aloud if people who have added things to /Extra/Extensions still have /Extra/Extensions.mkext sitting there unmodified. in that case you could add 10,000 kexts to /Extra/Extensions and i'm pretty sure chameleon would not load them, because it sees /Extra/Extentions.mkext sitting there and always loads that instead of what's in /Extra/Extensions

[digital_dreamer]

WORKS PERFECTLY my setup now successfully boots 9.7.0 w/ Chameleon 2.0!

 

You can even add other kexts to the 'stuff' folder and simply rebuild the mkext.

 

I tried reversing the process (mv Stuff Extensions) and it seems really odd that the bootloader can load kexts from 'Stuff' but can't from a folder named 'Extensions'

 

Anyway I'm glad SOMETHING has been worked out.

 

Also I am able to confirm that Mac4,1 is read from smbios.plist and Ram speed is read from the AppleSMBIOS.kext's Info.plist.

 

Gotta love bugs!

So, when you reversed the process, with the Extensions folder loaded with the extensions again, the system was unstable or unpredictable?

 

If wonder if just deleting these kexts altogether, after the mkext is created, would be a solution, too?

 

Thanks for troubleshooting this, guys! (FUT1L1TY and Crash4419)

regards,

MAJ

[joeblough]

WORKS PERFECTLY my setup now successfully boots 9.7.0 w/ Chameleon 2.0!

 

You can even add other kexts to the 'stuff' folder and simply rebuild the mkext.

 

I tried reversing the process (mv Stuff Extensions) and it seems really odd that the bootloader can load kexts from 'Stuff' but can't from a folder named 'Extensions'

 

Anyway I'm glad SOMETHING has been worked out.

 

Also I am able to confirm that Mac4,1 is read from smbios.plist and Ram speed is read from the AppleSMBIOS.kext's Info.plist.

 

Gotta love bugs!

 

good news. i dont think the bootloader is loading anything from /Extra/Stuff. once you create /Extra/Extensions.mkext, that's what chameleon is going to load. if there are chameleon bugs they are that chameleon can't load a bunch of kexts from /Extra/Extensions and instead must be given a .mkext.

 

when you create the .mkext, it just doesnt matter what the folder is called that contains all of the kexts. all that matters is the .mkext file is named /Extra/Extensions.mkext.

[digital_dreamer]

no if you are regenerating it then you don't have to delete it first. of course since it was created the first time as superuser, when you recreate it you have to use sudo!

 

i was just wondering aloud if people who have added things to /Extra/Extensions still have /Extra/Extensions.mkext sitting there unmodified. in that case you could add 10,000 kexts to /Extra/Extensions and i'm pretty sure chameleon would not load them, because it sees /Extra/Extentions.mkext sitting there and always loads that instead of what's in /Extra/Extensions

Right. The mkext file doesn't rebuild automatically when the Extensions folder is modified, unlike the one in S/L.

This packed mkext file is supposed to become mandatory in Snow Leopard.

 

regards,

MAJ

[fuma]

Version 9.6.3 is likely for 10.5.7 and 9.7.0 is for the yet unreleased Snow Leopard.

 

The way I saw it unfold was kernel 9.6.3 was from the i7 macpro's shipping now (obviously running 10.5.6) - and whomever posted the 9.7.0 kernel got it from a beta release of 10.5.7... not 10.6 (thats a horse of a different color!)

 

either way, like I've stated 3 or 4 times in other posts... 9.7.0 kernel is not released yet and is a beta version for developers and it most likely will change once the REAL 10.5.7 update drops... So keep that in mind everyone that is jumping on this thinking "newer is better".

[digital_dreamer]

The way I saw it unfold was kernel 9.6.3 was from the i7 macpro's shipping now (obviously running 10.5.6) - and whomever posted the 9.7.0 kernel got it from a beta release of 10.5.7... not 10.6 (thats a horse of a different color!)

 

either way, like I've stated 3 or 4 times in other posts... 9.7.0 kernel is not released yet and is a beta version for developers and it most likely will change once the REAL 10.5.7 update drops... So keep that in mind everyone that is jumping on this thinking "newer is better".

Thanks for that correction!

 

MAJ

[digital_dreamer]

Guys, I need a hand for sure. It seems whatever I do, my system just wont work. I've been working on it for another 7 hours today, but no luck. I guess it's gonna be a long night again.

 

<SNIP>

neils,

When you work on your boot drive on another system, can you verify that the "Ignore ownership on this volume" is deselected/disabled?

(Get Info on volume)

 

regards,

MAJ

[digital_dreamer]

So, when you reversed the process, with the Extensions folder loaded with the extensions again, the system was unstable or unpredictable?

 

If wonder if just deleting these kexts altogether, after the mkext is created, would be a solution, too?

 

Thanks for troubleshooting this, guys! (FUT1L1TY and Crash4419)

regards,

MAJ

It appears this is not a uncommon solution.

 

Well, following up on this, I'm finding out it does appear to work better with no extensions/kexts in the extensions folder. I've reinstalled the vanilla System.kext in S/L/E on both installs (Chameleon v2.0 RC1 and v1012). Reworked installer to copy all kexts, including System.kext to /Extensions, create a boot cache file, then delete the kexts. (I have to do a copy to bring all the kexts from various locations to one central location to create a boot cache file.) System.kext appears to be loading - USB, Bluetooth, etc.

 

It would appear Chameleon gets confused when it has both a mkext file and the equivalent kexts in Extensions folder.

 

regards,

MAJ

[Asterra]

You got a kernel panic putting the updated Natit.kext in the _to_be_installed folder and installing it via script? Something doesn't sound right.

I probably messed something up. The natit.kext I put in the to_be_installed folder was not highlighted green (it was unpacked from a zip file) and I couldn't figure out the significance of that, or how to fix it, or whether it mattered.

 

I got a newer in there now. Try it out

Yep, gave it a whirl. For whatever reason, this release of the script results in an installation which I cannot boot. It reboots the pc the moment it leaves Chameleon.

 

Still, I was able to borrow the natit.kext from it, and use it in your older script (it was properly highlighted green). I've gotten this modification to install and boot. But the subsequent installation of the 47x0 drivers from the ATI "Simple Guide" thread still results in a Blue Flash Of Death. (Regardless of whether or not I uncheck the natit.kext which comes with the drivers.)

 

Incidentally, the new script's dialigue has given me some pause. After OSX has installed, one of the Y/n questions concerns whether I wish to replace the kernel. In the older script, the replacement kernal is not specified, and I assumed the replacement was basically required and the question was largely rhetorical - meaning what I thought it was doing was replacing the kernal with the most current, 9.7.0, which is presumably the most compatible with my 4870. But the dialogue in your most recent script is more specific: It asks if I wish to replace the kernal with 9.6.0.

 

This revelation leaves me with some more questions, but what I mainly don't understand is this: How can I get your older script (which works in my case) to install the 9.7.0 kernel, which I assume I'd better have if I want my 4870 to work fully? Just take it for granted that I'm too stupid to figure it out using your script. ;p

 

Edit: Incidentally, I suspect that the reason your latest script gives me an unbootable installation may be because it is not installing 0.9.7, or perhaps something I am doing is overriding the installation of 0.9.7. Is there some specific step one has to take (or skip) in order to ensure 0.9.7 gets installed?

[Crash4419]

It appears this is not a uncommon solution.

 

Well, following up on this, I'm finding out it does appear to work better with no extensions/kexts in the extensions folder. I've reinstalled the vanilla System.kext in S/L/E on both installs (Chameleon v2.0 RC1 and v1012). Reworked installer to copy all kexts, including System.kext to /Extensions, create a boot cache file, then delete the kexts. (I have to do a copy to bring all the kexts from various locations to one central location to create a boot cache file.) System.kext appears to be loading - USB, Bluetooth, etc.

 

It would appear Chameleon gets confused when it has both a mkext file and the equivalent kexts in Extensions folder.

 

regards,

MAJ

 

So in theory a system should boot with Kexts in /Extra/Extensions and NO mkext?

 

Now I seem a bit confused about WHICH kexts are going to be used. You mention that you copy all VANILLA kexts to /Extensions and then create a mkext in /Extra? But isn't the whole point of /Extra is to keep the hacked kexts separate? Why would you want the Vanilla kext?

 

Also DD, I think you should start date stamping the X58 Installer Zip's.

[@ROBASEFR]

yes, probably your system wall clock is running fast now. do the icons bounce really fast in the dock? if you watch the clock in the system preferences, is the second hand racing around the dial?

 

if the system timebase is off then results of benchmarking programs are going to be wrong.

 

 

Thanks for your reply ! Indeed system wall clock is running fast now !

 

Got back to voodoo kernel 9.6.

(I didn't install Chameleon 2.0 Rc1 yet )

 

Waiting for stable 9.7 voodoo kernel and 10.5.7 update

 

Geekbench is back too 10700 now !

[joeblough]

It appears this is not a uncommon solution.

 

Well, following up on this, I'm finding out it does appear to work better with no extensions/kexts in the extensions folder. I've reinstalled the vanilla System.kext in S/L/E on both installs (Chameleon v2.0 RC1 and v1012). Reworked installer to copy all kexts, including System.kext to /Extensions, create a boot cache file, then delete the kexts. (I have to do a copy to bring all the kexts from various locations to one central location to create a boot cache file.) System.kext appears to be loading - USB, Bluetooth, etc.

 

It would appear Chameleon gets confused when it has both a mkext file and the equivalent kexts in Extensions folder.

 

regards,

MAJ

 

can you just copy the kexts to a directory not called Extensions? its really useful to have the .kexts around in extra in case you need to add something and re-make the mkext. if we use this new script we have to go digging around in your directories to find the kexts, and its not clear from the directory structure which ones you install... and of course you have named the directory with a tilde which makes it hard for noobs to get into that directory from the shell...

[iTestTube]

Also DD, I think you should start date stamping the X58 Installer Zip's.

 

Concur with Crash4419. Versions w/date stamps of your script would be a welcome feature.

 

The development process is moving at a pretty rapid pace.

 

iTT

[mrmacintosh31]

Could it be possible to split EX85-UD5 + vanilla kernel conversation to a completely new thread and leave this thread for voodoo based installations ?

 

It seems that now there is 3 different install methods in this single thread it is quite confusing to everybody, you never know what method people used when they discuss about problems they have. It would also help new people just starting up with their first installations. Now the information about specific methods of installation gets lost in a flood of messages.

[mattpeufpeuf]

Is it possible to have a link for boot132.iso special for ud-5??

[digital_dreamer]

I probably messed something up. The natit.kext I put in the to_be_installed folder was not highlighted green (it was unpacked from a zip file) and I couldn't figure out the significance of that, or how to fix it, or whether it mattered.

 

 

Yep, gave it a whirl. For whatever reason, this release of the script results in an installation which I cannot boot. It reboots the pc the moment it leaves Chameleon.

 

Still, I was able to borrow the natit.kext from it, and use it in your older script (it was properly highlighted green). I've gotten this modification to install and boot. But the subsequent installation of the 47x0 drivers from the ATI "Simple Guide" thread still results in a Blue Flash Of Death. (Regardless of whether or not I uncheck the natit.kext which comes with the drivers.)

 

Incidentally, the new script's dialigue has given me some pause. After OSX has installed, one of the Y/n questions concerns whether I wish to replace the kernel. In the older script, the replacement kernal is not specified, and I assumed the replacement was basically required and the question was largely rhetorical - meaning what I thought it was doing was replacing the kernal with the most current, 9.7.0, which is presumably the most compatible with my 4870. But the dialogue in your most recent script is more specific: It asks if I wish to replace the kernal with 9.6.0.

 

This revelation leaves me with some more questions, but what I mainly don't understand is this: How can I get your older script (which works in my case) to install the 9.7.0 kernel, which I assume I'd better have if I want my 4870 to work fully? Just take it for granted that I'm too stupid to figure it out using your script. ;p

 

Edit: Incidentally, I suspect that the reason your latest script gives me an unbootable installation may be because it is not installing 0.9.7, or perhaps something I am doing is overriding the installation of 0.9.7. Is there some specific step one has to take (or skip) in order to ensure 0.9.7 gets installed?

The kernel and System.kext that's directly inside the "Kernels" folder are the one that will be installed. The others inside their parent folders are ignored.

The reason the option is given to skip the kernel install is this:

1) I assumed there would be some who wished to skip this installation,

2) In preparation for 10.5.7, which will be released shortly and will contain a compatible vanilla kernel, the user may wish to not replace the installed kernel.

3) Eventually, when 10.5.7 has gathered a significant foothold in our userbase, I may remove that option, with the expectation that all users of the script install 10.5.7.

However, I now realize that some may still desire to use the older bootloader and, hence, the Voodoo kernel.

 

I assume that the failure of the new script may be because it installed the 9.6.0 kernel, which required a busratio=20 kernel flag that it did not receive.

 

I really tried to cover all the bases, but it appears trying to become more flexible and provide more options for some, leaves confusion and failure for others if those features are not fully understood.

 

Let me know what you think.

 

can you just copy the kexts to a directory not called Extensions? its really useful to have the .kexts around in extra in case you need to add something and re-make the mkext. if we use this new script we have to go digging around in your directories to find the kexts, and its not clear from the directory structure which ones you install... and of course you have named the directory with a tilde which makes it hard for noobs to get into that directory from the shell...

I can do that if you wish.

I thought I made it rather clear from the very beginning which kexts get installed from the kexts. It's not difficult to discern. Additionally, I split the structure up to make it clear what kexts are for what purpose, as some were confused regarding which they should remove/replace.

Thank you for your input.

 

Concur with Crash4419. Versions w/date stamps of your script would be a welcome feature.

 

The development process is moving at a pretty rapid pace.

 

iTT

Sure. I do, however, date stamp my download links and update the version # of the script.

If that's not enough, then let me know what else I should do. <sigh>

 

Could it be possible to split EX85-UD5 + vanilla kernel conversation to a completely new thread and leave this thread for voodoo based installations ?

 

It seems that now there is 3 different install methods in this single thread it is quite confusing to everybody, you never know what method people used when they discuss about problems they have. It would also help new people just starting up with their first installations. Now the information about specific methods of installation gets lost in a flood of messages.

No kidding.

[joeblough]

I can do that if you wish.

I thought I made it rather clear from the very beginning which kexts get installed from the kexts. It's not difficult to discern. Additionally, I split the structure up to make it clear what kexts are for what purpose, as some were confused regarding which they should remove/replace.

Thank you for your input.

 

i was wrong about where the kexts are inside your installer. i guess i was confused, obviously _to_install/ is self explanatory but i didnt understand what the stuff in _repository/ was for.

 

anyway i can just hack the script to not delete the /Extra/Extensions directory, its no big deal.