Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Another thing perhaps interesting to developers:
The old and obviously broken file prelinkedkernel in directory PrelinkedKernels has 19.993.674 bytes and is dated from 24. January 2017 at 12:36.
The new file generated automatically by the procedure above has 12.946.882 bytes and is dated from today.
To prevent for such trouble I have had it should be investigated why this file has changed so much.
Was the date stamp of the old file the date when I updated from 10.12.2 to 10.12.3? I don't recall.
 
Another thing perhaps interesting to developers:
The old and obviously broken file prelinkedkernel in directory PrelinkedKernels has 19.993.674 bytes and is dated from 24. January 2017 at 12:36.
The new file generated automatically by the procedure above has 12.946.882 bytes and is dated from today.
To prevent for such trouble I have had it should be investigated why this file has changed so much.
Was the date stamp of the old file the date when I updated from 10.12.2 to 10.12.3? I don't recall.

The OS time to time regenerate the prelinkedkernel. If anyone enable SIP, when the OS thinks it's a time to create a new prelinkedkernel the next reboot will kill USB.
 
Last edited:


While it is apparent that for this poster, just finding a working solution was the primary objective, after researching other alternatives, I wanted to share a much more simpler/inexpensive internal Wi-Fi replacement for the BCM94321MC Card in macOS Sierra.

For exactly $4 US dollars Total (included both the card & shipping), I picked up a Atheros AR5BXB92 (Apple Part #: 607-3758-A) and simply unscrewed the T6 fastener screw, detached the two (2) Wi-Fi connector cables, and removed the unsupported BCM4321. I then installed the Atheros AR5BXB92 in the very same socket, reconnected the cables, and tightened the same T6 screw (which aligned perfectly), closed up the 24" iMac 8,1 A1225 case and done.
 
Last edited:
  • Like
Reactions: extrachrispy
The OS time to time regenerate the prelinkedkernel. If anyone disable SIP, when the OS thinks it's a time to create a new prelinkedkernel the next reboot will kill USB.
If this is true then it is very dangerous to use the patched Sierra for not supported Macs.
I have running the patched Sierra for some month now and never changed SIP by hand or otherwise.
I even don't know about it until a few days ago when Trackpad and Keyboard was gone.
When the OS blocked it by itself that is really a very bad thing.
There should be a great warning before downloading and using the patch!!!!!!!
 
If this is true then it is very dangerous to use the patched Sierra for not supported Macs.
I have running the patched Sierra for some month now and never changed SIP by hand or otherwise.
I even don't know about it until a few days ago when Trackpad and Keyboard was gone.
When the OS blocked it by itself that is really a very bad thing.
There should be a great warning before downloading and using the patch!!!!!!!

I'am running Sierra on unsupported macs from the early days, and SIP newer turned back to on (one of the first things when i'am starting using a mac (since El Capitan) to turning off SIP). Some people here randomly clearing PRAM (SIP config flag stored on nvram, so this simply reset SIP back to on) after that flooding this thread about non working USB devices. SIP status is not touched by any updates (dot updates or complete upgrades), if it's turned off it's keeping off until anyone not turning it back to on.
 
I'am running Sierra on unsupported macs from the early days, and SIP newer turned back to on (one of the first things when i'am starting using a mac (since El Capitan) to turning off SIP). Some people here randomly clearing PRAM (SIP config flag stored on nvram, so this simply reset SIP back to on) after that flooding this thread about non working USB devices. SIP status is not touched by any updates (dot updates or complete upgrades), if it's turned off it's keeping off until anyone not turning it back to on.
That seems to be wrong!
I have not cleared VPRAM nor anything else. Also the update from 10.12.2 to 10.12.3 was done times ago.
Trackpad and keyboard was gone after a normal start.
The only thing correct you have wrote was the fact about the broken file prelinkedkernel. Thank you for this information.
Perhaps there is a Mac user with more knowledge to investigate what is going wrong here with the Sierra patch.
 
That seems to be wrong!
I have not cleared VPRAM nor anything else. Also the update from 10.12.2 to 10.12.3 was done times ago.
Trackpad and keyboard was gone after a normal start.
The only thing correct you have wrote was the fact about the broken file prelinkedkernel. Thank you for this information.
Perhaps there is a Mac user with more knowledge to investigate what is going wrong here with the Sierra patch.

Sierra patch is simply some small modifications:
- modify /System/Library/CoreServices/PlatformSupport.plist because this is required to boot the OS. Without this the booting process stopping with a stop sign.

- Add a LegacyUSBInjector.kext to /Library/Extensions because this kext is required to bring back USB support. Without this kext USB devices can't working. This kext can't be loaded when SIP is enabled. Anyone with developer subscription can sign this kext myself, and when it's signed, it's working with enabled SIP.

- On the installer media we require to replace prelinkedkernel, because the original version don't contains the usbinjector.kext. On the running OS, this is not required because the OS can't be regenerate the prelinkedkernel.

When USB devices are in a non working state:
- check SIP, because SIP needs to be disbaled
- if SIP is disabled, check usbinjector.kext is exists in /Library/Extensions (apple updates are not touching /Library/Extensions)
- recreate prelinkedkernel from recovery

When the running OS recreate prelinkedkernel, it's build it from the kexts from the /Library/Extensions and /System/Library/Extensions. You did something, because if SIP is disabled, if the injector kext exists, the automatically created prelinkedkernel always contans the injector. So maybe you run something that replaced the prelinkedkernel with a faulty one.
 
Sierra patch is simply some small modifications:
- modify /System/Library/CoreServices/PlatformSupport.plist because this is required to boot the OS. Without this the booting process stopping with a stop sign.

- Add a LegacyUSBInjector.kext to /Library/Extensions because this kext is required to bring back USB support. Without this kext USB devices can't working. This kext can't be loaded when SIP is enabled. Anyone with developer subscription can sign this kext myself, and when it's signed, it's working with enabled SIP.

- On the installer media we require to replace prelinkedkernel, because the original version don't contains the usbinjector.kext. On the running OS, this is not required because the OS can't be regenerate the prelinkedkernel.

When USB devices are in a non working state:
- check SIP, because SIP needs to be disbaled
- if SIP is disabled, check usbinjector.kext is exists in /Library/Extensions (apple updates are not touching /Library/Extensions)
- recreate prelinkedkernel from recovery

When the running OS recreate prelinkedkernel, it's build it from the kexts from the /Library/Extensions and /System/Library/Extensions. You did something, because if SIP is disabled, if the injector kext exists, the automatically created prelinkedkernel always contans the injector. So maybe you run something that replaced the prelinkedkernel with a faulty one.
Again you are wrong!
Is the Sierra patch your work?
If yes, you have to warn people for using it!
There is no usbinjector.kext, not in /Library/Extensions nor in /System/Library/Extensions and there has never been such file when searching my backups from TimeMachine.

In case of a broken prelinkedkernel file it is very hard for the average user to restore it. Disabling SIP is not sufficient and that was the only hint I got.
 
Again you are wrong!
Is the Sierra patch your work?
If yes, you have to warn people for using it!
There is no usbinjector.kext, not in /Library/Extensions nor in /System/Library/Extensions and there has never been such file when searching my backups from TimeMachine.

In case of a broken prelinkedkernel file it is very hard for the average user to restore it. Disabling SIP is not sufficient and that was the only hint I got.
If there is no legacy USB injector kext, there is either a bug in the patcher or something on your computer is deleting it.
 
If there is no legacy USB injector kext, there is either a bug in the patcher or something on your computer is deleting it.
He has talked about a LegacyUSBInjector.kext and of a usbinjector.kext. The latter never exists and the former exists only in the Sierra patch and not in El Capitan.
After all the developer of the Sierra patch should warn users about such problems.
 
He has talked about a LegacyUSBInjector.kext and of a usbinjector.kext. The latter never exists and the former exists only in the Sierra patch and not in El Capitan.
After all the developer of the Sierra patch should warn users about such problems.
He is just abbreviating it. He means legacy USB injector. I know because I wrote the kext!
 
He is just abbreviating it. He means legacy USB injector. I know because I wrote the kext!
I hate it when someone is not able to precise something. When you are coding despite of C++, ObjectiveC or Swift or whatever and you can't precise something your code will not compile!
 
I'm having problems with an early 2008 MacPro (3,1). I do have a OWC Accelsior E2 1 TB PCI SSD as my boot drive, but I am trying to target a Physical drive with the patch tool. Has anyone been able to get it to work with the Excelsior installed?? Has anyone removed it and then installed it on one of the internal drives and then rebooted with the SSD PCI installed? Any thoughts?
 
Last edited:
Sierra patch is simply some small modifications:
- modify /System/Library/CoreServices/PlatformSupport.plist because this is required to boot the OS. Without this the booting process stopping with a stop sign.

- Add a LegacyUSBInjector.kext to /Library/Extensions because this kext is required to bring back USB support. Without this kext USB devices can't working. This kext can't be loaded when SIP is enabled. Anyone with developer subscription can sign this kext myself, and when it's signed, it's working with enabled SIP.

- On the installer media we require to replace prelinkedkernel, because the original version don't contains the usbinjector.kext. On the running OS, this is not required because the OS can't be regenerate the prelinkedkernel.

When USB devices are in a non working state:
- check SIP, because SIP needs to be disbaled
- if SIP is disabled, check usbinjector.kext is exists in /Library/Extensions (apple updates are not touching /Library/Extensions)
- recreate prelinkedkernel from recovery

When the running OS recreate prelinkedkernel, it's build it from the kexts from the /Library/Extensions and /System/Library/Extensions. You did something, because if SIP is disabled, if the injector kext exists, the automatically created prelinkedkernel always contans the injector. So maybe you run something that replaced the prelinkedkernel with a faulty one.
If you can sign the troublesome unsigned legacyUSBinjector kext, could you share it with dosdude1 so all this trouble with SIP could be put to rest? That way the Sierra post-installer adds it as a signed kext that SIP won't dump?
 
If you can sign the troublesome unsigned legacyUSBinjector kext, could you share it with dosdude1 so all this trouble with SIP could be put to rest? That way the Sierra post-installer adds it as a signed kext that SIP won't dump?
Some of the other patches, such as the Ambient Light Sensor and Volume Control patches, modify pre-existing kexts, so SIP being disabled would still be necessary for those patches to work. Signing LegacyUSBInjector would definitely eradicate quite a few issues, and if nobody else is able to, I'll more than likely purchase an Apple Developer License sometime in the near future.
 
  • Like
Reactions: Brale
If you can sign the troublesome unsigned legacyUSBinjector kext, could you share it with dosdude1 so all this trouble with SIP could be put to rest? That way the Sierra post-installer adds it as a signed kext that SIP won't dump?

I can, but i'am not sure it's fully legal to hacking os x (modifying Apple's software) to run on unsupported hardware. So i don't want to risky my developer account.
 
I can, but i'am not sure it's fully legal to hacking os x (modifying Apple's software) to run on unsupported hardware. So i don't want to risky my developer account.
I understand that concern. However, signing a kext someone made isn't hacking macOS. Even specifically in this case, adding a USB driver to the system does not seem to be a violation. The only thing Apple could say is they don't like how dosdude1 used a kext that "you" posted somewhere. What dosdude1 does with it isn't your problem.
[doublepost=1486550979][/doublepost]
Some of the other patches, such as the Ambient Light Sensor and Volume Control patches, modify pre-existing kexts, so SIP being disabled would still be necessary for those patches to work. Signing LegacyUSBInjector would definitely eradicate quite a few issues, and if nobody else is able to, I'll more than likely purchase an Apple Developer License sometime in the near future.
Yes, but those kexts are not critical. Loss of USB is serious and complicates recovery. It would be great if someone could sign at least the USB.kext... I have thought about signing up for a dev license (it is $99) but I'd have no use for it other than this project.
 
First of all there should be written the truth about this hack to warn people who like to use it.
It is irresponsible to guide users into this trap. They should know something about the background and the risk using it.
E.g. it should be said that resetting VPRAM is absolutely forbidden and such things.
Otherwise the developers of this hack risks to be sued for damages.
 
Ok so now successfully got Night Shift working on MacPro 3.1 nVidea GT120 and 23" Cinema Display.
Not as much fun as flux.
 
First of all there should be written the truth about this hack to warn people who like to use it.
It is irresponsible to guide users into this trap. They should know something about the background and the risk using it.
E.g. it should be said that resetting VPRAM is absolutely forbidden and such things.
Otherwise the developers of this hack risks to be sued for damages.

Anyone can be sued. You can be sued as well. Give that this is freeware etc. the likelihood of success is low. It would be a good idea to have a typical legal disclaimer regarding the software to reduce the possibility of any nuisance suits.
 
Again you are wrong!
Is the Sierra patch your work?
If yes, you have to warn people for using it!
There is no usbinjector.kext, not in /Library/Extensions nor in /System/Library/Extensions and there has never been such file when searching my backups from TimeMachine.

In case of a broken prelinkedkernel file it is very hard for the average user to restore it. Disabling SIP is not sufficient and that was the only hint I got.

No offence but if you follow the instructions to a T it breaks nothing, does nothing bad and works fine. User error is 99% of the issues with technology. I learned that doing IT help desk. Also as your basically hacking the bloody thing it's at your own risk. You should be smart enough to know that Individual mileage may vary.

You go on and on about your issues and how it's "dangerous" but what it look like in all honesty is you didn't follow the steps completely and then when your told something simple as "go into recovery and open terminal and type crutil disable " and you post some terminal help page full of crutil commands it just makes it more obvious it was an error on your part and not the dev's

Even with basic computer knowledge it's not computer science.

If a jailbreak bricks your iPhone do you seriously think it's the devs fault?
 
Nobody twisted your arm buddy and no court would seriously entertain a lawsuit where a user made the choice to modify their hardware to do things against the recommendations of the manufacturer using freeware they found online.

Lol you're already doing something your not supposed to do.
 
Last edited:
First of all there should be written the truth about this hack to warn people who like to use it.
It is irresponsible to guide users into this trap. They should know something about the background and the risk using it.
E.g. it should be said that resetting VPRAM is absolutely forbidden and such things.
Otherwise the developers of this hack risks to be sued for damages.
I think the people working on this project have been more than clear about this issue. However what might help is an updated and clear guide. Would you want to contribute?
 
I understand that concern. However, signing a kext someone made isn't hacking macOS. Even specifically in this case, adding a USB driver to the system does not seem to be a violation. The only thing Apple could say is they don't like how dosdude1 used a kext that "you" posted somewhere. What dosdude1 does with it isn't your problem.
Yes, but those kexts are not critical. Loss of USB is serious and complicates recovery. It would be great if someone could sign at least the USB.kext... I have thought about signing up for a dev license (it is $99) but I'd have no use for it other than this project.
You don't think Apple has employees participating in these forums? Any dev signing kexts and distributing them to get around Apple's policies on which systems are supported would not only lose their license, but likely be blacklisted.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.