macOS (APFS) and bootcamp partitions no longer mount

I could do that, but I could also attach them to a simple SATA to USB adapter. That would be easier. 🙂

I used RAID0, unfortunately. The most vulnerable to failure option I could have chosen, I know. I did it for the performance gain and, knowing that if I setup the RAID in hardware, I could have macOS and Windows. At least I can say that it was reliable for almost two years up to this point.

I have attached the BIOS setup screen for Velocity Duo I captured when I first configured the RAID. I need to stick the card in a compatible PC in order to get to this screen again (the MacPro will not let you get there). I had to dig through some old emails to find out what machine I used to configure it! It is very picky.

If I can get to this setup screen again, it might tell me something more useful about the RAID.

Getting to the Velocity BIOS screen was easier than I thought it would be. I just had to remember I needed to return the compatible PC to Legacy mode (Velocity does not work in UEFI).

What I discovered next is both interesting and encouraging. The RAID seems to have broken but both drives are still recognized. The screens would seem to indicate that I just need to rejoin them. But....will this be a destructive change or will it simply return things to the way they were? Tough decision but it may be the only option.

Maybe I should proceed with caution. I know Apricorn no longer sells this product but they may still be able to answer what will happen to my data if I try to merge them back.

The system is currently booting from a backup of High Sierra on separate drive. This is what was used to generate the diskutil output I posted. Neither OS on the RAID drive is bootable. No attempt by an older macOS system to access an APFS volume has been made.

NOTE: I have a Sierra drive too but not have not booted from it since moving to HS. Not that you've warned me, I won't! 🙂

Yep. I know how to create one. No problem to do that but I'm curious though on why diskutil list must be done from an external boot drive. Looks like my High Sierra backup drive has a working recovery boot option. I have not tried it yet though. Would that be okay to use?

Thanks.

Here is the terminal output when booted from the recovery partition.

Let me know if this is ok.

-bash-3.2# diskutil list

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *128.0 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_APFS Container disk3 127.8 GB disk0s2

/dev/disk1 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *64.0 GB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_HFS Sierra 63.7 GB disk1s2

/dev/disk2 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *500.1 GB disk2

1: Windows_NTFS Storage 500.1 GB disk2s1

/dev/disk3 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +127.8 GB disk3

Physical Store disk0s2

1: APFS Volume Backup 37.8 GB disk3s1

2: APFS Volume Preboot 21.0 MB disk3s2

3: APFS Volume Recovery 522.8 MB disk3s3

4: APFS Volume VM 20.5 KB disk3s4

/dev/disk4 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *2.0 TB disk4

1: EFI EFI 209.7 MB disk4s1

2: Apple_HFS Stash 2.0 TB disk4s2

/dev/disk5 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme +2.1 GB disk5

1: Apple_HFS OS X Base System 2.0 GB disk5s1

/dev/disk6 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *250.1 GB disk6

1: EFI EFI 209.7 MB disk6s1

2: Apple_HFS 249.7 GB disk6s2

/dev/disk7 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +5.2 MB disk7

/dev/disk8 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +524.3 KB disk8

/dev/disk9 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +524.3 KB disk9

/dev/disk10 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +524.3 KB disk10

/dev/disk11 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +2.1 MB disk11

/dev/disk12 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +524.3 KB disk12

/dev/disk13 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +524.3 KB disk13

/dev/disk14 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +12.6 MB disk14

/dev/disk15 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +2.1 MB disk15

/dev/disk16 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +1.0 MB disk16

/dev/disk17 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +2.1 MB disk17

/dev/disk18 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +524.3 KB disk18

/dev/disk19 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +524.3 KB disk19

/dev/disk20 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +1.0 MB disk20

/dev/disk21 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +6.3 MB disk21

/dev/disk22 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +6.3 MB disk22

/dev/disk23 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +524.3 KB disk23

/dev/disk24 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: untitled +2.1 MB disk24

-bash-3.2#

One of the updates was for security essentials definitions. The other was a single critical system update but I did not note which one. It was part of the monthly updates for March, I'm sure.

Mounting did not go so well, with the exception of the EFI:

Mac-Pro:~ jeff$ diskutil mount /dev/disk5

Volume on disk5 failed to mount; if it has a partitioning scheme, use "diskutil mountDisk"

If the volume is damaged, try the "readOnly" option

Mac-Pro:~ jeff$ diskutil mount readOnly /dev/disk5

Volume on disk5 failed to mount; if it has a partitioning scheme, use "diskutil mountDisk"

If the volume is damaged, try the "readOnly" option

Mac-Pro:~ jeff$ diskutil mount readOnly /dev/disk5s1

Volume EFI on /dev/disk5s1 mounted

Mac-Pro:~ jeff$ diskutil mount readOnly /dev/disk5s2

Volume on disk5s2 failed to mount

If the volume is damaged, try the "readOnly" option

Although not listed above I did try mountDisk also.

My apologies. I tried to mount while booted normally from the backup drive. I'll be able to actually see the mounted volumes this way, if successful.

Should I stay in the recovery boot while troubleshooting, for now?

Just disk5 as pictured in my original screencap.

In the Windows world, I would call this a partition table problem. If the RAID configuration is damaged, I do not think we would be seeing any of the separate disks (0,1,2) show up in diskutil.

I may be forced to try to recover the data from the Windows partition using Parted Magic and then wipe it all out and start over. I would lose some data on the macOS APFS partition unless there is a way to recover that also.

When booted up from recovery, the RAID is renumbered as disk 6 but it is the same as disk5 in my first example. It shows up whether booted normally or in recovery.

/dev/disk6 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *250.1 GB disk6

1: EFI EFI 209.7 MB disk6s1

2: Apple_HFS 249.7 GB disk6s2

disk6s0 and disk6s2 do not mount. disk6s0 is my Windows partition (NTFS format) and disk6s2 is the macOS HS boot drive and should be APFS format. Getting the partitions recognized again as their true format would solve the problem. I don't know if it is possible or not.

The RAID was built in hardware with the Velocity card installed in an actual PC. The MacPro just sees it as a single large drive and sees the controller just fine. It is only the two partitions that are damaged in some way.