Jump to content
InsanelyMac Forum


  • Content count

  • Joined

  • Last visited

About nabziF99

  • Rank
    InsanelyMac Protégé
  1. Update: success! Indeed the problem was relatively simple: Clover's config.plist was a "mess", wreaking havoc with toleda's script, as he pointed out. Changing config.plist/Devices/Audio/#Inject/0x0887 to config.plist/Devices/Audio/Inject/1 allowed the script to work its magic. (Apparently pound signs are used to comment lines out, and Clover's default config starts out with basically everything commented out. Not sure what's with the default value of 0x0887, but that's a question for another place.)
  2. VirusX, thanks for the response! However I'm still stuck; I installed Clover on the hard drive, it seems to boot ok (though it would spontaneously reboot itself until I added NullCPUPowerManagement.kext). But I'm still getting the error from my previous post when running audio_cloverALC-110_v1.0f.command: EFI partition is mounted Boot/Arguments = kext-dev-mode=1 found Error: no IOReg/HDEF; BIOS/audio/disabled or ACPI problem No system files were changed Did I miss something? The only thing in my BIOS settings I see regarding audio is Integrated Peripherals->Azalia Codec->Auto...does that sound right? Toleda's troubleshooting guide leads to more steps that you didn't mention (stuff about adding HDEF, dsdt, ssdt, etc), that seems to have a dead end, so I figured maybe it's something wonky in the Clover config.plist I'm using. So I replaced it with the fresh vanilla config.plist the Clover installer created, rebooted, ran cloverALC, and now get this: EFI partition is mounted Boot/Arguments = kext-dev-mode=1 found No audio codec detected Toleda's troubleshooting guide sends me to the same place for this - adding HDEF, but then a dead end. Since our boards are basically identical, I'm hoping there's a simple step I'm missing that you might know about. Any ideas are appreciated. Thanks! <edited to abide by a forum rule I missed earlier>
  3. Thanks for the reply Robasefr! Just a couple clarifications: Ah, so VirusX's step 7 (install clover to hard drive) should have come before step 6 (apply audio patch)? Oh...I had thought since I have the same board as VirusX (GA-EX58-UD5) that I could simply use his steps and not need a DSDT, as per his earlier post: ...so does this sound like VirusX already modified his BIOS to have HDEF support and just forgot to mention it?
  4. Preface: My board is EX58-UD5, F12 BIOS. I know it's been awhile since these nice and concise steps were posted, but I'm stuck at step 6. The link points to CloverALC, so I downloaded it (audio_CloverALC-master.zip), proceeded with the instructions there (i.e. "Double click: Downloads/audio_cloverALC-110.command"), and got this: File: audio_cloverALC-110.command_v1.0f EFI partition is not mounted Confirm Clover Legacy Install (y/n): y /Volumes/[path]/audio_CloverALC-master/audio_cloverALC-110_v1.0f.command: line 318: [: /Volumes/[Yosemite drive]: binary operator expected /Volumes/[Yosemite drive]/EFI/CLOVER not found No system files were changed (portions enclosed in brackets are unique to my system so I've redacted them) I figured maybe this meant I was supposed to first mount the USB drive's EFI partition even though that wasn't mentioned in the guide. So I did so, but that appears to be empty. I wasn't too surprised, because when I followed step 1 to create a USB installer, google led me here, and following the steps there appears to have installed Clover into a folder named "EFI" on the USB's main partition rather than in its EFI partition - and somehow it boots. Nevertheless, after mounting that EFI partition I ran toleda's script again, and predictably got the same error. So then I ejected that EFI, and instead mounted my Yosemite hard drive's EFI partition. It didn't yet have Clover (installing Clover to the Yosemite hard drive isn't mentioned until step 7), so that too was futile. So I thought maybe what the script is looking for is Clover installed in the Yosemite hard drive. So I did that (thereby skipping step 6). I rebooted, mounted the Yosemite hard drive's EFI partition, went back to try step 6 again, and get this: EFI partition is mounted Boot/Arguments = kext-dev-mode=1 found Error: no IOReg/HDEF; BIOS/audio/disabled or ACPI problem No system files were changed I googled that error, and all relevant hits seem to point here. I followed those troubleshooting steps which led me to add HDEF...at which point I stopped, thinking I must have made a wrong turn much earlier, otherwise VirusX would have mentioned all this. Step 6 sounded so much simpler... So I'm guessing there are two possibilities here: either I took a wrong turn on step 1 (i.e. I should have created the install USB based on some other guide than the ##### one due to the way it installed Clover I mentioned above)...or toleda has modified his script so much since VirusX's post that I'm missing some additional steps somewhere. Has anyone followed VirusX's steps lately using current versions (Yosemite 10.10.5, Clover v2.3k r3270, audio_cloverALC-110)? If so, have you encountered errors like the ones I've listed, and have an idea as to what I'm missing? (maybe I just need to proceed with taleda's troubleshooting steps?) Thanks!
  5. Yeah I always just use your default settings on everything so I assumed the script installed the audio stuff like it always has, but apparently it didn't because I just ran the kext installer again and rebooted, and I have audio again. Weird. Anyway, thank you so much!
  6. I tried again and it worked! So I got r1684, then got 10.7.2 running (with iCloud, yay!). So only remaining issue that I know of right now is the built-in audio; it works just fine in 10.6.8, but in 10.7 (and 10.7.2) the Sound preference just says "No output devices found", same for input. If I plug in my USB headset though, both output and input work with it, just not the audio jacks out the back, to my desktop speakers. Has anyone with this motherboard figured out how to fix that in Lion? Many thanks!
  7. Hm perhaps I'm doing something wrong; as soon as I tell it to check for updates, it starts with this error: ./~extra/Resources/Scripts/HackInstaller.sh: line 1514: /.../HackInstaller/~extra/Bootloaders/Chameleon_v2.1-RC5/Project_builds: No such file or directory (I omitted the directory path containing the HackInstaller folder.) Then it displays "Chameleon v2.1svn: Checking for update" repeatedly over the course of several minutes, and finally gets back to the Bootloader Installer screen, with the Chameleon line saying " 2) Chameleon v2.1svn r1331:1449 Unable to access URL. (revertible to r1518)" Any ideas?
  8. Oh. Right. So anyway, got 10.7 running (with App Store) yay! Next step: 10.7.2 since I do want to get on the iCloud train. I hope a new iCloud-compatible version of the script (with instructions) is coming soon. After reading all the headaches people have had with getting FaceTime and iCloud working, all the different methods with varying success... even if all it takes is a more recent boot loader, downloading/compiling/installing one seems a bit complex and intimidating lol! Unless I'm making mountains out of molehills and it's really easy as pie?
  9. Thanks for your quick reply! Well...I never bothered to update because I never had a need to. If it ain't broke... Now I've updated the bootloader and nothing seems to have broken (and restart actually works now) so all's well again. Just caught me by surprise is all. So that brings me to my latest conundrum. Your step 1 for installing 10.7 says to use MBR instead of GUID, but the 10.7 boot DVD I created using the script (per instructions #2 - #5) seems to discriminate against MBR partitioned drives. It's a fresh, empty drive, 2 partitions (second partition is intended for Time Machine). After booting the DVD, when it asks to pick the destination partition for Lion it doesn't let me pick the MBR drive, saying "to install on this disk...repartition this disk using GUID Partition Table." As I understand it, something must be modified in the boot disk before OS X can install to MBR. Doesn't your script make that modification when creating the boot disk (menu #15)? If not...how can I convince it to install to MBR as you suggest in step 1? Thanks again!
  10. Well this is strange. I downloaded the newest version of the script and happened to target my old 10.6.6 volume, at which time the script immediately and without warning began "updating boot caches for Snow Leopard". Oh {censored} I thought, I haven't even done anything yet and it already thinks something needs updating, this cannot be good. After rebooting to a few kernel panics (and my own panics), I realized what the script had done: it had renamed com.apple.Boot.plist to org.chameleon.Boot.plist, which my existing bootloader (Chameleon v2.0-RC4) doesn't recognize. Did I do something wrong, or is it the script's mission to wipe com.apple.boot.plist off of Hackintoshes everywhere, without first bothering to check for the existence of an older bootloader? I managed to rename the plist back to what it was and things seem to be back to normal...but I'm left with questions: Was the filename the only change, or does the script go monkeying with the contents too when it converts old com.apple.Boot.plist? Is there a way to avoid this with the current script, or must I choose between using an older script or update the bootloader (whether I want to or not)? Or maybe a way to get the older bootloader to use org.chameleon.Boot.plist? Thank you for any suggestions!
  11. Long-time user of the script; it's pretty fabulous! I have three questions currently which I've had difficulty finding straight answers for: It is well established that Chameleon has trouble with partitions over 1TB (or at least used to; is the latest RC5 any better about this?). Since I want my primary volume to be larger than 1TB, my solution was to start with 1 small partition, get the OS running, then resize to fill the rest of the drive, and for some reason Chameleon still works. But that little trick falls apart if the drive ever has to be repaired with DiskWarrior, since you have to reinstall the bootloader after a DW repair. Now that the partition is "full size", reinstalling Chameleon once again gives the boot0 error. (Strangely, v5.01 of the script detects the bootloader it just installed, but if I try the same with v5.54 of the script it says no bootloader installed, even immediately after using the script to install Chameleon.) So I guess the only solution that takes potential future DW repairs into account, is to keep the boot partition 1TB or less? Drives (and thus partitions) will only get larger in the future, so I predict this problem will become more and more prevalent unless it is fixed (if it is even fixable). Speaking of Chameleon - the current version of the script says RC5 r691 is "your best choice". Indeed, I've read that it fixes restart without resorting to a kext, and while I don't restart often, when I do it is rather annoying to have to manually hit the reset switch. But I have some trepidation about upgrading from the latest official release (RC4 684) to an unofficial release. That one came out such a long time ago; is the official release no longer being developed? (I suppose the entire osx86 concept is rather unofficial; declaring RC4 "official" and RC5 "unofficial" seems a bit like splitting hairs, so perhaps my hesitation is unfounded?) In the script's section "Modify plists and EFI strings", the default option is "For HackInstaller", with the other options for specific boot partition(s). I assume when you choose "For HackInstaller" and then run the full install, the Plists/EFI strings are copied to whichever partition you're installing to. Which specific installation step copies the Plist info from the script to the partition? Just curious. (I thought it was the kext/kernel installer but that wasn't it.)
  12. This is what I did originally, and it worked fine for months...until the drive developed errors that only DiskWarrior could repair (invalid index key). So now I get the boot0: error as well, even after reinstalling the same bootloader. Indeed, D_D's script says no bootloader is installed, even immediately after using the script itself to install the bootloader. So I think the issue here is the partition size. I too have a 1.5TB drive, with 2 parts: 1 large (>1TB) primary, and a secondary for Windows. Eventually the disk will have more than 1TB of data on it, at which point I won't be able to re-do the trick to get around large partition sizes. So I guess the only long-term solution is to leave the boot partition 1TB o r less, just for Chameleon and the OS, so that DiskWarrior doesn't re-screw me if I ever need to use it again...anyone have a better solution? Anyone know if the latest version of Chameleon still has this partition size incompatibility? If it does, I predict this issue becoming more and more common as drives >1TB become more commonplace...