Jump to content

pharillion

pharillion

Member Since 18 Mar 2008
Offline Last Active Today, 12:04 AM
-----

Posts I've Made

In Topic: 10.9 GM Released.

13 October 2013 - 04:35 PM

You are not right in thinking non-apple signed kexts will only be loaded from /Library/Extensions/. There is no problem in loading unsigned kexts and an alert is just that, an alert.

Yes, I know that unsigned kexts will load from /S/L/E, however I'm drawing a distinction between unsigned kexts and kexts signed with an identified Developer Id which is not Apples.  I do not believe that these will load from /S/L/E, I think that for them to load they must be in /Library/Extensions.

If we do look ahead to 10.10 with your thinking, do you propose that any of the current apps being used with unsigned kexts will not be able to run because these kexts have not been updated with proper kext signing?

I would say that this is a distinct possibility for the long term.  However I imagine that Apple will encourage developers to sign their kexts and have them loaded from /Library/Extensions.

In Topic: 10.9 GM Released.

13 October 2013 - 02:06 PM

So that explains things. The chameleon and smbios plist files are read by the system as usual, but not the extensions as with previous versions of OS X. Anything else that's shoved into S/L/E gets loaded or at least read regardless of being signed or not, but unsigned or tampered kexts would turn up with a warning on the Console.

 

If I look at the list of Extensions from System Profiler I see that a couple of "Not Signed" kexts including Andy's AnyAppleUSBMouse.kext are listed as being "not loaded" although in fact they are being loaded.   Other "Not Signed" kexts such as FakeSMC.kext are listed as being loaded.

 

The same version of Andy's AnyAppleUSBMouse.kext is listed in the Info.plist of AppleKextExcludeList.kext, as too is FakeSMC.kext but of course I edited the Info.plist of AnyAppleUSBMouse.kext when I added my own Mouse IDs.

 

Looking at /S/L/caches/com.apple.kext.caches/Startup I see some interesting .plist files:

 

excludedkextalert.plist

loadedkextmt.plist

invalidsignedkextalert.plist

 

All of these start with "Alerts sent" and contain more or less what would be expected.

 

The latest version of Little Snitch 3 for Mavericks has its signed .kext in /Library/Extensions and not /S/L/E

 

Am I right in thinking that Mavericks will load unsigned .kexts in /S/L/E with a warning but that non-apple signed .kexts will only be loaded from /Library/Extensions?

 

Without wishing to be too alarmist I'm guessing that eventually, perhaps by 10.10 Syrah, /S/L/E will be read-only and third-party .kexts will need to be signed with a developer ID and loaded from /Library/Extensions.

 

It will be interesting to see how this progresses.

In Topic: No Hard Drives

17 July 2013 - 04:37 PM

 

ok now Iam try to install on EXT hdd  and  after I update to DP 3  do you think when I am plug inside de Dell optiplex 755,  its work ???  :D  B)

 

It should do, at least if my experience is anything to go by.  Good Luck

In Topic: No Hard Drives

17 July 2013 - 03:41 PM

Shouldn't the Generic AHCI entry match on class code here?

 

System Profiler detail is often largely cosmetic, although there are SATA injector .kexts for specific chipsets.  In this same Dell Precision 690 I have a Marvell eSATA card which is normally picked up as GenericAHCI but I've injected correct details into a legacy .kext residing in /S/L/E:

 

<key>Marvell 88SE9123</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.apple.driver.AppleAHCIPort</string>
            <key>Chipset Name</key>
            <string>88SE9123</string>
            <key>IOClass</key>
            <string>AppleAHCI</string>
            <key>IOPCIClassMatch</key>
            <string>0x01060100&amp;0xffffff00</string>
            <key>IOPCIPrimaryMatch</key>
            <string>0x91231b4b</string>
            <key>IOProbeScore</key>
            <integer>15000</integer>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
            <key>Vendor Name</key>
            <string>Marvell</string>
        </dict>
 

I think I'm right in saying that the Info.plist in DP3 AppleAHCIPort.kext and that for DP2 and earlier are identical, however my suspicion is that the binaries may not be - unless the difference is somewhere else in the AHCI disk chain.

 

I no longer have DP2 or DP1 installed to diff and check.

In Topic: No Hard Drives

17 July 2013 - 02:44 PM

Hi,

 

I had the problem of missing SATA hard drives with 10.9 on a Dell Precision 690 which uses an ESB2 SATA controller.  This runs ML very well but on my initial installation attempt with 10.9 DP1 Disk Utility would see no SATA hard drives.  I did manage a successful installation of 10.9 DP1 onto  a USB HDD and also using the onboard LSI SATA/SAS chipset after modifying AppleLSIFusionMPT.kext.

 

Looking with IORegistryExplorer, AppleAHCIPort.kext would attach to the ESB2 SATA but never show any disks.

 

Upgrading to DP2 made no difference, and I spent a while adding "compatible" and "name" flags to the ESB2 SATA entry in my DSDT but to no effect.  Rolling back to the 10.8.4 AppleAHCIPort.kext also didn't help.

 

Upon upgrading to DP3 suddenly the ESB2 HDDs became visible exactly as in ML.  Thus I think that this is probably the consequence of a bug in DP1 and DP2 which Apple have fixed in DP3.

 

I would suggest that anyone with this problem installs on USB and upgrades to DP3 or beyond.  Their SATA drives should then appear and it should be possible to clone the 10.9 installation across.

 

Good Luck,

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy