Contribute
Register

Gatebreak: Signed Kexts for Everyone

Status
Not open for further replies.
it looks like it tried to link the FakeSMC plugins in the absence of FakeSMC, are they all loose in SLE?
 
it looks like it tried to link the FakeSMC plugins in the absence of FakeSMC, are they all loose in SLE?

They don't exist at all in SLE -- which is weird, because FakeSMC was installed before I tried to install Gatebreak. What's even more weird is that now there's a folder called "FakeSMC.next" in SLE with the following contents:

Code:
FakeSMC.next/
  Contents/
    Info.plist
    MacOS/
      FakeSMC
    Plugins/
      FakeSMCKeyStore.kext/
        Contents/
          Info.plist
          MacOS/
            FakeSMCKeyStore
 
that .next is what the Gatebreak installer does to preserve the previous FakeSMC, like the .old it appends to the kext utilities. The plugins which failed to prelink are from a non-Gatebreak package; that they still tried to prelink despite the renaming of the main kext means something else is going on.
 
that .next is what the Gatebreak installer does to preserve the previous FakeSMC, like the .old it appends to the kext utilities. The plugins which failed to prelink are from a non-Gatebreak package; that they still tried to prelink despite the renaming of the main kext means something else is going on.

So what should I do?
 
if the plugins have unloaded, try installing again
 
if the plugins have unloaded, try installing again

What I ended up doing was to manually remove the FakeSMC.next and the plugins (which were floating around in /S/L/E), as well as GenericUSBXHCI.kext, then rerun MultiBeast to properly reinstall FakeSMC and GenericUSBXHCI. After that I reran the Gatebreak installer and it installed successfully!
 
I was looking at my Console log because of an unrelated problem, and I noticed this:

Code:
12/5/13 7:16:45.000 PM kernel[0]: OSMetaClass: Kext org.gatebreak.driver.FakeSMC class FakeSMCKey is a duplicate;kext org.hwsensors.driver.FakeSMCKeyStore already has a class by that name.
12/5/13 7:16:45.000 PM kernel[0]: Kext org.gatebreak.driver.FakeSMC start failed (result 0xdc00400a).
12/5/13 7:16:45.000 PM kernel[0]: Kext org.gatebreak.driver.FakeSMC failed to load (0xdc008017).
12/5/13 7:16:45.000 PM kernel[0]: Dependency org.gatebreak.driver.FakeSMC of kext org.gatebreak.driver.CPUSensors failed to load.
12/5/13 7:16:45.000 PM kernel[0]: Can't remove kext org.gatebreak.driver.FakeSMC; services failed to terminate - 0xdc008018.
12/5/13 7:16:45.000 PM kernel[0]: Kext org.gatebreak.driver.CPUSensors failed to load (0xdc008015).
12/5/13 7:16:45.000 PM kernel[0]: Failed to load kext org.gatebreak.driver.CPUSensors (error 0xdc008015).
...
12/5/13 7:16:45.000 PM kernel[0]: OSMetaClass: Kext org.gatebreak.driver.FakeSMC class FakeSMCKey is a duplicate;kext org.hwsensors.driver.FakeSMCKeyStore already has a class by that name.
12/5/13 7:16:45.000 PM kernel[0]: Kext org.gatebreak.driver.FakeSMC start failed (result 0xdc00400a).
12/5/13 7:16:45.000 PM kernel[0]: Kext org.gatebreak.driver.FakeSMC failed to load (0xdc008017).
12/5/13 7:16:45.000 PM kernel[0]: Dependency org.gatebreak.driver.FakeSMC of kext org.gatebreak.driver.ACPISensors failed to load.
12/5/13 7:16:45.000 PM kernel[0]: Can't remove kext org.gatebreak.driver.FakeSMC; services failed to terminate - 0xdc008018.
12/5/13 7:16:45.000 PM kernel[0]: Kext org.gatebreak.driver.ACPISensors failed to load (0xdc008015).
12/5/13 7:16:45.000 PM kernel[0]: Failed to load kext org.gatebreak.driver.ACPISensors (error 0xdc008015).

And there are many more lines like this (for GPUSensors, etc.) Is this normal?
 
Your FakeSMC plugins were in SLE as I suspected, (which is not their normal location, I think, since they are PlugIns), so removing them was important; GenericUSBXHCI however should not be affected either way.
FakeSMCKeyStore is still floating around and should be removed.
I assumed those using Gatebreak would have a normal installation, not FakeSMC plugins loose in SLE; I may have to revise this in later pkgs.
 
Your FakeSMC plugins were in SLE as I suspected, (which is not their normal location, I think, since they are PlugIns), so removing them was important; GenericUSBXHCI however should not be affected either way.
FakeSMCKeyStore is still floating around and should be removed.
I assumed those using Gatebreak would have a normal installation, not FakeSMC plugins loose in SLE; I may have to revise this in later pkgs.

I have absolutely no idea how those plugins ended up "loose"... I do regularly update HWMonitor/FakeSMC from the developer's site: http://sourceforge.net/projects/hwsensors/ - maybe one of those installations is the culprit.
 
Status
Not open for further replies.
Back
Top