MacBook Pro M1 crash while Raid drive mounting (Softraid 6.0.5 and Mac OS 11.6)
I've got the same issue with both SoftRAID 6.05 and 6.1b13 on MacOS 11.6, M1 Mac Mini.
In testing a few scenarios it appears that the kernel panic occurs when a 4-bay Thunderbay is connected. That Thunderbay has 2 RAID 5 partitions, both of which are APFS (I know - I made a mistake there). I've tried with it connected when booted, and connecting it after booting. No matter what I do there are kernel panics.
When I connect my 8-bay Thunderbay that doesn't lead to a kernel panic. That has 1 RAID 5 partition.
Not sure if that is helpful but hope it is.
Tried without automatic volume rebuilds and kernel panic again.
Can you contribute to the bug report with Apple on this?
SoftRAID tech support file
Panic log (report to Apple, more details, copy/paste it to a support file.
System Diagnose file (paste the below into terminal.app:)
sudo sysdiagnose -f ~/Desktop/
Let me know when you have them.
I suspect if you remove one drive, your volume will mount.
@softraid-support Hmmm. I’ve submitted all three already earlier in this thread. Do you need fresh copies? As stated earlier in this thread, everything works fine with just one drive attached. Removing both drives and attaching to Intel Mac and configuring as mirror also works. Reconnecting pre configured pair to M1 mini also works, but volume won’t mount. Unplugging USB-C drive allows other to Mount. Plugging back in crashes.
We can also remove secondary drive from volume, attach unpaired USBC drive, initialize and add as long as auto-sync is off. But even without sync, we can’t restart without removing this drive, no crash but driver won’t load.
Thanks very much. You can attach a text file and support file. the sysdiagnose is harder. here are isntructions. Paste the link in your reply, I will not post the link.
go to the url:
Click the button that says "I Agree".
Click the "Add your files" button and select the Sysdiagnose file.
Click the ... Button.
Select the "Get transfer link" button.
Click the large "Get a Link" button.
After a short period of time, the wetransfer site will give you a link.
Send that link to us.
Downloading now, will let you know if it is missing anything.
@softraid-support I've repeated many of the same changes on a new M1 Mini with a near identical config, but different Primary drive interface manufacturer (USB-A v3.1). I've still got the exact same model of Secondary interface, SanDisk Extreme 2 USB v3.2 Gen2. I started with blank volumes to do some testing and have thus far not had any pink screens or crashes using 6.1 Beta 11. I've been able to boot, mount and sync an APFS volume.
I've now got a different problem which I'm hoping is simply poor setup on my part; I've moved over the old server's USB drive (v3.1) and have that configured and working with no secondary at the moment. Doing some testing, I noticed that I'm unable to change permissions on this Volume now. Also, when viewing files/folders on this volume, they all show up as owned by "mike:staff", my user account. But when I "sudo -s" to root, all the ownership looks correct. But, even root doesn't seem to be to change ownership on this volume.
Have I done something with 6.1 beta 13 to cause this? Note, I'm still able to view/change ownership of files on the boot volume (non-SR) no problem as either "mike" or "root".
There was indeed a permissions bug when creating volumes in the beta, fixed in our internal b14, which a new beta should be released in a few days.
YOu should be able to change permissions in get info for the volume, however. Can you?
Or maybe it needs to be via command line, which I can get you.
Yes, I think so, we are working on what is causing this, it appears to be an M1 issue, we are looking at any way to get around it we can. Its strange that it is only happening to a small minority of users, when it seems like it should be more consistent/widespread.
Its is also happening to non SoftRAID users, according to reports I have seen elsewhere, but no one has a "fix" that I have found yet. The crash appears to be in the Thunderbolt bus. Why a RAID in particular would trigger it is unknown, except perhaps for the more active I/O on a RAID volume when mounting it.