Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Innie 1.3.0 works perfectly with the instructions from post #9 on a cMP 5,1 2012 that I’m setting up as a Server for a client - no OC or RFP - just a plain, standard HS installation. Thank you again for the continued work in developing this tool/resource.

I've been experiencing issues with drives in the direct connect bays (SATA II sleds - bay 2 and bay 3) disappearing on a cMP 5,1 2012 Server, and where they didn't just unmount - they were completely missing even in System Information and Disk Utility. This wasn't the case when using Innie 1.2.1 before I upgraded to V1.3.0. I have now downgraded to 1.2.1 and have experienced no issues since.

I also started having issues with portable USB drives (plugged into the USB 3.0 PCIe card) disappearing, but that persists even after downgrading back to 1.2.1 so I can't put that down to Innie.
 
I wonder if someone could help me. I installed innie and followed the instructions on the first page and my nvme went from external to internal and was working fine for a couple of days. All good thanks very much!
However I've just booted my mac up and the drive has gone back to external. I don't think I've done anything new but it's this a known thing? I'm using a 5.1 2010 mac with mojave.
Any help appreciated
 
I wonder if someone could help me. I installed innie and followed the instructions on the first page and my nvme went from external to internal and was working fine for a couple of days. All good thanks very much!
However I've just booted my mac up and the drive has gone back to external. I don't think I've done anything new but it's this a known thing? I'm using a 5.1 2010 mac with mojave.
Any help appreciated
If you used Innie 1.3.0 then try the previous version, Innie 1.2.1.

Also are you using OpenCore or RefindPlus? If so you may be doubling up the Innie kext. Provide more info on your setup in your signature.
 
Just tried with newest Innie version and unfortunately my problem is still there (drive showing up as external, like with some others). First of all, seems like Innie is installed and at least doing something:

Code:
log show --predicate 'message contains "Innie:"' --last 2h
Filtering the log data using "composedMessage CONTAINS "Innie:""
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL 
2021-04-02 12:04:53.749798+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: starting
2021-04-02 12:04:54.662970+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: found PCI root PCI0
2021-04-02 12:04:54.662973+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.664103+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.665233+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.666361+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.667490+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.668619+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.669747+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.670876+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.672006+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.673136+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.674266+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.675395+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.676525+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.677655+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.678785+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.679914+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.681044+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.682173+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.683304+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.684433+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.685562+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.686692+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.687822+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.688953+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.690084+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.691214+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.692345+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.693476+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.694606+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.695737+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.696868+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.697914+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.699590+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.701129+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.702763+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.704327+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.705924+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.707506+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.709115+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: waiting for PCI root to be configured
2021-04-02 12:04:54.710785+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: found device SATA
2021-04-02 12:04:54.711014+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: adding built-in property
2021-04-02 12:04:54.711343+0200 0x73       Default     0x0                  0      0    kernel: (Innie) Innie: found PCI root in 974685 attempts
--------------------------------------------------------------------------------------------------------------------
Log      - Default:         44, Info:                0, Debug:             0,

Next I analysed the ioReg Entries, and compared them with the entries for my Apple provided SSD. And mybe I found something, i.e. the "built-in" properties do not match up.

First if we look at the entry just below the NVME Controller (see screens, ANS2@0 for the Apple one, and pci144d,a808@0 for the Samsung one) we can see that there is no built-in property set for the Samsung.

Now if we go up two nodes further, we arrive at RP17@1B (Apple) respectively DS0C@C (External Samsung). The Apple node has built-in set as well, but not so for the external entry. Only if I go up further the tree (arriving at US00@0) I can find this entry for the external drive as well.

Going even further up, now arriving at the entry just below AppleACPIPCI both devices seem to have built-in set.

So we have built-in set one more time for the internal one, and also further up the tree compared to the external one ... so maybe this is the problem it does not work correctly for some?

I guess adding more built-in entries just like with the internal drives - or setting this property on a different node of the device tree - could be worth a try?
 

Attachments

  • Bildschirmfoto 2021-04-02 um 13.21.04.png
    Bildschirmfoto 2021-04-02 um 13.21.04.png
    1.1 MB · Views: 132
  • Bildschirmfoto 2021-04-02 um 13.20.55.png
    Bildschirmfoto 2021-04-02 um 13.20.55.png
    1 MB · Views: 116
  • Bildschirmfoto 2021-04-02 um 13.21.56.png
    Bildschirmfoto 2021-04-02 um 13.21.56.png
    734.3 KB · Views: 112
  • Bildschirmfoto 2021-04-02 um 13.22.05.png
    Bildschirmfoto 2021-04-02 um 13.22.05.png
    939.9 KB · Views: 119
  • Bildschirmfoto 2021-04-02 um 13.22.45.png
    Bildschirmfoto 2021-04-02 um 13.22.45.png
    1.1 MB · Views: 122
Hi @cdf - first and foremost appreciate the time & effort put into a project like this.

I'm having some issues. Using the latest Innie 1.3 on a cMP 5,1 with a 1TB 970 Evo Plus (with the firmware update to make it OSX friendly). Running Mojave 10.14.16 and latest 144 boot-rom.

Following all instructions makes the drive appear internal for only one reboot.

Disabling SIP, or enabling SIP doesn't seem to make a difference. I can re-run the instructions and it will be gone on the subsequent reboot, but then on the next, it's back on the desktop.

The .kext is definitely loaded, but after a reboot the drive reappears.

Is there any other information I can provide to see if there's a way to keep it gone?

TIA.
 

Attachments

  • Screen Shot 2021-04-12 at 1.30.26 pm.png
    Screen Shot 2021-04-12 at 1.30.26 pm.png
    27.5 KB · Views: 114
  • Screen Shot 2021-04-12 at 1.32.12 pm.png
    Screen Shot 2021-04-12 at 1.32.12 pm.png
    46.4 KB · Views: 115
  • Screen Shot 2021-04-12 at 1.32.34 pm.png
    Screen Shot 2021-04-12 at 1.32.34 pm.png
    18.3 KB · Views: 111
  • Screen Shot 2021-04-12 at 1.34.20 pm.png
    Screen Shot 2021-04-12 at 1.34.20 pm.png
    15.7 KB · Views: 122
Following all instructions makes the drive appear internal for only one reboot.

Disabling SIP, or enabling SIP doesn't seem to make a difference. I can re-run the instructions and it will be gone on the subsequent reboot, but then on the next, it's back on the desktop.

The .kext is definitely loaded, but after a reboot the drive reappears.
Booting into another OS and back can have an effect like this, but just rebooting shouldn't. If Innie is indeed listed as loaded in System Information > Software > Extensions, then this may be related to a bug in version 1.3.0 where Innie thinks that the drive is already internal. The next version will address this issue.
 
Booting into another OS and back can have an effect like this, but just rebooting shouldn't. If Innie is indeed listed as loaded in System Information > Software > Extensions, then this may be related to a bug in version 1.3.0 where Innie thinks that the drive is already internal. The next version will address this issue.

Thank you so much for the prompt reply!

Definitely not loading any other OS. Just a standard power off, then next day power on and the drive is back.

Have checked in Software > Extensions and it's definitely loaded, so it sounds like it could be the bug you are describing.

Just so I know when to look out for a new release, do you have a vague ETA? This is by no means a typical user's "HURRY UP WITH THE FREE SOFTWARE, BUDDY!", but just so I know when to check back in (days/weeks/months is fine!).

Thanks again for all the work.
 
@cdf help needed; I have 7101a with four drives installed. Innie is installed and the drives still show up as external.

I looked into system information; for some reason 7101a does not show up under "NVMExpress"; but the individual drives do show up under "PCI". Am I missing a driver?
 
Just so I know when to look out for a new release, do you have a vague ETA? This is by no means a typical user's "HURRY UP WITH THE FREE SOFTWARE, BUDDY!", but just so I know when to check back in (days/weeks/months is fine!).
I'll try to get around to it soon ;)

@cdf help needed; I have 7101a with four drives installed. Innie is installed and the drives still show up as external.
It should work if you're not using the HighPoint driver for RAID. However, as mentioned above, there is currently a bug in version 1.3.0. Perhaps that's the issue you're facing.
 
I'll try to get around to it soon ;)


It should work if you're not using the HighPoint driver for RAID. However, as mentioned above, there is currently a bug in version 1.3.0. Perhaps that's the issue you're facing.
I am actually using HighPoint driver for RAID! Are you suggesting that I switch to the MacOS soft raid instead? Is there a way to do this without having to format the drives?
 
It is well known that macOS sees PCI drives in a cMP as external. In the past, there have been several attempts to fix this annoyance, typically through codeless kexts and driver patches. However, these approaches are far from perfect.

Codeless kexts affect the properties of all (even non-PCI) drives. We therefore have to settle for calling all drives SATA or PCI. Patches can be dangerous, especially if applied to critical kexts. After system updates, these modifications can prevent the system from booting. There are also bootloader approaches, but these are better suited for hacks and not real Macs.

The problem is not just cosmetic. Improperly identified drives can cause issues for Boot Camp Assistant and the macOS installer.

I am currently working on an actual kext that addresses the problem. The kext simply changes the pertinent properties of PCI drives so that they can be seen as internal. So far, the approach works nicely with the 256 GB Apple SSUBX and the 240 GB Kingston HyperX Predator, the drives which I possess. This is how the drives now appear, for example, under Storage in About this Mac:

View attachment 780549

If there is interest in the community for the kext, I will make it available. However, to support other drives, particularly NVMe ones, I would need the names of PCI drives reported in System Information:

View attachment 780555

And, of course, some brave testers. Let me know if you're interested!

Current device list: Innie should now work with any SATA (AHCI) or NVMe drive.

Please refer to Post #9 for the kext and installation instructions.
By running innie, can I finally have boot camp installed on an nvme drive?
 
By running innie, can I finally have boot camp installed on an nvme drive?
The internal drive requirement concerns running Boot Camp Assistant on High Sierra and earlier. However, current approaches to installing Windows on a classic Mac Pro (detailed here in the forums) no longer involve Boot Camp Assistant and work fine with many NVMe drives.
 
The internal drive requirement concerns running Boot Camp Assistant on High Sierra and earlier. However, current approaches to installing Windows on a classic Mac Pro (detailed here in the forums) no longer involve Boot Camp Assistant and work fine with many NVMe drives.
That's pretty exciting to hear thanks!
 
Installation
  1. Enter the following commands in terminal:
    Code:
    sudo chmod -R 755 /Library/Extensions/Innie.kext
    sudo chown -R root:wheel /Library/Extensions/Innie.kext
    sudo touch /Library/Extensions
    sudo kextcache -update-volume /
    [/LIST]
    [/QUOTE]
    
    Do I have to write anything after "update-volume /"  ?
 
I've been using Innie for years now and never had a real problem, besides having to re-enter the terminal commands after every OS / security update (guess they overwrite something).

I recently installed a new driver for my audio interface and ever since my drives are seen as external again the next morning. I guess the driver is also somehow overwriting some of the Innie commands on every startup. Is there a way to make Innie immune against this kind of overwrite?
 
I'm having trouble with this install and keep getting this error.


Mac-Pro-51:~ paulharper$ sudo kextcache -update-volume /


/ locked; waiting for lock.


Lock acquired; proceeding.


Warning: /AppleInternal/Library/Extensions: No such file or directory


Mac-Pro-51:~ paulharper$
 
  • Like
Reactions: dabotsonline
I'm having trouble with this install and keep getting this error.


Mac-Pro-51:~ paulharper$ sudo kextcache -update-volume /


/ locked; waiting for lock.


Lock acquired; proceeding.


Warning: /AppleInternal/Library/Extensions: No such file or directory


Mac-Pro-51:~ paulharper$

IIRC I've had that once when installing 1.2.0 on a fresh Mojave install.
After removing the 1.2.0 kext , Installing 1.0.9 (debug) version solved it and still works perfectly.
 
  • Like
Reactions: dabotsonline
IIRC I've had that once when installing 1.2.0 on a fresh Mojave install.
After removing the 1.2.0 kext , Installing 1.0.9 (debug) version solved it and still works perfectly.
do You know where I can get a copy of v1.0.9?
 
Warning: /AppleInternal/Library/Extensions: No such file or directory

Still same error!

There's no such folder as 'AppleInternal'?
 
  • Like
Reactions: dabotsonline
@cdf ... know that you are a big advocate of using device properties but there are situations where this does not work and there is a need to fall back on Innie when this is the case.

The OCLP and MyBootMgr do this fallback and it would be great if the mystery bug (which appears to affect v1.3.0) could be closed out (if possible).
 
@cdf ... know that you are a big advocate of using device properties but there are situations where this does not work and there is a need to fall back on Innie when this is the case.

The OCLP and MyBootMgr do this fallback and it would be great if the mystery bug (which appears to affect v1.3.0) could be closed out (if possible).
I know. I'll try to free up some time to address this.
 
  • Like
Reactions: Dayo
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.