1

Background: My partner decided to upgrade her work iMac to Mojave. Apparently, towards the end of the process, it hung on a black screen, said an error had occurred and would try to recover. It cycled this process a few times before aborting and asking to either restore from a time machine backup or do a fresh OS install.

Having no Time Machine backup, she opted for the fresh install. The first hint that something went wrong with the drive is that the only choice to install to was her external (non-Time machine) drive, which she did. This installed El Capitan, which does not support APFS.

Theory: Because this is a Fusion drive, it didn't get converted to APFS until now. Part of this process must've gone awry and now the drive is unrecognisable. Because the backup OS that installed itself to the secondary drive is only El Capitan, it's not capable of identifying APFS volumes. diskutil showed two disjoint SSD and HDD volumes with no CoreStorage group present.

In my bumbling attempts to fix this, I did not research ahead of time to find out about the Mojave APFS conversion. I tried recreating a HFS+ partition, then running Disk Rescue on that. Naturally, it didn't find anything. I took a drive image (stupidly after the fact...) home to try and run forensics on it, but because it was likely encrypted, it seems unlikely I'll find anything.

I did, however, notice what looks like an APFS block header at the beginning of the partition:

1+0 records in
1+0 records out
512 bytes copied, 7.4092e-05 s, 6.9 MB/s
00000000  68 4b 56 14 14 fc fd 0c  01 00 00 00 00 00 00 00  |hKV.............|
00000010  04 00 00 00 00 00 00 00  01 00 00 80 00 00 00 00  |................|
00000020  4e 58 53 42 00 10 00 00  ac 45 8d 0e 00 00 00 00  |NXSB.....E......|
00000030  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  02 00 00 00 00 00 00 00  64 b8 83 b0 64 92 43 35  |........d...d.C5|
00000050  b9 07 a5 af d1 9d 31 78  06 04 00 00 00 00 00 00  |......1x........|
00000060  05 00 00 00 00 00 00 00  18 01 00 00 5c 6c 00 00  |............\l..|
00000070  01 00 00 00 00 00 00 00  19 01 00 00 00 00 00 00  |................|
00000080  08 00 00 00 0e 00 00 00  06 00 00 00 02 00 00 00  |................|
00000090  0a 00 00 00 04 00 00 00  00 04 00 00 00 00 00 00  |................|
000000a0  93 9a 28 00 00 00 00 00  01 04 00 00 00 00 00 00  |..(.............|
000000b0  00 00 00 00 64 00 00 00  02 04 00 00 00 00 00 00  |....d...........|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

As far as I can tell, ac 45 8d 0e 00 00 00 00 would indicate 244,139,436 blocks of 4096 bytes, yielding 999,995,129,856 bytes -- just around the 1TB drive size.

Because the partition still has some APFS block headers seemingly intact, I'm hoping it might be possible to overwrite the GPT to tell it to treat the partitions as APFS instead.

I see a few pitfalls to this theory:

  1. Fusion Drive: Because this is a fusion drive, I might be able to restore the HDD drive by itself, but that doesn't mean it's going to be at all functional...
  2. Encryption: Because the faculty requires that drives be encrypted, it was likely HFS+ encrypted before the upgrade. I don't know how APFS encryption operates, but this sort of procedure sounds like it might be likely to mess with that.
  3. Overwriting the partition table: In my misguided attempt to recreate the partitions, I wonder if I might've made things unrecoverable. Even if we didn't write anything to the fresh partitions, it'll still have created the usual .DS_Store and related files.
  • I don't have access to the machine at this time, only the partition image, so I can't provide the output of gpt or diskutil or anything that might be relevant until then... – Camille Oct 21 '18 at 1:57
  • Using the experimental apfs-fuse driver, I was able to inspect and mount the image. It shows as empty and unencrypted, although random slices of the drive data show near-perfect entropy. I'm guessing part of the installer panic recovery also attempted a clean APFS format. Since that means the original block number and volume encryption keys are most likely lost, it seems as though this is unrecoverable even if I were to restore a valid GPT table. – Camille Oct 21 '18 at 19:50

You must log in to answer this question.

Browse other questions tagged .