Jump to content


  • Content Count

  • Joined

  • Last visited

About ~Galaxy

  • Rank
    InsanelyMac Protégé

Profile Information

  • Location
  1. ~Galaxy

    Chameleon 2.4svn Official PKG Installer

    I just recently upgraded to an NVIDIA GTX 1050 Ti and can't for the life of me get any combination of methods for web drivers to work. FileNVRAM refuses to persist between reboots, trying to use kexts.plist override for NVIDIAWebDrv=Yes does not work. The boot loader doesn't seem to enumerate the RAM for the GPU either. I am at a loss. All I am getting is the Apple Software Renderer. mp51_gtx_1050_ti.txt
  2. ~Galaxy


    I am so glad someone is still maintaining Chameleon. Hopefully I can get some time to work on some helpful documentation, it's been a long time since we last had a documentation flush out and with so many new features and abilities its sure to take some time to write it all out!
  3. Will it ever be possible to get microphone pre-gain? Also, is there a possiblity we can use VoodooHDA on this machine? I tried before but I got garbled sound. In my opinion VoodooHDA usually does a better job than AppleHDA. Thanks for any input you can give!
  4. By default most drives are which is why i haven't made much of a fuss about it. This issue has been taken care of in VoodooPreboot with a vsdbutil check if the script detects that drive permissions are not enabled it will enable them automatically to save any issues with kernel extension permissions.
  5. Here's my latest and final iteration of "SlimBuild" under that moniker. It now contains a fairly indepth readme and should be much easier to utilize now that there is an instruction manual for it
  6. The Chameleon Bootloader that is in the works now that will be released along-side the final version of Voodoo should solve all these issues of timings and clock speed detection errors some pretty hard work is going into it to make it perform a few more tasks that would normally be taken care of by EFI in an actual Mac. So, sit tight it's just around the corner
  7. All good ideas that have other tools, in the end I just wanted something to make the cd not necessarily the end all to beat all, have to leave room for improvements somewhere, and your wishlist will be taken care of in the new chameleon due out soon that will coincide with the launch of Voodoo so just keep patient good things come to those who wait, and welcome back btw we'll have to catch up
  8. Hm.. come to think of it I don't see why it wouldn't be possible, though the partition scheme is Apple Partition Map -- this should be of little consequence as long as the bootloader knows where to find it as it simply contains an HFS+ partition with the files you'd need... what you are propsing for the moment is out of reach for the bootloader to be able to handle, as it is the bootloader that is tasked with utilizing that encrypted boot image itself. Chameleon isn't capable of loading up stuff like that at this present time and from the sounds of it CheckPoint appears to perform some consistency checks to see if its running on a Mac platform as opposed to a hackintosh...
  9. The issue is the fact you haven't specified any extensions in the Extensions directory. The whole purpose of slimbuild is to create a preboot disk with additional kernel extensions that will aid you in getting your system to boot, so you might try getting the proper extensions together so you can use the script. The script is failing to do what it is intended because its not meeting the set condition of requiring a meta-kernel extension file and is thus failing the consistency check in its meta kernel extension creation routine. Thanks for reminding me I meant to put a check in for this sort of scenario and I will do so now and release SlimbuildV2.1 soon in order to prevent anyone from getting that far without extensions...
  10. Only if you specify one by placing it in the PLIST folder.
  11. The com.apple.boot.s is an inbuilt plist that the bootloader uses when it falls back due to something being wrong with any of the alternative boot.plist files and or it not being able to find a boot.plist on the media you told it to boot from. At the first prompt with the timeout with the preboot cd in you should hit f8 then escape and then should be presented with the hex code chooser 9F for DVD 80 for HD1 etc.. As for the files being hidden, I made them hidden so that no one would accidentally delete something important or have to worry about them -- the only files which are hidden need no user interaction or changes in any case.
  12. The issues are going to happen in any case that there is more than one name of the same driver present. Your idea is a bit of an oversimplification yes, but not a hard one to make, the IOKit is a relatively stubborn, but efficient subsystem and its asynchronous as well which can present a problem for us. Regardless of the driver version the IOKit is going to load the drivers the bootloader feeds it before it proceeds to place the drivers in the appropriate spaces and discard things it doesn't need to load. Its when it comes time to process and send things out to their respective locations in the kernel that the magic happens. If two kernel extensions share the same name a series of checks is done on it to determine which one to load. The match category is first checked (we have two of the same name in this case) so then it goes on to check the version number and probescores (if present) then if a version is newer and or probescore is higher, it loads that extension instead of another one that is already in the bootable media for example -- this process is what we exploit; its actually a feature of the IOKit to keep things going smoothly. We make our hacked or additional drivers that share a match category appear newer or bump their probescore to beat the other extension to the parking spot in the kernel. booting -f simply ignores any kernel caches and loads all the extensions that are present in the Extensions directory on the bootable media and doesn't necessarily guarantee us getting to the parking space first; however, bumping the probescore and worst case the version number, and we ensure we get there first and get the added functionality we need in order for our system to work properly.
  13. There actually is its just hidden.
  14. You musn't forget that some kernel extensions exist in retail installs already at this point. I think its high time I do up a guide on how to add in or increase a probe score or bump the version number. The majority of the errors I am seeing from all of you seem to lie in the fact you are using kernel extensions which are conflicting with kernel extensions that are already present on the Retail disk and or install. You need to make slight modifications to the kernel extensions you are going to use in your preboot disk by either a ) bumping and or adding a probe score or b ) by increasing the version # the latter of which i wouldn't recommend unless the kernel extension is being stubborn.. In a standard kernel extension such as IOATAFamily.kext you can dissect it and get out the plugin you would like. So for example here is the Info.plist of the AppleIntelPIIXATA Plugin that is inside of the IOATAFamily.kext. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>English</string> <key>CFBundleExecutable</key> <string>AppleIntelPIIXATA</string> <key>CFBundleGetInfoString</key> <string>2.0.0, Copyright Apple Inc. 2000-2007</string> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleIntelPIIXATA</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>Apple Intel ICHx/PIIX ATA Driver</string> <key>CFBundlePackageType</key> <string>KEXT</string> <key>CFBundleShortVersionString</key> <string>2.0</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>2.0.0</string> <key>IOKitPersonalities</key> <dict> <key>ICH7-M Serial ATA</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleIntelPIIXATA</string> <key>Controller Name</key> <string>ICH7-M SATA</string> <key>IOClass</key> <string>AppleIntelPIIXATARoot</string> <key>IOPCIPrimaryMatch</key> <string>0x27c48086</string> <key>IOProbeScore</key> <integer>2000</integer> <key>IOProviderClass</key> <string>IOPCIDevice</string> <key>Serial ATA</key> <true/> <key>Supported Transfer Modes</key> <string>0x3f061d</string> </dict> <key>Serial ATA</key> <true/> <key>Supported Transfer Modes</key> <string>0x3f061d</string> </dict> <key>Serial ATA Channel Driver</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleIntelPIIXATA</string> <key>IOClass</key> <string>AppleIntelICHxSATA</string> <key>IOProbeScore</key> <integer>1000</integer> <key>IOProviderClass</key> <string>AppleIntelPIIXATAChannel</string> <key>Serial ATA</key> <true/> </dict> </dict> <key>NSHumanReadableCopyright</key> <string>Copyright Apple Inc. 2000-2007</string> <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOATAFamily</key> <string>1.5.0d1</string> <key>com.apple.iokit.IOPCIFamily</key> <string>1.1</string> <key>com.apple.kpi.iokit</key> <string>8.7.2</string> <key>com.apple.kpi.libkern</key> <string>8.7.2</string> <key>com.apple.kpi.mach</key> <string>8.7.2</string> </dict> <key>OSBundleRequired</key> <string>Local-Root</string> </dict> </plist> NOTE: (I stripped out some of the other match categories within this Info.plist for the sake of shortening the post there are several more present..) Notice how there is a IOProbeScore key in each of the "Personalities". If you are for instance using a hacked AppleIntelPIIXATA.kext you would only need this kext and could make a simple modification to only the match category that pertains to your hardware. Where you see something like : <key>IOProbeScore</key> <integer>1000</integer> Bump the probe score to something higher than what it originally is. A value of 2000 in the personality that matches your hardware is sufficient. So for example if I am using ICH7-M SATA... <key>ICH7-M Serial ATA</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleIntelPIIXATA</string> <key>Controller Name</key> <string>ICH7-M SATA</string> <key>IOClass</key> <string>AppleIntelPIIXATARoot</string> <key>IOPCIPrimaryMatch</key> <string>0x27c48086</string> <key>IOProbeScore</key> <integer>3000</integer> <key>IOProviderClass</key> <string>IOPCIDevice</string> <key>Serial ATA</key> <true/> <key>Supported Transfer Modes</key> <string>0x3f061d</string> </dict> I increased the probe score to 3000 because the base score was already 2000. In the case of other match categories in the kext you can just leave them alone. As for other kernel extensions, some of them like any of the IO*Family.kext files have no personalities and thus have no probe score. If you can dissect the IO*Family kernel extension that has the plugin you need in it it is your best bet to do so and simply change the OSBundleRequired to Root within that plugin (or add it if it isn't present). It will be loaded automatically when the proper IO*Family.kext is loaded. If you are absolutely bent on not dissecting a kernel extension or are using an IO*Family extension, then you can do the following. For example the version information for IOATAFamily.kext: <key>CFBundleName</key> <string>IOATAFamily</string> <key>CFBundlePackageType</key> <string>KEXT</string> <key>CFBundleShortVersionString</key> <string>1.7.2</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>1.7.3f1</string> I generally bump the values to 9.9.9 so that I can see when a hacked or additional kernel extension is loaded on my system via kextstat. Increasing the version # within the kernel extensions CFBundle values makes the IOKit think that our driver is newer than the existing driver and as such will load it instead of the driver that is already present within the installation! The changes reflected in this Info.plist would look like: <key>CFBundleName</key> <string>IOATAFamily</string> <key>CFBundlePackageType</key> <string>KEXT</string> <key>CFBundleShortVersionString</key> <string>9.9.9</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>9.9.9</string> That is really all that needs to be done in the case of loading in additional kernel extensions that are already present in the system when you are creating a preboot disk. Be incredibly careful that you don't mess with any other values in the kernel extension if and when you do choose to edit things because the formatting and content are very important to the proper loading and execution of the payload of the kernel extension. Hopefully this helps alleviate some of the issues people have been having with not getting a root device for example. There are more advanced methods for adding in additional DeviceIDs etc into kernel extensions which are already present and don't require a binary hack or recompilation, but for the sake of simplicity I will omit these for the time being and add that information in later when I do a formal guide. Good Luck! ~Galaxy
  15. the mkext generated by the system includes a bunch of kernel extensions that are unnecessary for our means. The reason slimbuild only uses the kexts you give is it so that we can keep the payload down to a minimum of only the kexts that you will be needing. comparatively speaking the mkext for a full system install is 10MB whereas even a busy mkext from the preboot disk is maybe 3MB tops. Using a full system's mkext is highly not reccomended because of how many drivers it is loading and the simple fact that many of them have dependencies that could run into issues when the kernel tries to resolve them and can't find them. On another note i am still working on a script that you can use to do that ie "PreviousBuild" where you can use files from a previous build of slimbuild in order to create a new bootable iso its in its infancy at the moment but i hope to bring it up to parr in the coming days so it can work together with slimbuild to provide a more robust toolset for making preboot disks. ~Galaxy