MP 1,1-5,1 Copying to NVMe drive causing kernel panics

[bluesbop]

Just installed a new M.2 NVMe drive (WD SN750 1TB) via PCIe card (Ableconn PEXM2-130) in slot 2 of my 5,1 MP running Mojave. System recognized the drive, formatted it with Disk Utility (APFS), excellent speed: ~2500 read/write according to Blackmagic. But when I try to copy my system drive to it using SuperDuper, at about 20-30GB the machine abruptly restarts. Tried it 3 times, same results.

Fits the description of a kernel panic, but don't see any .panic files in DiagnosticReports. Doesn't seem to be overheating, the WD stick has it's own heat sink and the card has one as well, running Macs Fan Control and not seeing any temp spikes or higher fan activity before the restart.

Any ideas? Dying to get this M.2 bootable.

 

[bluesbop]

Update: Moved the card to a 4x slot and it’s working fine. Slower, around 1500 unfortunately, but none of the restarts that happened in the 16x slot.

Can anybody comment on possible reasons for that? Something to do with that particular drive or PCIe card not being compatible with the 16x lane, or does that slot tend to be more problematic overall?

 

[KeesMacPro]

I assume it could be caused by the fact that you only installed 1 blade , if I understood your post correctly.

 

[bluesbop]

I assume it could be caused by the fact that you only installed 1 blade , if I understood your post correctly.

Yes, the PCIe card has space for 2 blades but I only installed 1. Is it necessary to have both blades in for the card to work properly in a x16 PCIe slot? The PEX M2-130 card is considered an x8 card but is listed as compatible with x16 slots and supports non-bifurcation motherboards, if that’s relevant.

Here’s a link with information about the card, looks to be the same as the Lycom DT-130: https://www.amazon.ca/gp/product/B07PRN2QCV/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1

 

[bsbeamer]

There are many known conflicts and errors with how it works with APFS that SuperDuper had not addressed last time I looked at it. Carbon Copy Cloner has basically written the white paper on the majority of these issues and Bombich has done a very good job of documenting them and correcting for them within CCC.

If you continue to have issues, have two suggestions:

Try starting NVMe with a clean HFS+ before cloning bootable data. Let the clone software setup the additional partitions with APFS and linkage. Unsure if SuperDuper has been updated to do that with APFS or not. Previous versions were NOT able to.

Try Carbon Copy Cloner and see if it repeats.

 

[bluesbop]

There are many known conflicts and errors with how it works with APFS that SuperDuper had not addressed last time I looked at it. Carbon Copy Cloner has basically written the white paper on the majority of these issues and Bombich has done a very good job of documenting them and correcting for them within CCC.

Interesting. I had suspected SuperDuper might be a factor, and was ready to try CCC if I hadn’t been able to clone to the NVMe in a x4 slot. But considering I was able to do that with SuperDuper, wouldn’t that rule out software being the issue?

I’m going to try moving the card back to a x16 slot now that it has a functioning system on it and see if it will run, just have to wait for some downtime to do that.

 

[bsbeamer]

There is a chance simply running the software again after restart is what fixed your issue. There are two APFS volumes for every APFS partition/container instance, at least for system drives. Misidentification to the incorrect could easily cause this. A restart may have pointed machine to the -data partition or reverse. Creating a true bootable clone like that is not recommended.

The APFS notes from CCC are extensive:

Bombich Software Blog | Bombich Software

bombich.com

I do not see similar notes for SuperDuper APFS published anywhere.

 

[bluesbop]

A restart may have pointed machine to the -data partition or reverse. Creating a true bootable clone like that is not recommended.

Is that something I should be concerned about, or does the fact that it's booting and running properly mean the system was properly cloned?

 

[bsbeamer]

The additional APFS volume may not be cloned or APFS links may be broken. If that is the case it is not truly a clone. It’s likely a working boot drive, just compromising all benefits of APFS. Have a feeling you only went APFS because you “had” to.

 

[bluesbop]

Yes, no choice but to go APFS as of High Sierra. Does the attached screenshot from Disk Utility give any indication if the APFS setup is correct? (MoCoreX is the boot drive name.) If not, is there a way to check?

 

[bsbeamer]

Should have a “- Data” container that looks like a different volume/disk but is basically hidden. CCC easily shows this easily and enables ways to navigate some of this.

On mobile right now, but this might be helpful with screenshot:

Why you might see a new “Data” disk in Catalina

MacOS now splits the operating system and data files into two volumes, but they should never appear on the desktop.

www.macworld.com

 

[nobullone1964]

I would suggest making a time machine backup, boot into recovery and restore from that backup. By doing this you'll get exactly what is on that drive put onto the new drive. If you do a clean install and then add the time machine backup during installation the system files are written over as new so any system changes you made are gone. Try the restore from time machine. It'll erase and put the system back as is.

 

[KeesMacPro]

@bluesbop you may take a look here:

PCIe SSDs - NVMe & AHCI

Don't work, @combatphotog bought one this week and tested. Stupid design, needs additional MOLEX/SATA power even with one blade.

forums.macrumors.com

post #1733
post #1737
post #1739

 

[bsbeamer]

A "proper" APFS system drive should show like this in Disk Utility. If you do not have both of these volumes within the container, something is wrong. Make sure you have "show all devices" selected from the VIEW menu or pulldown button and sidebar enabled.

Worth noting - multiple partitions on a single physical disk has created issues with APFS clones in the past. More notably with multiple partition HDDs (for clone cycles/versions) where drives would take forever to mount. Nothing physically wrong with them and once partitions removed it worked fine. A client recently reported an identical issue with cloning to a single 4TB SATA SSD with 4x1TB partitions (to clone a 1TB APFS system drive). If you are updating an APFS clone in future, suggest sticking with identical size or leaving larger as-is without additional partitions.