About 40-60 seconds...
My old iMac 27” (late 2009) with SSD (SATA II ), boots up faster... Some are reporting boot times of 2-3min even.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Innie: A fix for PCI drives seen as external
- Thread starter cdf
- Start date
- Sort by reaction score
About 40-60 seconds...
My old iMac 27” (late 2009) with SSD (SATA II ), boots up faster... Some are reporting boot times of 2-3min even.
Tried this last night and it was sweet! I got a PCIe ssd SATA III adapter off AliExpress (debroglie brand) and a crucial bx500 240gb ssd from a local shop that had them on sale and now it is showing as an internal drive. May have to switch it with my boot ssd that is mounted in the optical bay. Any issues running bootcamp from a PCIe drive that anyone knows of? Don’t really boot into it very often as I mainly use parallels as I need to use coreldraw a bit when working from home.
Chiming into give a big THANK YOU to cdf 
I have two Samsung 970 Evo NVMe drives (256GB boot and 1TB user) mounted to an IOCrest IO-PCE2824-TM2 (aka Syba SI-PEX40129) in PCIe slot 2 of a 5,1.
I also have 4 SSDs with data cables attached to a SATA III controller in PCIe slot 4.
All of these drives appear internal, thank you very much!
Four comments:
1) I believe Innie 1.0.9 needs an update to match the latest Lilu 1.3.0. I originally tried this combination but got the following output when trying to update kextcache
System Information > Extensions also reported dependency errors as seen in the attached screenshot.
When I tried Innie 1.0.9 with Lilu 1.2.9 all dependencies were allowed and the system behaves as expected.
2) In case someone isn’t contemplating this in advance — be aware that resetting NVRAM (aka zapping PRAM) appears to reset SIP restricted and excepted files. This will cause Innie to be ignored on the reboot. You’ll need to go back into Recovery OS to disable SIP, boot and run the commands in Step 6, go back and enable SIP to carry on — basically you’re rebuilding the SIP exceptions to allow the unsigned Lilu and Innie. I added an alias in my .bashrc file so I can easily run all four commands.
3) Innie seems to survive multiple reboots (both shutdown and restart) so for now I am leaving SIP fully enabled. If it ever gets tedious I may adopt the -without kext (and maybe -without fs) customization, but just now I’m uncertain how much actual vulnerability that might introduce in my daily use.
4) Another reason why it’s good to have these PCIe drives appear internal is because, when allowing the App Store to install a security update which invariably requires a reboot, the boot process may select a non-PCIe drive to boot from (e.g. a boot clone) and install the patch to a different drive than intended. It’s not the end of the world, but it does cause confusion and wastes time by having to install the patch twice. This has happened to me, but I anticipate it won’t anymore with Innie on the job.
Thanks again cdf!
I have two Samsung 970 Evo NVMe drives (256GB boot and 1TB user) mounted to an IOCrest IO-PCE2824-TM2 (aka Syba SI-PEX40129) in PCIe slot 2 of a 5,1.
I also have 4 SSDs with data cables attached to a SATA III controller in PCIe slot 4.
All of these drives appear internal, thank you very much!
Four comments:
1) I believe Innie 1.0.9 needs an update to match the latest Lilu 1.3.0. I originally tried this combination but got the following output when trying to update kextcache
Code:
Kext with invalid signatured (-67062) allowed: <OSKext 0x7f9307f63a40 [0x7fffa74e4b30]> { URL = "Innie.kext/ -- file:///Library/Extensions/Lilu.kext/Contents/PlugIns/", ID = "com.innieteam.Innie" }
Innie.kext - no compatible dependency found for as.vit9696.Lilu.
Innie.kext is missing dependencies (including anyway; dependencies may be available from elsewhere)
Kext with invalid signatured (-67062) allowed: <OSKext 0x7f9307f62720 [0x7fffa74e4b30]> { URL = "Lilu.kext/ -- file:///Library/Extensions/", ID = "as.vit9696.Lilu" }System Information > Extensions also reported dependency errors as seen in the attached screenshot.
When I tried Innie 1.0.9 with Lilu 1.2.9 all dependencies were allowed and the system behaves as expected.
2) In case someone isn’t contemplating this in advance — be aware that resetting NVRAM (aka zapping PRAM) appears to reset SIP restricted and excepted files. This will cause Innie to be ignored on the reboot. You’ll need to go back into Recovery OS to disable SIP, boot and run the commands in Step 6, go back and enable SIP to carry on — basically you’re rebuilding the SIP exceptions to allow the unsigned Lilu and Innie. I added an alias in my .bashrc file so I can easily run all four commands.
3) Innie seems to survive multiple reboots (both shutdown and restart) so for now I am leaving SIP fully enabled. If it ever gets tedious I may adopt the -without kext (and maybe -without fs) customization, but just now I’m uncertain how much actual vulnerability that might introduce in my daily use.
4) Another reason why it’s good to have these PCIe drives appear internal is because, when allowing the App Store to install a security update which invariably requires a reboot, the boot process may select a non-PCIe drive to boot from (e.g. a boot clone) and install the patch to a different drive than intended. It’s not the end of the world, but it does cause confusion and wastes time by having to install the patch twice. This has happened to me, but I anticipate it won’t anymore with Innie on the job.
Thanks again cdf!
Thanks, sailmac, for your comprehensive account. I believe that this is the first report of Innie working with a PCI-switched carrier board. Regarding comment 1: the newest version of Lilu (1.3.1) addresses the issue.
Thanks @cdf for this great help. It really came up when i try to find a solution about this issue.
I have a question now. I am using HS 10.13.6 with bootrom 140.0.0.0 on 960gb kingston predator pcie ssd.
After this kext installed. Anyone able to install bootcamp partitioned windows 10 on pcie disk? I am struggling now. Did it once but it got bootlooped. Now will try legacy install. And let you know guys!
I have a question now. I am using HS 10.13.6 with bootrom 140.0.0.0 on 960gb kingston predator pcie ssd.
After this kext installed. Anyone able to install bootcamp partitioned windows 10 on pcie disk? I am struggling now. Did it once but it got bootlooped. Now will try legacy install. And let you know guys!
It says internal on amazon.com. Are you talking about it come up with internally without ant kext?
Edit: sorry my mistake. Understood it after i seen your previous post
Innie should work with any AHCI or NVMe drive.
Interesting! Hopefully somebody can verify this.
That's a bit sad. It seems he may hit some "positive bug" in the macOS, but not Apple intentionally fix this issue.
This is from Developer Joe
He told me that he never install innie, and after one of the beta update, all his drive but one show as internal.
If he has innie installed. All drivers should shows as internal. So, this screen capture actually supported that he didn't lie to me.
And he said after the latest 10.14.3 beta 3 update. All his drives now shows as internal.
P.S. The remaining external one is on the Highpoint card. And the other 3 drivers are all shows as internal on the same Highpoint card.
Last edited:
I just clean installed 10.14.2 and upgraded to 10.14.3 DP4 to check this. Didn't installed HighPoint SSD7101A drivers:
I did the same yesterday too, 10.14.3 DP4. No change on Internal vs External. Just the same as always. All Bay mounted drives show as internal, PCIe drives and USB show as external.
It seems that the kexts are not being installed properly. Make sure that SIP is actually disabled. Entering "csrutil status" in terminal should tell you if it is. If not, reboot into recovery again and disable SIP.
Once you are sure that SIP is disabled, try installing again. Move Lilu.kext (which according to steps 2-4 should contain Innie.kext) out of /Library/Extensions (to the desktop, for example). Rerun the last two commands of step 6. Rerun them until you see "KernelCache ID: ...". Now move Lilu.kext back, carrying out steps 5 and 6. Repeat the last last two commands of step 6 until you see "Kext with invalid signatured ... allowed ..." and "KernelCache ID: ...". Then reboot.
I happened to be checking the status of my kexts to make sure they were up to date and noticed my SM951 was no longer TRIM enabled. It used to be, but obviously something changed. I ran `sudo trimforce enable`, y, y, got the success message, rebooted, and.... still disabled. I tried it with SIP both enabled and disabled, and neither way worked despite getting messaging to the contrary. I have Lilu 1.3.1 with Innie 1.0.9 installed. Any idea what's going on?
Strange. I can tell you that Innie should not interfere with TRIM. Many here are using Innie with TRIM enabled. My understanding is that the trimforce command installs a codeless kext called AppleDataSetManagement. Maybe you can check if this kext is loaded.
It says it's Loadable, but it's not currently loaded:
AppleDataSetManagement:
Version: 1.0.0
Last Modified: 12/7/18, 10:03 PM
Bundle ID: com.apple.AppleDataSetManagement
Loaded: No
Get Info String: 1.0.0, Copyright Apple Inc. 2015
Obtained from: Apple
Location: /System/Library/Extensions/AppleDataSetManagement.kext
Kext Version: 1.0.0
Loadable: Yes
Dependencies: Satisfied
Signed by: Software Signing, Apple Code Signing Certification Authority, Apple Root CA
Would my SIP settings have anything to do with it?
csrutil status
System Integrity Protection status: enabled (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: enabled
DTrace Restrictions: enabled
NVRAM Protections: disabled
BaseSystem Verification: enabled
Also, what about the fact I have my drive partitioned?
Well I figured out the problem. I apparently tried to use AHCI3rdPartySATA.kext at some point to make the drive appear as internal. I don't remember doing this when I reformatted for Mojave, but I guess I did. Removing this .kext and resetting the kextcache fixed the issue. Thanks for the info, guys.