Thanks for your attention. I tried reading the thread you linked. Sanigo first says "I use usb to boot, and use diskutil to fix the partition. But the problem remains after reboot." Then "I used the following to fix the problem: sudo fsck_msdos disk0s1". Is this step 1 and step 2? That's what I assumed, which is why I was trying to create a bootable USB. Is it really "disk0s1" or...?
Because you are *not* booted from the drive you want to fix, you are already effectively in recovery mode with respect to that drive. There's no system dependency upon it, so its volumes can be umounted and structure checked and fixed running from your primary drive.
Let's say you have a physical drive you've made with CCC and renamed to "BACKUP".
Find out the /dev designator BACKUP using
diskutil list
For example...
Here is a sample listing of
/dev/disk1, which includes a normal macOS APFS container (a virtual disk inside) at
/dev/disk3
Code:
% diskutil list
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_APFS Container disk3 2.0 TB disk1s2
/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +2.0 TB disk3
Physical Store disk1s2
1: APFS Volume BACKUP - Data 878.9 GB disk3s1
2: APFS Volume BACKUP 9.3 GB disk3s2
3: APFS Volume Preboot 2.1 GB disk3s3
4: APFS Volume Recovery 1.2 GB disk3s4
5: APFS Volume VM 1.1 MB disk3s5
To be extra clear, there's a bit to unpack above...
As just mentioned, a macOS system drive has two "disks", one for the physical drive itself and one for the APFS system container, which includes a signed-system-volume (protected OS files) the user
Data partition, plus support partitions
Recovery,
Preboot, and
VM.
A drive designator will have 1 or 2 numbers: the first # is the drive HW unit number, e.g.,
disk1, and the second # is the partition unit number, e.g.,
s2.
You can tell these two "disks" belong to the same physical drive because of the name of the container drive disk3 is "BACKUP" and it lists
Physical Store disk1s2.
So, working backwards from the name of paritions within the APFS container, we find the APFS container is located inside
disk1, e.g., partition
2 of
disk1.
NOTE—After you make a copy with CCC Legacy Bootable Copy Assistant, the backup drive has the same name as the source! On a running mac, the boot drive isalways
disk0. If you wanted to repair
disk0 you might have to boot into another macOS.
The ESP for disk1 "BACKUP" in this example is listed as type "EFI". Its designator is therefore
disk1s1
NOTE 2—By convention every GPT drive has its ESP as the first partition after the partition table, e.g., 1 as reported by diskutil list.
Now that you know the ESP's designator
disk1s1 you can check and repair it:
Code:
% diskutil repairVolume /dev/disk1s1
Started file system repair on disk1s1 (EFI)
Checking file system and repairing if necessary and if possible
Volume is already unmounted
Performing fsck_msdos -y /dev/rdisk1s1
** /dev/rdisk1s1
** Phase 1 - Preparing FAT
** Phase 2 - Checking Directories
** Phase 3 - Checking for Orphan Clusters
99 files, 200814 KiB free (401628 clusters)
File system check exit code is 0
Restoring the original state found as unmounted
Finished file system repair on disk1s1 (EFI)
If repairs are needed, you might need to re-run using
sudo diskutil /dev/disk1s1
Other threads suggest booting into recovery mode, but I can't figure out how to do that, if it's even possible on a hackintosh.
A proper hackintosh install will include a bootable recovery volume which will be accessible from the OpenCore picker (not the BIOS picker). But this is academic for the moment.
This is the first thing I tried using HackinDROM. My OS and Applications are on an M2 ssd, and the backup copy is on a partition of an HDD. I updated HackinDROM to 2.1.9, then updated OC to 0.9.7 on the SSD, mounted both ESPs and copied the EFI folder to the backup. But the backup doesn't show up in the picker as mountable. I'm trying to figure out where I went wrong and I keep making more mistakes and hitting walls. Everything is another problem.
This all makes sense... You want to get the EFI of the source drive into the ESP of the backup.
- The capacity of the backup ESP is supposed to be 206.5 MB, but only 142.4 MB is available, even when totally empty. When I try to update the backup using HackinDROM, it says there's not enough space, even though I've emptied the trash. And 142.4 mb should be enough anyway but somehow it's not.
- When Disk Utility first aid, I get partition map and unable to mount errors on the "internal physical disk" and "internal physical volume", but not on the "container disk", "APFS volume group", nor "APFS data volume".
- I tried downloading Sonoma, but I don't know where it is. The installer is not in "Applications".
- I can't even follow simple instructions to create a bootable USB.
It seems that something is damaged about your backup drive ESP.
Try the above to repair it. If that doesn't work, the next step is to consider what caused it to get into a funky state.
For exampke, the next question would be how did you format the drive before using the CCC Legacy Bootable Copy Assistant? And what happened with the drive after it was formatted? Etc... But leave that for later after you've checked and repaired the backup ESP.
