UEFI Partition Not Created macOS13.1

[colinzeal]

I was previously using, Monterey and got the Volume Hash Mismatch error so in preparation of the latest OS I decided to do a clean install of Ventura.

Opencore working perfectly at this point with 100% functionality with the exception of the above.

When trying to install 13.0 and 13.0.1 I was unable to complete the installation having gotten about 60% of the way through installation. I was receiving the error about "Cannot verify this update".

With the release of 13.1, I thought I would try again to test the newest installer and though installed successfully, it was not without its hiccups.

When I first tried, I got the "Cannot verify this update" issue again. But unlike the previous installation attempts with 13.0 and 13.0.1, it took me back to the main menu of the installation. At this point I tested my Internet connection using Safari. Had a quick google and confirmed a working internet connection (ethernet).

I tried the installation again and this time I was successful however, a had a grey screen and had to force restart my machine, booted again and got to the setup assistant which crashed and quit, then on the third time I was into macOS and everything seems to be working ok.

However, I mounted the EFI of both the USB installer and the macOS drive to copy my Opencore installation onto the macOS Drive which I completed successfully.

I rebooted, updated my UEFI BIOS settings to boot from the macOS Drive but the partition is unbootable! It seems the macOS Drive is not compatible with UEFI, but why now? To prove a point, I went into the advanced settings and changed the BIOS to only show UEFI drives in the boot selector menu. The macOS Drive did not appear at all, proving I had made a legacy EFI and not a UEFI compatible one.

Does anyone know how to change this or why this happened?

Disk Utility confirms it is formatted as APFS and GUID partition table.

Currently using:

• Intel 9600k
• Asus TUF Z370 Plus Gaming Board
• Corsair Vengeance RGB 16GB
• Corsair MP510 240GB M.2 Drive

 

[colinzeal]

Any tips?

Sick of having a USB hanging out of the machine just so I can boot!

 

[UtterDisbelief]

Any tips?

Sick of having a USB hanging out of the machine just so I can boot!

Hi there.

Not enough info to go on but ...

The verify update issue can be caused by three common things -

Internet connection
or
BIOS date
or
macOS installer obtained elsewhere other than Apple direct

You seem to have checked the Internet connection.

Next ...

The different versions of macOS changed APFS as the years passed. I would have expected the Monterey version to be fine, but not the High Sierra, for example. It's best practice to format the destination using the Disk Utility included on the USB Installer, as that will match and you will see that destination drive in the Installer itself.

 

[colinzeal]

Hi there.

Not enough info to go on but ...

The verify update issue can be caused by three common things -

Internet connection
or
BIOS date
or
macOS installer obtained elsewhere other than Apple direct

You seem to have checked the Internet connection.

Next ...

The different versions of macOS changed APFS as the years passed. I would have expected the Monterey version to be fine, but not the High Sierra, for example. It's best practice to format the destination using the Disk Utility included on the USB Installer, as that will match and you will see that destination drive in the Installer itself.

This was a clean install.

The git hub command was used to download the software directly from Apple. However there is a second stage to build the installer once it has downloaded the file required.

I think I will have to try again with another clean installation when I can.

I think the installation may have been buggy. But this is unlike Apple.

 

[UtterDisbelief]

This was a clean install.

The git hub command was used to download the software directly from Apple. However there is a second stage to build the installer once it has downloaded the file required.

I think I will have to try again with another clean installation when I can.

I think the installation may have been buggy. But this is unlike Apple.

Check the format of the hidden EFI partition on your destination drive. It should be MS-DOS.

 

[c-o-pr]

I was previously using, Monterey and got the Volume Hash Mismatch error so in preparation of the latest OS I decided to do a clean install of Ventura.

Opencore working perfectly at this point with 100% functionality with the exception of the above.

When trying to install 13.0 and 13.0.1 I was unable to complete the installation having gotten about 60% of the way through installation. I was receiving the error about "Cannot verify this update".

With the release of 13.1, I thought I would try again to test the newest installer and though installed successfully, it was not without its hiccups.

When I first tried, I got the "Cannot verify this update" issue again. But unlike the previous installation attempts with 13.0 and 13.0.1, it took me back to the main menu of the installation. At this point I tested my Internet connection using Safari. Had a quick google and confirmed a working internet connection (ethernet).

I tried the installation again and this time I was successful however, a had a grey screen and had to force restart my machine, booted again and got to the setup assistant which crashed and quit, then on the third time I was into macOS and everything seems to be working ok.

However, I mounted the EFI of both the USB installer and the macOS drive to copy my Opencore installation onto the macOS Drive which I completed successfully.

I rebooted, updated my UEFI BIOS settings to boot from the macOS Drive but the partition is unbootable! It seems the macOS Drive is not compatible with UEFI, but why now? To prove a point, I went into the advanced settings and changed the BIOS to only show UEFI drives in the boot selector menu. The macOS Drive did not appear at all, proving I had made a legacy EFI and not a UEFI compatible one.

Does anyone know how to change this or why this happened?

Disk Utility confirms it is formatted as APFS and GUID partition table.

Currently using:

• Intel 9600k
• Asus TUF Z370 Plus Gaming Board
• Corsair Vengeance RGB 16GB
• Corsair MP510 240GB M.2 Drive

From this report, it seems like there are two problem areas:
1) drives are unreliable,
2) target macOS drive layout is not right.

The fits and starts you are seeing with installation point to a drive with bad blocks or cable issue or RAM edge case or anything that can cause I/O to be unreliable.

Late macOS—since Big Sur 11.2ish introduced the signed system volume SSV—is very sensitive to I/O errors, because every bit of data is verified by the installer and the OS: the installer package is verified with its own hash like when a disk image is checked before mount. Then as the installer runs, it hashes structure of the entire macOS (every file) to permit detection of modifications / corruption (SSV structure).
Moreover, if I/O errors occur during setup, these can cause erratic behavior of the installer or OS and failure to boot.

Your report conveys evidence of all these probs, so start by troubleshooting all the drives you are using to build: for example look for problems with both the installer drive and the macOS target drive.

Background on drive layout for UEFI: the ESP (EFI Service Partition) is a standard UEFI partition for bootloaders and maintenance. Boot loading can be thought of as having three stages: 1) ROM finds and launches a small amount of code from the drive based on its partition table, 2) this code sets up facilities needed to access complex storage and interact with BIOS (ACPI and logical volume mgmt), and 3) initialize the mainline OS. At every stage, work may into arranged into sub-stages. There's a vast amount of per-system history and lore about what goes into the stages and how these interact. Suffice to know that the ESP generally holds stage-2, including OpenCore and that in multiboot setups, different OS loaders have to be designed to not step on each others ESP while observing UEFI standards for file naming, etc. This can be a bad dream which turns into a nightmare when bootloader stages chain-load other bootloaders, as OC and Linux do. Avoid multibooting unless you are prepared to face the music.

Re target drive layout for macOS: Actual Macs keep the stage-2 bootloader in Apple board firmware and Apple only uses the ESP for firmware maintenance and diags. OpenCore works more like Windows and Linux by living in the ESP—Your hack's EFI folder—and interacting with PC UEFI BIOS.

Disk Utility and other drive tools will always create an ESP this when a drive is Erased as GPT (GUID Partition Table). But once the drive is formatted, the ESP won't be automatically fixed if it is disturbed. The way to think about it is the ESP is a shared area which the UEFI drive tool must take the liberty to create on a blank drive, but respect (not clobber) any existing drive layout, where different versions of a system running in different modes may have different dependencies on the ESP.

The macOS installer won't recreate the ESP if it's been corrupted or disturbed due to drive probs or by mis-use of drive format tools. There are various edge-cases regarding health of ESP and macOS.

So a "clean" macOS install means that you reset the target drive by Erasing it as GPT, either by booting into recovery or taking the drive to another system.

To be sure that the drive is completely reset, you can copy /dev/zero over the first few megabytes so Disk Utility sees it as a blank drive (you want to see "macOS cannot read this drive. Do you want to initialize it?"). NOTE: Late versions of macOS, since SIP+, do not permit this operation so you have to boot Recovery or a Linux installer and use terminal.

I predict that your situation is a due to unreliable storage. Suspect all drives. Try a different target and if that doesn't work try a diff installer drive. Or viceversa.

Wipe the partition table of the target and format, install macOS, lastly copy over your working hack EFI to target ESP.

Hth

 

[colinzeal]

From this report, it seems like there are two problem areas:
1) drives are unreliable,
2) target macOS drive layout is not right.

The fits and starts you are seeing with installation point to a drive with bad blocks or cable issue or RAM edge case or anything that can cause I/O to be unreliable.

Late macOS—since Big Sur 11.2ish introduced the signed system volume SSV—is very sensitive to I/O errors, because every bit of data is verified by the installer and the OS: the installer package is verified with its own hash like when a disk image is checked before mount. Then as the installer runs, it hashes structure of the entire macOS (every file) to permit detection of modifications / corruption (SSV structure).
Moreover, if I/O errors occur during setup, these can cause erratic behavior of the installer or OS and failure to boot.

Your report conveys evidence of all these probs, so start by troubleshooting all the drives you are using to build: for example look for problems with both the installer drive and the macOS target drive.

Background on drive layout for UEFI: the ESP (EFI Service Partition) is a standard UEFI partition for bootloaders and maintenance. Boot loading can be thought of as having three stages: 1) ROM finds and launches a small amount of code from the drive based on its partition table, 2) this code sets up facilities needed to access complex storage and interact with BIOS (ACPI and logical volume mgmt), and 3) initialize the mainline OS. At every stage, work may into arranged into sub-stages. There's a vast amount of per-system history and lore about what goes into the stages and how these interact. Suffice to know that the ESP generally holds stage-2, including OpenCore and that in multiboot setups, different OS loaders have to be designed to not step on each others ESP while observing UEFI standards for file naming, etc. This can be a bad dream which turns into a nightmare when bootloader stages chain-load other bootloaders, as OC and Linux do. Avoid multibooting unless you are prepared to face the music.

Re target drive layout for macOS: Actual Macs keep the stage-2 bootloader in Apple board firmware and Apple only uses the ESP for firmware maintenance and diags. OpenCore works more like Windows and Linux by living in the ESP—Your hack's EFI folder—and interacting with PC UEFI BIOS.

Disk Utility and other drive tools will always create an ESP this when a drive is Erased as GPT (GUID Partition Table). But once the drive is formatted, the ESP won't be automatically fixed if it is disturbed. The way to think about it is the ESP is a shared area which the UEFI drive tool must take the liberty to create on a blank drive, but respect (not clobber) any existing drive layout, where different versions of a system running in different modes may have different dependencies on the ESP.

The macOS installer won't recreate the ESP if it's been corrupted or disturbed due to drive probs or by mis-use of drive format tools. There are various edge-cases regarding health of ESP and macOS.

So a "clean" macOS install means that you reset the target drive by Erasing it as GPT, either by booting into recovery or taking the drive to another system.

To be sure that the drive is completely reset, you can copy /dev/zero over the first few megabytes so Disk Utility sees it as a blank drive (you want to see "macOS cannot read this drive. Do you want to initialize it?"). NOTE: Late versions of macOS, since SIP+, do not permit this operation so you have to boot Recovery or a Linux installer and use terminal.

I predict that your situation is a due to unreliable storage. Suspect all drives. Try a different target and if that doesn't work try a diff installer drive. Or viceversa.

Wipe the partition table of the target and format, install macOS, lastly copy over your working hack EFI to target ESP.

Hth

Remarkable advice.

I’m hoping it’s not the target drive. It’s a newish drive so it shouldn’t be a problem however, I used two different USB drives as installers and got the same results.

I think I will have to try installation again.

Although I reformatted the drive during installation, is there a chance is was only reformatted on the surface? So there are still some 1s on the drive?

I think I’ll try getting to the installer and ‘go nuclear’ at wiping the target drive again completely writing 0s across it.

Thanks to both for you advice.

 

[colinzeal]

Check the format of the hidden EFI partition on your destination drive. It should be MS-DOS.

Confirmed as MS-DOS (FAT32).

 

[UtterDisbelief]

Confirmed as MS-DOS (FAT32).

View attachment 561128

Yes, that looks fine.

As I mentioned previously when a drive is not visible to boot from as UEFI, then we need to check the hidden EFI partition and that the format of the main destination is one macOS can use, i.e matching APFS version.

Next you should check any other bootable drives are disabled or disconnected because the system might be looking at the wrong EFI at boot time. This can happen with dual-boot systems with more than one physical drive.

Oherwise, perhaps zip and upload the EFI you have created? I'm only guessing at this stage but an EFI folder of 63.5MB in size is a little large for OpenCore or Clover alone. Perhaps there's a Microsoft folder in there too?