softraid v7 kext fails because of a dependency resolution error

There is a simple way to know if SoftRAID's driver is loading. Connect a thumbdrive, initialize it and create a non RAID volume. If it mounts, all is good.

But I think this is the issue. You have not enabled third party developers. We have a video for M1 on this page:

https://www.softraid.com/docs/softraid-quick-start-guide/installation-macos/additional-steps-for-apple-silicon-macs/

@softraid-support you're mistaken, i completed all steps from the quick start guide and enabled 3rd party drivers. as i wrote my existing thunderbay 4 mini with 4 ssds mounts again after one hiccup in the reboot process and also is visible in softraid. did this with a thumbdrive as requested, no problem with it mounting.

as you can see in the second system report picture from my initial post softraid is loaded. what bugs me is the error as displayed in the system report image:

Fehler bei Abhängigkeiten:

  Dependency Resolution Failures:

  Indirect dependencies can't be resolved: com.apple.iokit.IOStorageFamily

Being a software develeoper myself there is a strong smell and i suspect this would be cause for failure later on when i proceed with creating a raid volume with softraid. i know nothing about iokit, but could it be either

* my default instllation is missing some apple framework/library/... i need to install or

* softraid is missing an error check if the OS subsystem is missing a piece it wants to use later on?

Thats why i ask: is it safe for me to proceed or is it a bug of concern?

here is a fresh softraid technical report if it helps

@andrewf 

I mentioned this to our engineer, who suggested you post this to the Apple developers forum.

This is unlikely to affect SoftRAID, but is an interesting question.

i created a raid4 volume that mounted and seemed fine after the necessary restart. i then installed the new ventura update 13.0.1 which required a restart, and after the restart a flurry of error messages occurred.

Looking in the system report confirmed the softraid kext was not loaded. Another restart brought this dialog

In the system preferences it was still shown as activated (but again kext not loaded), so i restarted again. Which brought this

which upon clicking restart shortly showed a window hinting something like "rebuilding system extension cache" (bad translation from german, sorry). after this final restart it now seems to work fine, did some timemachine and file copying to test.

I was surprised about the number of restarts required, and it seems a rather minor OS updated triggered several restarts and accompanying heart-attack-inducing warnings. Should i expect a routine of several restarts with every OS update? And will this also be the case for the new RSR updates?

@andrewf 

Your analysis is pretty accurate. the extensions cache failed to update. No this is not normal (on a clean install for example).

Apple is working on this, a big problem is the massive changes to MacOS driven by the Apple security team. (to prevent exploits, etc). This results in very poor user experience for professional users, those who need to install drivers, etc.

We are working with Apple for a better solution long term, but it will take a while. Apple has announced they are moving all drivers out of the System, which should avoid all this, but they need to develop kits for this, which are not out at this time, at least for disk drivers.

Did some googling and am rather horrified: as kernel extensions were rated as deprecated since summer 2019 by Apple thats a very slow slow-motion disaster. Dropbox and microsoft onedrive seem to have suffered a similar fate with changing from kext to the File Provider-API, but the bumpy transition experience rested on their shoulders as Apple provided Kits soon enough. As Apple till today (just looked at the developer docs) didnt provide a Kit to help with replacing kext with a system extension for implementing Raid/IODriver, i doubt that "working with Apple" will be fruitful. And even if somewhere in the future there is a Kit, not having a timeline/roadmap is not really reassuring for me as a customer. I cannot base my professional storage requirements on hope.

I am sorry for the bleak reply, please close the issue and thanks for trying to help.

@andrewf 

I cannot discuss any details of our Apple discussions, but there is nothing to worry about here.

i have a follow-up problem after uninstalling softraid as recommended in the manual. after rebooting, the system report wont show the extension SoftRaid, but the raid volume is shown in finder. it turns out that the kext is still loaded:

~$ sudo kmutil showloaded | grep soft
No variant specified, falling back to release
264 0 0xfffffe0006e787f0 0x1b5d 0x1b5d com.softraid.driver.SoftRAID (7.0) 7DE50BA2-D365-3136-804F-763524334DF2 <21 5 4 3>

i tried with another reboot after this command:

sudo kmutil clear-staging

but it had no effect. Next i wanted to get to the recovery mode and turned off my mac. it shut down at first, but the enclosure was still active and after 10 seconds or so turned my mac on without me touching anything. when the startup screen appeared there was a crash message:

i repeated with another shutdown and the same happened again:

both times the crash culprit seems to be the still loaded softraid kext.

please help: how do i get rid of the remains without a complete reinstall of the os?

@andrewf 

Its near impossible to review a kernel panic in a picture, always paste it into text edit, "Make plain text" and post the text file.

To your problem, if you did "uninstall SoftRAID"  and the driver is still loading, this means the MacOS extensions cache is not being refreshed. This is a common MacOS bug.

try this:

sudo kmutil clear-staging
sudo kextcache -i /

sudo kextcache -i /

returns an error message in ventura. and 

sudo kmutil clear-staging

in combination with reboots didnt resolve it either. even setting the security police back to "apple only" didnt do it. only with reinstalling ventura i could erase all traces.

thanks for your help and good luck resolving these horrible user experience problems. 

@andrewf 

I hope during this next year, the correct attention is paid to these issues at Apple. We have some hope on this, but we will have to wait and see when it actually happens!