Big Sur on M1 machi...
 
Notifications
Clear all

[Sticky] Big Sur on M1 machines and SoftRAID issues

Page 9 / 59
(@david1977)
New Member

Hello,

I have a MAcMini M1 with ThunderBay4 and I installed SoftRaid 6 beta while waiting for the final version for the M1.
If I set up a RAID5 (with certification) with the beta version, will the day I put the final version of SoftRaid for M1 up, do I have to redo the certification and installation of the RAID5?
I have another question, the license number for the beta version does not work, is this normal?

Thank you for everything !

ReplyQuote
Posted : 05/01/2021 8:51 am
(@softraid-support)
Member Admin

@david1977

All information about disks is on the disks, RAID volumes are independent of the system. So all will work.

 

the beta versions do not support serial numbers. That is normal

ReplyQuote
Topic starter Posted : 05/01/2021 11:05 am
(@david1977)
New Member

Thank you for the quick reply !

ReplyQuote
Posted : 05/01/2021 11:06 am
(@thierrycoopman)
Active Member

Just a quick note on stability... 

It seems that the OS is having trouble with keeping a SoftRaid Volume mounted. I have an 8TB Thunderblade RAID0, and I try to get my iCloud photo's on that volume.

The Volume becomes "unmounted" in SoftRaid interface, it's mounted in the Finder and Disk Utility. However, unmounting it there is not possible, neither is mounting it in Softraid...

Now, I tried to look into the console logs and came across these:

default 1352.959969+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1352.960971+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1353.330718+0100 Photos PLFileSystemVolumeManager: diskDisappearedCallback for <private>
default 1353.331224+0100 Photos ignoring diskDisappeared due to missing volumeUUID for <private>
default 1353.428112+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1353.449172+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1353.578807+0100 Photos PLFileSystemVolumeManager: diskDisappearedCallback for <private>
default 1353.579591+0100 Photos ignoring diskDisappeared due to missing volumeUUID for <private>
default 1353.646361+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1353.647155+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1353.749641+0100 Photos PLFileSystemVolumeManager: diskDisappearedCallback for <private>
default 1353.750576+0100 Photos ignoring diskDisappeared due to missing volumeUUID for <private>
default 1353.810976+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1353.811717+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1353.921282+0100 Photos PLFileSystemVolumeManager: diskDisappearedCallback for <private>
default 1353.922054+0100 Photos ignoring diskDisappeared due to missing volumeUUID for <private>
default 1353.988544+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1353.989608+0100 Photos Unmount of this disk is not interesting. Does not match <private>
default 1354.084058+0100 Photos PLFileSystemVolumeManager: diskDisappearedCallback for <private>
default 1354.084610+0100 Photos ignoring diskDisappeared due to missing volumeUUID for <private>

 

I'm not attributing this to SoftRaid per se, as SotRaid support mentions, there is a lot going on hardware wise too, but it does seem like something SoftRaid could at least be smarter about, given that the Finder/Disk Utility still have the volume mounted (and operational for use...), it just seems 'unstable' and hence never allows me to finalise an iCloud Photos download (library corruption seems to happen)

Apple is not helpful with "no error messages", just stalling and beach balling... I feel the pain of the SoftRaid engineers trying to make sense of this...

Anyway, fingers crossed this will improve in future versions. Let me know if I can do anything to get more info (stress test, enable debug, whatever...)

 

 

ReplyQuote
Posted : 06/01/2021 7:00 am
(@softraid-support)
Member Admin

I will take a look. I am not sure if I can reproduce this. Can you attach a SoftRAID tech support file? It may help me out on this.

ReplyQuote
Topic starter Posted : 06/01/2021 10:40 am
(@thierrycoopman)
Active Member

Not sure what's in that file, but the volume ThunderBlade is mounted in the finder while the SoftRaid app shows unmounted... 

 

ReplyQuote
Posted : 07/01/2021 2:24 am
(@softraid-support)
Member Admin

SoftRAID app does not fully support APFS yes. It cannot unmount APFS volumes.

I see two disk ejects of the Thunderbay. Is that what you refer to by instability?

Was the cable tightly inserted? Or near where it would be nudged?

ReplyQuote
Topic starter Posted : 07/01/2021 9:45 am
(@thierrycoopman)
Active Member

@softraid-support

Everything is clean, connected and not nudged. 

I understand APFS and the SoftRaid app does not support it yet, so no issue/blame there. 

The ThunderBlade works fine in - I would say day to day use. But putting the Photos.app library on it seems to stress the IO requests and I have not been able to use Photos.app with the library located on the external ThunderBlade drive. 

I was able to copy a 280GB Photo library to it (as I said, "day to day use" from the finder), but the photos.app seem to be special/specific for IO use, and in it's current OS/SoftRaid beta driver a bit unstable on M1 with APFS.

 

I have used the Thunderblade before without issues on an Intel Mac, with HFS+ and having the Photos.app use that volume... 

So the "diskDisappeared due to missing volumeUUID" is the only real logging I could find related to disks, the rest is just the app 'hanging'

Unfortunately I can't reboot the machine every 10 minutes during the week (work happens when you're having fun ;), but I'll retry in the weekend, and try to get more details. 

 

ReplyQuote
Posted : 07/01/2021 10:10 am
(@justvisiting)
New Member

@softraid-support FYI, M1 Macs are having thunderbolt- and HDMI-related kernel panics with many kinds of external hardware. Apple seems to be pretending it's not happening. Lots of discussion about this going back to October with many people returning Mac minis and other M1 Macs within the return window because Apple has done zero communicating with any of them about the issue. Everyone sends in panic logs, and calls Apple support.  But nobody is getting any sense that Apple is even taking the issue seriously.  It's affecting most every kind of thunderbolt hardware which the OS tries to put to sleep (monitors, TB hard drives, TB raid arrays, etc)...

So avoid going on a wild goose chase with suspected driver or kext conflicts. It's a hardware or OS problem on Apple's end affecting nearly everything TB which can be put to sleep.

ReplyQuote
Posted : 07/01/2021 12:21 pm
(@dmwfotos)
Active Member

I am still unable to create any volumes using the Beta software on an M1 MM.

I tried again today after putting two OWC Thunderbolt bridges into service to expand the port count on the M1MM.

Still getting the unable to create a file system on this volume message. I had the file system selected as HFS+.

I noticed that all the SSDs visible in the SoftRaid interface show that the Format is designated as for Intel.

 

Here is a support log after the attempt today.

 

ReplyQuote
Posted : 08/01/2021 3:59 pm
(@softraid-support)
Member Admin

@dmwfotos

 

There are two possible issues.
first, I assume you went through this to allow third party developers? that is required:

https://support.apple.com/en-lk/guide/mac-help/mchl768f7291/mac
Select reduced security and enable this:
Select the “Allow user management of kernel extensions from identified developers” checkbox to allow installation of software that uses legacy kernel extensions.

Second, you have several obsolte extensions brought over from Migrating your data. this can block all extensions from loading.

Here are the most likely suspects. Go there and delete each extension listed:

/Library/Extensions/Belcarra.USBLAN_netpart.kext

/Library/Extensions/Belcarra.USBLAN_usbpart.kext

/Library/Extensions/RemoteControl.USBLAN_usbpart.kext

Then run the terminal.app. Run these two commands (copy/paste them in)

sudo kmutil clear-staging

followed by:

sudo kextcache -i /

 

restart, then run SoftRAID and "reinstall SoftRAID driver" on your startup volume. That should fix this.

 

 

ReplyQuote
Topic starter Posted : 08/01/2021 6:07 pm
(@dmwfotos)
Active Member

@softraid-support

I've done everything you suggest. Including several iterations with different configurations of the security panel. I've included a photo of the panel for reference.

I tried with neither tick box check, with both and with first on only.

 

Nothing has a worked.

I've also included a screen shot of the Softraid monitor panel.

It's curious that the format shown for the drives is GPT (for Intel)

Each time I initialized the drives via Softraid and then created the volume as HFS+.

Screen Shot 2021 01 09 at 12.43.15 PM
IMG 1372

 

 

ReplyQuote
Posted : 09/01/2021 1:52 pm
(@softraid-support)
Member Admin

@dmwfotos

 

Lets try this. Delete this extension:

/System/Library/Extensions/ArcMSR.kext

(You will notice using the below steps, that it is not loadable. So far, I believe that ANY non loadable extensions will prevent ALL Big Sur M1 extensions from loading.

Using the process below:

Solution:
If you have the public beta of SoftRAID 6 installed and volumes are not mounting follow the steps below. If you do not have the public beta installed, you:
1) 
Under the Apple menu, open "About this Mac"
2) 
Click the "System Report" button
3) 
Click "Extensions" under the Software menu
4) 
After a few seconds, a list of extensions will populate. Click on "Obtained By", to sort by that column
5) 

5. Scroll down to the third party extensions. Look for "unsigned" extensions. All extensions that are "unsigned" must be deleted.

The remaining extensions, click on each on in turn. the pane below has more information about each extension. The 12th line has "loadable" If loadable shows this: Loadable: No Then you must also delete that extension.

6) 
With that open, Search your System for "/Library/Extensions" and delete the files
7) 
Then run the terminal.app and paste these two commands:
sudo kmutil clear-staging
sudo kextcache -i /
8) 
If you have not downloaded the latest beta, you can download here. Once installed run SoftRAID
9) 
Select the startup volume in the volume column, right click the volume and select "Reinstall SoftRAID driver"
10) 
You can now restart and your volumes should mount.
If it doesn’t start, please contact our tech support team. We may need a copy of the SoftRAID Technical Support file.

 

ReplyQuote
Topic starter Posted : 10/01/2021 12:43 am
Sunstarfire
(@sunstarfire)
Estimable Member

@justvisiting That would actually explain why I do not have trouble, since I am not putting my disks to sleep..... I will definitely test that.

ReplyQuote
Posted : 10/01/2021 1:19 am
(@dmwfotos)
Active Member

@softraid-support

OK,

Tried the suggested procedure.

First problem is that I could not delete any file in the /System/Library/Extensions/ folder. Thus, it was impossible to get rid of arcMSR.kext

I did remove all the other kext files that did not load even though the info panel said that they were loadable.

Same result with message that file system could not be created for the volume.

You can see in the screen shot that none of the OWC extensions loaded.

 

Screen Shot 2021 01 10 at 10.20.04 AM

 

 

ReplyQuote
Posted : 10/01/2021 10:32 am
Page 9 / 59
Share:
close
open