<< Solved >> Partition map needs to be repaired. Recovery mode??

[Feartech]

How do I boot into recovery? Command-R doesn't work.

that key combo is for real macs

boot to opencore boot picker and press space bar, you should see recovery option

then go to terminal and pop in the command, that should fix the EFI

 

[c-o-pr]

Some followup on a discrepancy in the advice I am offering and the others' advice.

I suggested diskutil repairVolume.

But all the other posts advise using diskutil repairDisk.

If the drive was formatted using Disk Utility and copied using CCC, the partition table will not be damaged, nor will any volume, so neither of these should be needed.

This makes me wonder if it might be that HackinDROM is causing a problem?

CCC will not damage the drive structure.

---

As to repairing, rather than reformatting and re-copying...

Here's what the diskutil man page says about repairDisk

repairDisk
Repair the partition map layout of a whole disk intended for booting or data use on a Macintosh. The repairs further include, but are not limited to, the repair or creation of an EFI System Partition, the integrity of any Core Storage Physical Volume partitions, and the provisioning of space for boot loaders. Ownership of the affected disk is required; it must be a whole disk and must have a partition map.

This might seem like what you want.

But when you run repairDisk, you will see a warning;

Repairing the partition map might erase disk, proceed (y/N)?

At this point you need to be ready to reformat and recopy to the backup drive if it goes wrong.

Here's the man page for repairVolume:

repairVolume
Repair the file system data structures of a volume. The appropriate fsck program is executed and the volume is attempted to be left mounted or unmounted as it was before the command. Any underlying Storage System (e.g. Core Storage, APFS) is repaired before the given target volume. In most cases (e.g. except mount-read-only), the target volume must be unmountable; in all cases, the underlying storage media must be writable. "Live" repair (e.g. of a file-writable mounted volume) is not supported. Ownership of the affected disk is required.

repairVolume is equivalent to "First Aid" in Disk Utility. It will not threaten the drive structure and will ensure the filesystem of the ESP is coherent. If it fails the rest of the drive will be intact. This shouldn't be needed either, but it's less risky.

I think this is what you want.

---

If you are having a problem with a backup drive, do not run diskutil repairDisk on disk0, that is your primary drive. Locate the backup drive's designator as previously described.

And to repeat, as the backup drive is not booted, you do not need to boot recovery or another macOS instance, just use run from your existing install.

---

I suggest that once you get the drive structure resolved, you try something other than HackinDROM to mount your ESPs and copy your EFI folders. You can learn to mount with diskutil directly or find a another helper.

I like CorpNewt's MountEFI script:

GitHub - corpnewt/MountEFI: An even more robust edition of my previous MountEFI scripts

An even more robust edition of my previous MountEFI scripts - corpnewt/MountEFI

github.com

 

[pisomojado]

boot to opencore boot picker and press space bar, you should see recovery option

This WORKED! I'm now able to enter recovery mode.

Also, through trial and error, I did manage to make a Sonoma install usb which also gives me access to the Disk Utility and Terminal tools (I still think the Tonymacx8x installation instructions are outdated and need attention.)

I ran Disk Utility First Aid with success, but no change in the problem of the wrong size ESP.

I ran the following with the recovery terminal, but I'm still not getting things right:

[-bash-3.2# diskutil repairDisk disk0​

Repairing the partition map might erase disk0s1, proceed? (y/N) N​

Repair canceled​

[-bash-3.2# sudo fsck_mdos disk0s1​

-bash: sudo: command not found​

(Later)​

[-bash-3.2# % diskutil repairVolume /dev/disk2s1​

-bash: fg: %: no such job​

-bash-3.2# diskutil repairVolume /dev/disk2s1​

Error starting file system repair for disk2s1 (macOS Base System): Unable to unmount volume for repair (-69673)​

[-bash-3.2# fsck_mdos -y /dev/rdisk2s1​

-bash: fsck_mdos: command not found​

-bash-3.2# fsck_msod -y /dev/disk2s1​

-bash: fsck_msod: command not found​

Attached is the results from diskutil list.

 

[c-o-pr]

[-bash-3.2# % diskutil repairVolume /dev/disk2s1

Haha I'm sorry, zi inadvertently included the % prompt from the shell which happens to be a shell job control shortcut. That's why it responds with % no such job

Leave out the %

 

[c-o-pr]

Re "sudo" command not found.

That's a command for privilege escalation, to root. It's needed when running Terminal as a normal macOS user

When in recovery's Terminal you're already root and sudo isn't available in that Terminal.

The shell prompt is a clue... If it's a % that's normal user. If it's a # that's root user. (usually, there are exceptions to every rule).

 

[Jasonhacks]

[-bash-3.2# sudo fsck_mdos disk0s1​

[-bash-3.2# fsck_mdos -y /dev/rdisk2s1​

-bash-3.2# fsck_msod -y /dev/disk2s1​

These are no no no.

the correct command is

fsck_msdos disk0s1

 

[pisomojado]

More failures at spell casting from the recovery terminal:

[-bash-3.2# sudo fsck_msdos disk2s1​

-bash: sudo: command not found​

[-bash-3.2# sudo diskutil /dev/disk2s1​

-bash: sudo: command not found​

[-bash-3.2# diskutil repairDisk disk2s1 A whole disk must be specified​

(later)​

[-bash-3.2# fsck_msdos disk2s1​

** /dev/rdisk2s1 (NO WRITE)​

could not read boot block (Permission denied)​

[-bash-3.2# diskutil /dev/disk2s1​

diskutil: did not recognize verb "/dev/disk2s1"; type "diskutil" for a list​

Als, not sure if this is a cause or a symptom, but maybe worth noting that four years ago I set up Ted Howe’s EFI Partition Clone Script to “make things easier” with CCC and lately I’ve been getting an error: “The postflight shell script exited with a non-zero exit status.” This meant nothing to me, so I ignored it. I tried to attach it but couldn't. It's called "EFIClone-v4.sh"

 

[c-o-pr]

diskutil repairVolume /dev/disk2s1
Error starting file system repair for disk2s1 (macOS Base System): Unable to unmount volume for repair (-69673)

This is the best command because it will figure out the right type of filesystem on its own.

As to why it won't unmount...

Is disk2 in fact the backup drive?

Maybe I was wrong about disk0 always being the boot drive and the drives are enumerated by their bus position.

Use diskutil list as previously explained to locate your specific backup drive.

s1 is appropriate partition for the ESP —assuming it's not a APFS container disk.

 

[c-o-pr]

More failures at spell casting from the recovery terminal:

[-bash-3.2# sudo fsck_msdos disk2s1-bash: sudo: command not found

sudo not needed in recovery terminal

[-bash-3.2# sudo diskutil /dev/disk2s1-bash: sudo: command not found

Same

[-bash-3.2# diskutil repairDisk disk2s1 A whole disk must be specified(later)

repairDisk takes a whole drive designator, eg disk2, not a partition designator, eg disk2s1

Make sure you are targeting the correct drive!

[-bash-3.2# fsck_msdos disk2s1** /dev/rdisk2s1 (NO WRITE)could not read boot block (Permission denied)

Disk2 is probably an APFS container.

Make sure you are targeting the correct drive.

[-bash-3.2# diskutil /dev/disk2s1diskutil.: did not recognize verb "/dev/disk2s1"; type "diskutil" for a list

Omitted a command to diskutil, eg, list, repair, etc.

 

[pisomojado]

Disk2 is probably an APFS container.

Make sure you are targeting the correct drive.

Yes, I ran "diskutil list" and the results are attached (as above). The reason I think that disk2s1 is the problem is that when I mount the ESP it is labled EFI-ST8-DL6