What Would Cause APFS Volumes to Show Up Under the Wrong Disk?

Question

I’ve got a pretty interesting APFS problem. There are two volumes on one, internal drive, and two that were cloned from it, on an external. All four volumes show up under the internal drive, even though they show up under the right device going by device number. So - you have disk1s1, disk1s5, disk8s1, and disk8s5 all showing up under disk1.

They are also showing up as belonging to disk6, which houses disk8. Disk8 though - it’s listed as “Uninitialized,” and won’t do a thing.

It started like this:

1. My system drive had an fsroot error when checked. It seemed to cause problems with booting and some hangs; I wanted to clone the drive to have a back up to my backups - to be super safe.
2. I couldn’t clone either the disk or the system drive volume. I’d end up with a single file on the target drive that said “tobeinverted.”
3. I used dd to clone the drive. The clone has the same “invalid fstroot tree” problem, of course.
4. After a reboot, the volumes that belong under the external drive are shown in the container disk for the system drive (internal). And after another reboot... unmounting and mounting again...

Meanwhile, I’m unable to get High Sierra reinstalled on the original system drive - it hangs with a completed status bar and the Apple logo. It does this even after I’ve erased it - First Aid / fsck checks out now that it’s wiped, too. So that’s confusing.

I’m going to get myself out of this mess, but since I can’t find anything on this weird issue, I think it could be helpful to someone else in the future.

I don’t know much about these aspects of disk and drive structure and so on, but if fsroot doesn’t stand for filesystem root, I quit everything.

So - the volume has corrupt information about which disk it belongs to? Is that how I ended up here?

They know which device they belong to... it shows up under the Device section, and using diskutil list, or df -h; whatever you like.

The Disk Utility First Aid errors:

error: invalid dstream.default_crypto_id (0x4), given apfs_fs_flags (0x1)
error: xf : INO_EXT_TYPE_DSTREAM: invalid dstream
error: inode_val: object (oid 0x1a24c0): invalid xfields
fsroot tree is invalid.
The volume /dev/disk/ could not be verified completely.

That’s it - if someone has encountered this problem I’d love to hear about your experience.

Answer 1

The plain answer is that APFS volumes (from two separate disks) show up under the wrong disk when the containers share a UUID. Of course when you clone a drive, the UUIDs come along - volumes and the container. Possibly it happens when two volumes have the same UUID as well.

I gave up trying to fix the problem with the UUIDs on the containers. The method I know is to use one of the filesystem utilities -

/System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util or /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util

for example, and since APFS Container partitions don't have a filesystem, I got stuck there, and attacked my problem from a different direction.

---

To fix the UUIDs on individual volumes:

Say diskDsV and diskFsB (both APFS volumes) share the same UUID. You can change one of them by unmounting the volume and doing this:

./System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -s rdiskDsV

If this is a system drive, it's much more complicated. You have a Preboot volume, and you have to change the name of a folder in the root directory of that volume as well - the folder name needs to be the UUID of the system drive.

Even though 2 volumes are shown on the list, when you click on the disk you can see that there are actually 5. Preboot, VM, and Recovery were created automatically, and for the most part are hidden.

So, to take care of this, find the right UUID for the system volume like this (I'm guessing it's s1 - could be different):

./System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -k rdiskDs1

Then, diskutil list /dev/diskD - you'll see the Preboot volume; let's call it sp. Next sudo diskutil mount /dev/diskDsp, then ls /Volumes/Preboot/ and you'll see the folder. If the name doesn't match the UUID of the correct volume, change it.

Two final steps - see here for more - (diskDspNAME being the mount point under Volumes):

Declare where the boot files are:

sudo bless --folder/Volumes/diskDspNAME/System/Library/CoreServices --bootefi

Update the dynamic linker cache:

sudo update_dyld_shared_cache -root /Volumes/diskDspNAME -force