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

[Crash4419]

Okay easy enough.

 

In the next release of the installer package the SMproductname should come pre-modified as MacPro4,1

[bernito]

Does the new 9.7 kernal you posted work with Wolfienuke's boot from EFI install? So you know how to get Chameleon 2.0 to work with that method? Is it possible to run VMWare Fusion (I get a kernal panic everytime I lauch it)?

 

My Wolfie install is working beautifully so don't want to screw it up! Thanks as always for you assistance and excellent work!

[tgintheworld]

Does the new 9.7 kernal you posted work with Wolfienuke's boot from EFI install? So you know how to get Chameleon 2.0 to work with that method? Is it possible to run VMWare Fusion (I get a kernal panic everytime I lauch it)?

 

My Wolfie install is working beautifully so don't want to screw it up! Thanks as always for you assistance and excellent work!

 

I was able to boot with Wolfienuke's EFI-Partition script and the new 9.7.0 kernel and System.kext, but I needed some additional kexts to get it to work. I will post a step-by-step of what I did to get it to work later tonight, including all the kexts I used. I got netflix to work too, which I was happy about.

 

My question now is: which is the superior method for install with regards to maintaining an install that works right and updates easily? DD's new script or the EFI Parition method? Or is it the case that DD's new script utilizes the EFI Partition and stores the modded kexts there in case an update blows away needed kexts on the system drive?

[boogusboy]

Does the new 9.7 kernal you posted work with Wolfienuke's boot from EFI install? So you know how to get Chameleon 2.0 to work with that method? Is it possible to run VMWare Fusion (I get a kernal panic everytime I lauch it)?

 

My Wolfie install is working beautifully so don't want to screw it up! Thanks as always for you assistance and excellent work!

 

 

I fixed the VMWare issue by making sure the kernel in my EFI parition and /mach_kernel in the root of the retail partition were the same. I'm not sure if that fixes it with Voodoo Kernel, but it does with Vanilla.

[mangopeach]

dang it. I had everything working (except sleep) with the 4/22 update.. so I decided to delete all the s/l/e colored kexts and replaced them with the vanilla ones. Then i ran the patcher and installed the boot loader, 9.7 kernel, post patcher, etc. Then I reboot and when i tried to boot into that disk it KP'd right away. I dont know how to repair permissions in terminal for a different disk. Since the only drive now working is the distro drive, what is the terminal command to repair permissions for the other volume (retail install)?

 

--edit--

nevermind - i'm just starting over. wish me luck.

[neils]

Wolfienuke's kexts are specifically designed with the UD5 board in mind. Off hand, I don't know the what the differences are in the two mobos, but I'm sure it wouldn't be enough to prevent the system from booting.

What we need is the photo of the on-screen log. That will help a lot!

 

Best of wishes,

MAJ

 

 

MAJ

 

Ok. I reinstalled my retail copy of OSX using your script DD. I formatted the Disk again, and used the GUI option. It all seemed to install well, but again (ofcourse) it hangs on bootup. Chameleon however boots up just fine, it can see all 3 partitions. (I created 3 partitions, I installed OSX on the first partition)

 

Here's a printscreen of what I see. Many thanks in advance again ! I wont give up !

 

(btw, the UD4-P is almost exactly the same compared to the UD5. Same chipset, same soundchip, same lan, the biggest difference is the UD4-P only has one LAN-port.)

Wolfienuke's kexts are specifically designed with the UD5 board in mind. Off hand, I don't know the what the differences are in the two mobos, but I'm sure it wouldn't be enough to prevent the system from booting.

What we need is the photo of the on-screen log. That will help a lot!

 

Best of wishes,

MAJ

 

 

MAJ

 

Ok. I reinstalled my retail copy of OSX using your script DD. I formatted the Disk again, and used the GUI option. It all seemed to install well, but again (ofcourse) it hangs on bootup. Chameleon however boots up just fine, it can see all 3 partitions. (I created 3 partitions, I installed OSX on the first partition)

 

Here's a printscreen of what I see. Many thanks in advance again ! I wont give up !

 

(btw, the UD4-P is almost exactly the same compared to the UD5. Same chipset, same soundchip, same lan, the biggest difference is the UD4-P only has one LAN-port.)

 

For your information DD, I didn't use wolfies method. I exactly followed your instructions.

 

Btw, on the hardware side, I have 3 sticks of 2 GB Corsair Dominator 1600 MHZ Memory. I can't seem to let it run on 1.65 v and 1600 mhz. My BIOS defaults the memory on 1033 mhz and undervolts it. Could this perhaps be the problem ? I've tried to configure the memory properly, but I can't get it to 1600 mhz and the 1.65 stock voltage.

[Hakintos]

well when you are entering a password, the system does not echo it back to you so someone can not read your password over your shoulder!

 

just type your password and press return, it will work. this is normal behavior for any unix command line system.

 

If it works. Thank you

[digital_dreamer]

Thanks to Digital Dreamer's script, I am now about 50% done with the whole "install OSX" thing. Rather amazing for only 24 hours of fudging. Anyway, since I don't think anyone else has mentioned this particular panic in this thread, here's where mine craps out. (This is while booting a drive that has vanilla OSX 10.5.6 transparently patched by Digital Dreamer's script, using option 1 and selecting "Yes" at all prompts.)

 

panic(cpu 0 caller 0x004384FF): "Unable to find driver for this platform: \"ACPI\".\n"@/SourceCache/xnu/xnu-1228.12.24/iokit/Kernel/IOPlatformExpert.cpp:1407

 

I can type the rest if it's somehow elucidating. No real idea what I can do to troubleshoot this so there it is. My hardware: Gigabyte UD5, i7 920, SB Audigy2ZS, Sapphire HD4870, WD Caviar 640GB SATA, Pioneer 216 dvd-rom. Settings: 1 core, no hyperthreading, most things disabled.

 

Suggestions? Anyone familiar with this kernel panic? ;p

Hmmm. Try running File Permission Repair in Disk Utility on that volume. Make sure there are 14 kexts in /Extra/Extensions and that there is a .mkext file in /Extra. Double-check your boot.plist there, as well. You might want to just delete all the keys except the kernel and kernel flags to keep it simple, add the UUID of your drive to your boot.plist in Extra using the script (very easy).

 

@DD

 

your script is great everything except my Video card is running great...

 

I like to add a gfx string for my video card....but I don't no where to put this string...

 

Do I have to put it in the boot.plist in the extra folder?

 

Thanks for your help.

LEN

Yes, put it in the boot.plist in Extra. Don't use the script, as I haven't figured out a way to input over 1022 characters.

<key>device-properties</key>
<string>EFI string here</string>

I was able to boot with Wolfienuke's EFI-Partition script and the new 9.7.0 kernel and System.kext, but I needed some additional kexts to get it to work. I will post a step-by-step of what I did to get it to work later tonight, including all the kexts I used. I got netflix to work too, which I was happy about.

 

My question now is: which is the superior method for install with regards to maintaining an install that works right and updates easily? DD's new script or the EFI Parition method? Or is it the case that DD's new script utilizes the EFI Partition and stores the modded kexts there in case an update blows away needed kexts on the system drive?

Technically, both are the same (use the exact same kexts), except one stores the kexts in the EFI partition and the other stores them on the boot drive. Both methods could utilize the same bootloader, so that issue is moot. It think it comes down to managability and visibility:

Boot from EFI:

Pros: A system install that looks like a genuine Mac install, with no visible evidence of patches.

Cons: Harder to manage or keep track of, as the EFI partition is typically invisible and not easily accessible without the Terminal.

 

Boot from Extra directory on boot drive:

Pros: Visible and easily accessible install files makes management a cinch.

Cons: Some may not find it desirable for such patches to be visible.

 

dang it. I had everything working (except sleep) with the 4/22 update.. so I decided to delete all the s/l/e colored kexts and replaced them with the vanilla ones. Then i ran the patcher and installed the boot loader, 9.7 kernel, post patcher, etc. Then I reboot and when i tried to boot into that disk it KP'd right away. I dont know how to repair permissions in terminal for a different disk. Since the only drive now working is the distro drive, what is the terminal command to repair permissions for the other volume (retail install)?

Sorry about that.

You can run permissions repair on any volume from Disk Utility.

For what it's worth, here's the Terminal command:

diskutil repairpermissions /Volumes/YOUR_HARD_DRIVE

Ok. I reinstalled my retail copy of OSX using your script DD. I formatted the Disk again, and used the GUI option. It all seemed to install well, but again (ofcourse) it hangs on bootup. Chameleon however boots up just fine, it can see all 3 partitions. (I created 3 partitions, I installed OSX on the first partition)

 

Here's a printscreen of what I see. Many thanks in advance again ! I wont give up !

 

(btw, the UD4-P is almost exactly the same compared to the UD5. Same chipset, same soundchip, same lan, the biggest difference is the UD4-P only has one LAN-port.)

I ran into that several times myself. Seems to be a common panic screen. Note my comments above regarding this issue.

 

regards,

MAJ

 

Does the new 9.7 kernal you posted work with Wolfienuke's boot from EFI install? So you know how to get Chameleon 2.0 to work with that method? Is it possible to run VMWare Fusion (I get a kernal panic everytime I lauch it)?

 

My Wolfie install is working beautifully so don't want to screw it up! Thanks as always for you assistance and excellent work!

You should be able to just put the new kernel in his Kernels folder and the matching System.kext in his Extensions folder, taking care to preserve the originals for backup. If you are using a "saved" boot.plist that's in the script folder, make sure the kernel name in the plist does not have ".voodoo" on the end.

 

dang it. I had everything working (except sleep) with the 4/22 update.. so I decided to delete all the s/l/e colored kexts and replaced them with the vanilla ones. Then i ran the patcher and installed the boot loader, 9.7 kernel, post patcher, etc. Then I reboot and when i tried to boot into that disk it KP'd right away. I dont know how to repair permissions in terminal for a different disk. Since the only drive now working is the distro drive, what is the terminal command to repair permissions for the other volume (retail install)?

 

--edit--

nevermind - i'm just starting over. wish me luck.

 

Ok. I reinstalled my retail copy of OSX using your script DD. I formatted the Disk again, and used the GUI option. It all seemed to install well, but again (ofcourse) it hangs on bootup. Chameleon however boots up just fine, it can see all 3 partitions. (I created 3 partitions, I installed OSX on the first partition)

 

Here's a printscreen of what I see. Many thanks in advance again ! I wont give up !

 

(btw, the UD4-P is almost exactly the same compared to the UD5. Same chipset, same soundchip, same lan, the biggest difference is the UD4-P only has one LAN-port.)

Ok. I reinstalled my retail copy of OSX using your script DD. I formatted the Disk again, and used the GUI option. It all seemed to install well, but again (ofcourse) it hangs on bootup. Chameleon however boots up just fine, it can see all 3 partitions. (I created 3 partitions, I installed OSX on the first partition)

 

Here's a printscreen of what I see. Many thanks in advance again ! I wont give up !

 

(btw, the UD4-P is almost exactly the same compared to the UD5. Same chipset, same soundchip, same lan, the biggest difference is the UD4-P only has one LAN-port.)

 

For your information DD, I didn't use wolfies method. I exactly followed your instructions.

 

Btw, on the hardware side, I have 3 sticks of 2 GB Corsair Dominator 1600 MHZ Memory. I can't seem to let it run on 1.65 v and 1600 mhz. My BIOS defaults the memory on 1033 mhz and undervolts it. Could this perhaps be the problem ? I've tried to configure the memory properly, but I can't get it to 1600 mhz and the 1.65 stock voltage.

Those memory issues won't be related to the booting issues. I wouldn't worry about running it at 1033MHz for now, but what voltage is the RAM?

Try the suggestions I offered a few posts above. I think you're close.

 

If it works. Thank you

LOL! You got it!

So, does that mean you got the system running, or that you got the script running? :

 

 

I had my system sleeping most of the day today while I was at work. It woke on a phone call. No problems.

I might mention that when I installed the new setup on the previous EFI boot setup, I had to erase the EFI partition. Otherwise, the old bootloader kept interfering, even though I had "activated" the other partition.

So, if your going from EFI boot to this setup, you'll have to erase that EFI partition too.

This is very dangerous to do, as a simple mistake you will erase the wrong partition. I'll take no responsibilities for any issues.

Look in Disk Utility or do a diskutil list in Terminal to determine your disk number and partition number. (Get this right!!)

Then do the following in Terminal, replacing the first X with disk number and second X with partition number.

diskutil eraseVolume "HFS+" "EFI" diskXsX

 

NOTE: It would be a good idea to determine your new setup is bootable before erasing the EFI partition. That might be only possible if you have another install with the Cham2 bootloader, which can utilize the Extra directory.

 

EXTRA NOTE: I just want to say that I'm not endorsing this setup over boot from EFI - it just happens to be my preference. I don't suggest those with EFI boot setups to bend over backwards to get this setup going, as it may not offer any advantages other than visibility. I know many want to run the new bootloader and, currently, this setup is the only setup I'm supporting in my script that features the new bootloader. I don't think I plan on supporting EFI boot. But, if I get really bored and don't have anything else to do, I might go ahead and support it. But, for now, this setup is as good as EFI boot from a technical point of view, but more visible to the user and offers a new GUI bootloader.

 

 

regards,

MAJ

[neils]

Hi DD,

 

What do you mean with comments above? I've read this whole thread, but I have no clue what to try next.

 

Repair permissions ? Should I add the UUID of my harddisk ? Since my boot parttion is recognized properly ? Please give me a hint about what to try next.

 

Thankx !

[tgintheworld]

Technically, both are the same (use the exact same kexts), except one stores the kexts in the EFI partition and the other stores them on the boot drive. Both methods could utilize the same bootloader, so that issue is moot. It think it comes down to managability and visibility:

Boot from EFI:

Pros: A system install that looks like a genuine Mac install, with no visible evidence of patches.

Cons: Harder to manage or keep track of, as the EFI partition is typically invisible and not easily accessible without the Terminal.

 

Boot from Extra directory on boot drive:

Pros: Visible and easily accessible install files makes management a cinch.

Cons: Some may not find it desirable for such patches to be visible.

 

...

 

EXTRA NOTE: I just want to say that I'm not endorsing this setup over boot from EFI - it just happens to be my preference. I don't suggest those with EFI boot setups to bend over backwards to get this setup going, as it may not offer any advantages other than visibility. I know many want to run the new bootloader and, currently, this setup is the only setup I'm supporting in my script that features the new bootloader. I don't think I plan on supporting EFI boot. But, if I get really bored and don't have anything else to do, I might go ahead and support it. But, for now, this setup is as good as EFI boot from a technical point of view, but more visible to the user and offers a new GUI bootloader.

 

Hi MAJ,

 

I have to thank you again for all the hard work you've put into this. If you ever get bored of your job, I'm sure GIGABYTE would hire you as a salesperson

 

I guess I was more asking whether one setup was preferable over another in terms of long-term stability. If Apple puts out an update that hoses the system somehow, I know that with EFI-Partition, I'll be able to boot with a -f flag and it will rebuild my kexts with those I know work, and I don't really need another maintenance install for this to work.

 

In a similar situation with your script (an update hosing the install), is there a way to recover without using a maintenance drive?

 

regards,

TGITW

[digital_dreamer]

Hi DD,

 

What do you mean with comments above? I've read this whole thread, but I have no clue what to try next.

 

Repair permissions ? Should I add the UUID of my harddisk ? Since my boot parttion is recognized properly ? Please give me a hint about what to try next.

 

Thankx !

That panic screen is what happens when you try to boot a vanilla install without patches. It looks like the bootloader is not loading the mkext file (packed version of Extensions) in /Extra. It stalls on the AppleIntelCPUPowerManagement.kext, which should be blacklisted by the Disabler.kext. I ran into that a few times, but just kept reinstalling the kexts and making sure they were all there.

I actually think there's some bug in the bootloader that causes it not to see this .mkext at first. But, when it does see it, it's boots every time from that point on. Try booting with the -F flag.

 

Hi MAJ,

 

I have to thank you again for all the hard work you've put into this. If you ever get bored of your job, I'm sure GIGABYTE would hire you as a salesperson

 

I guess I was more asking whether one setup was preferable over another in terms of long-term stability. If Apple puts out an update that hoses the system somehow, I know that with EFI-Partition, I'll be able to boot with a -f flag and it will rebuild my kexts with those I know work, and I don't really need another maintenance install for this to work.

 

In a similar situation with your script (an update hosing the install), is there a way to recover without using a maintenance drive?

 

regards,

TGITW

Without a maintenance drive would be incredibly difficult. If you know what kext(s) are involved, one could safe boot and run the Terminal and do the work from there, but that's not for the faint of heart.

 

I don't foresee Apple releasing an update that would cause boot failure on our systems. There may be failure of various subsystems, but not a wholesale boot failure. The community has shown itself to be very keen on OS X development changes and has tried to stay, at least, one step ahead. Witness the DSDT patch. Although it hasn't happened yet, we as a community have already implemented a DSDT patch in response to a future OS upgrade that will require it.

 

Both methods (EFI boot and boot from Extra) are vulnerable in the exact same way - it would take an installer overwriting the directories (improbable, especially for EFI boot) or releasing a major update that changes the way our patches work. Neither of these methods are vulnerable to overwritten patches, like the standard boot-132 setup that I had been using until yesterday.

 

Best regards,

MAJ

[joeblough]

I had my system sleeping most of the day today while I was at work. It woke on a phone call. No problems.

 

i'm glad i'm not the only one. i think this board has some serious EMI susceptibility problems. it woke up when my iphone received a text message, and the iphone was not even connected to the machine! i dont have my case all sealed up yet, though.

[digital_dreamer]

i'm glad i'm not the only one. i think this board has some serious EMI susceptibility problems. it woke up when my iphone received a text message, and the iphone was not even connected to the machine! i dont have my case all sealed up yet, though.

Well, I forgot to mention I have "wake on modem ring" turn on.

I try to grab the caller ID on wake, but it's apparently not quick enough. Oh, well.

 

My box is not sealed up, either. Need to clean it all up and make it look nice. Then, we can have a Core i7 CPU picture thread.

 

regards,

MAJ

[airwalk776]

Maj

 

I attempted to install 9.7.0 and the System.kext that goes with it from your earlier post. After doing so the system goes into a constant reboot. I was able to recover from this by booting with the ideneb dvd and launching terminal and restoring the old System.kext and Mach_kernel then rebooted and I am back to 9.6.0 voodoo.

 

 

I attempted to install 9.7.0 using OSX86Tools (also used for System.kext.) Is this not the correct way to install?

 

Am I missing anything ?

 

Thanks

[Asterra]

Hmmm. Try running File Permission Repair in Disk Utility on that volume. Make sure there are 14 kexts in /Extra/Extensions and that there is a .mkext file in /Extra. Double-check your boot.plist there, as well. You might want to just delete all the keys except the kernel and kernel flags to keep it simple, add the UUID of your drive to your boot.plist in Extra using the script (very easy).

Thanks for the tips. It can't be argued that this isn't a learning experience.

 

File Permission Repair is greyed out (Verify and Repair both say all is okay). There are 14 kexts in /Extra/Extensions and a .mktext in /Extra. I first added the UUID string to the Kernel Flags (verifying many times that it was typed in correctly). Same result. Then I removed all keys besides Kernal and Kernal flags. This time, Chameleon offered me a boot choice: My Kalyway drive or the vanilla drive (originally, it gave a blue countdown bar for about 20 seconds). Upon selecting the vanilla drive, same kernal panic. Then I eliminated the only other Kernal Flags strings (concerning the ram). Same. Finally, I tried adding "busratio=20", as I recalled it was supposed to be needed for the i7 920. But the same problem persisted anyway.

 

Yeah, I pretty much don't have a clue what to try next.

 

Update: File Permission Repair reportedly can only be done on the boot disc. If that's the case, then I can't fathom how I'll be able to use it on a drive that won't boot...

Update2: I think I may have identified something rather fundamentally wrong with my install. Namely, the vanilla install drive has only ~200 mb on it. I had thought that the script would spot the mounted OSX iso and utilize it in its automated process (or else notify the user that it had failed to find an OSX to install). Now to figure out how to force it to install OSX.

 

Update3: Got it installed. It locks up after defaulting to full-secure for FireWire. Gives me the "Still waiting for root device" issue. The only thing wrong with the drive or its install was "group differs on mach_kernal, should be 0". It was at 80. I went ahead and repaired that, but it made no difference. Does anyone know just what this waiting-for-root-device issue is?

[digital_dreamer]

Maj

 

I attempted to install 9.7.0 and the System.kext that goes with it from your earlier post. After doing so the system goes into a constant reboot. I was able to recover from this by booting with the ideneb dvd and launching terminal and restoring the old System.kext and Mach_kernel then rebooted and I am back to 9.6.0 voodoo.

I attempted to install 9.7.0 using OSX86Tools (also used for System.kext.) Is this not the correct way to install?

 

Am I missing anything ?

 

Thanks

OSX86Tools would be okay.

I don't know what to say other than that it wasn't installed properly. File permissions are critical and updating the boot cache is mandatory. Kexts stored in S/L/E generally will get a automatic boot cache update. But, kexts stored elsewhere have to have the mkext updated manually.

 

Thanks for the tips. It can't be argued that this isn't a learning experience.

 

File Permission Repair is greyed out (Verify and Repair both say all is okay). There are 14 kexts in /Extra/Extensions and a .mktext in /Extra. I first added the UUID string to the Kernel Flags (verifying many times that it was typed in correctly). Same result. Then I removed all keys besides Kernal and Kernal flags. This time, Chameleon offered me a boot choice: My Kalyway drive or the vanilla drive (originally, it gave a blue countdown bar for about 20 seconds). Upon selecting the vanilla drive, same kernal panic. Then I eliminated the only other Kernal Flags strings (concerning the ram). Same. Finally, I tried adding "busratio=20", as I recalled it was supposed to be needed for the i7 920. But the same problem persisted anyway.

 

Yeah, I pretty much don't have a clue what to try next.

 

Update: File Permission Repair reportedly can only be done on the boot disc. If that's the case, then I can't fathom how I'll be able to use it on a drive that won't boot...

Update2: I think I may have identified something rather fundamentally wrong with my install. Namely, the vanilla install drive has only ~200 mb on it. I had thought that the script would spot the mounted OSX iso and utilize it in its automated process (or else notify the user that it had failed to find an OSX to install). Now to figure out how to force it to install OSX.

 

Update3: Got it installed. It locks up after defaulting to full-secure for FireWire. Gives me the "Still waiting for root device" issue. The only thing wrong with the drive or its install was "group differs on mach_kernal, should be 0". It was at 80. I went ahead and repaired that, but it made no difference. Does anyone know just what this waiting-for-root-device issue is?

The fact that Repair Permissions was grayed-out would have been a clue that no valid OS was installed on that partition.

The script isn't going to install OS X on its own. All it does is launch the installer from a mounted DVD, because that part can be rather tricky (You want to avoid the reboot stage that normally kicks in when you double-click the installer, so the script launches a child installer buried deep in the DVD that's hard to get to without the Terminal.)

 

Okay, I'm getting your latest update.

Waiting for root device.. Now we haven't heard that in a long time.

The sound is still ringing in the ears. There are a lot of issues that can contribute to the wait error. It basically means it hasn't got all the information it needs to go on. What graphics card are you using and what graphics related kexts do you have installed?

 

regards,

MAJ

[joeblough]

Well, I forgot to mention I have "wake on modem ring" turn on.

I try to grab the caller ID on wake, but it's apparently not quick enough. Oh, well.

 

My box is not sealed up, either. Need to clean it all up and make it look nice. Then, we can have a Core i7 CPU picture thread.

 

regards,

MAJ

 

ah. well i'm not winning any prizes here. this setup is going into my crappy cooler master case and evicting the venerable badaxe2. i think i'm going to wait for 10.5.7 to drop first though.

[Asterra]

Waiting for root device.. Now we haven't heard that in a long time.

What can I say? I'm a noob. ;p

What graphics card are you using and what graphics related kexts do you have installed?

Ah, here we go. No doubt that is the issue. I'm using a 4870 and I do understand that support for said card is something that was basically borrowed from the as-yet-unreleased 10.5.7. Don't think I have it handy (I'll hunt), and I think I also read that installing the kext may involve a program called Kext Helper. I will attend to that shortly, assuming I can find the kext.

 

I've also got a SB Audigy 2 ZS, if that is expected to cause more issues.

[mangopeach]

My setup looks so cheesy in this "I went to fry's to make a bling gaming pc" way that makes me chuckle. It's like a bmw with sheet metal made to look like a ford focus. But hey it stays cool and was only a grand for 13k geekbench.

[Asterra]

Well, the 48xx kext link is dead, and the how-to guide which discusses QE/CI takes it for granted that one already has their OSX working. It does provide a link to a file called 7_radeon_hd_48x0_drivers.pkg (among other things), which presumably contains the kexts I need, but I can't figure out how to unarchive it. ("7_radeon.pkg is used by OSX and cannot be opened." or "Operation could not be completed (com.apple.installer.pagecontroller error 01.)") I'm at a loss.

[L3B3R]

Well, the 48xx kext link is dead, and the how-to guide which discusses QE/CI takes it for granted that one already has their OSX working. It does provide a link to a file called 7_radeon_hd_48x0_drivers.pkg (among other things), which presumably contains the kexts I need, but I can't figure out how to unarchive it. ("7_radeon.pkg is used by OSX and cannot be opened." or "Operation could not be completed (com.apple.installer.pagecontroller error 01.)") I'm at a loss.

Are you following this guide?

 

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

 

Run the .pkg from your "backup" system onto your main system by selecting the appropriate drive when prompted. Then grab the kext that is listed and use that in your script. Make sure to follow the instructions on the other thread. Video should now be working. If QE is not, then you need to download the new framework as listed and follow the instructions.

[Asterra]

Run the .pkg from your "backup" system onto your main system by selecting the appropriate drive when prompted.

What would you advise if all attempts to run the .pkg with Installer (3.0.1 and/or 3.0.2) produces this error: "Operation could not be completed (com.apple.installer.pagecontroller error -1.)"?

 

Update: Sigh, never mind. The file had gotten renamed (truncated) during its trip from pc -> cd-rom -> mac, and I hadn't been aware that that made a difference as to whether it can still be used. Still baffled by it, in fact.

[Asterra]

Okay, followed the 48x0 guide to get kexts installed on the correct drive. Did not prevent the "Still waiting for root device" issue. One fellow in another thread suggested that this message pops up when one doesn't have the correct chipset driver for their Southbridge. But since I used Digital Dreamer's script specifically designed for the hardware I have (UD5), I have to consider that unlikely.

 

Anyway, this time I really am out of options, heh.

[Boeing 737]

Hi all,

 

Anyone have the HotPlug USB issue with kernel 9.6.3 and 9.7.0 ? it don't recognize my USB hard disk even my Iphone when hotplug. No problem with voodoo kernel.

 

Thank's all.

 

Regards.

 

B737

[walterav]

post nr 630 old thread:

 

jmicron 322 trouble

The jmicron controller is a real {censored}, there are four ports, only 'one device' at a 'group of ports' works in "OSX" and is supported for boot.

jm 01,0=bootharddisk

jm 23,0=dvd-drive

adding a second device on jm 01,1=

#"green/blue colored GIGABYTE-sata menu during boot reports 'only' the device on 01,0" bios does see all the device! not in OSX "maybe in windows?"

adding a second device on jm 23,1=

#"green/blue colored GIGABYTE-sata menu during boot reports 'only' the device on 23,0" bios does see all the device! not in OSX "maybe in windows?"

total of 4 devices don't work only the 2 of the 4 that are on 0 port,"closest to motherboard" work in osx

 

plot:

the bios detects multiple devices, the devices that are coloured "green" during post will boot and will be shown in osx, haven't tested ubuntu or xp.

 

or newer osx versions yet