<< Solved >> Opencore Issues (BIOS? NVRAM?) No idiocy in taking the 32 bit xxx.efi files instead of 64 bit.

[Westsurf]

Sorry for the generic subject .... better description of issue in Post#5

Could anyone tell me why this APFS drive looks so overtly complicated? Is this correct / good ?

 

[jaymonkey]

@Westsurf,

Yes it all looks correct

Explanation of BSD names :-

• disk0 is the physical SSD
• disk0s1 is the GUID EFI partition on disk0
• disk0s2 is the APFS partition on disk0
• disk1 is the APFS container on disk0
• disk1s1 - disk1s5 are the APFS volumes within the disk1 APFS container.

This is just how APFS works, yes it can look somewhat overly complicated if your new to APFS.

You can have multiple APFS containers on a single GUID formatted drive and multiple volumes within a APFS container but MacOS still keeps the standard GUID BSD naming convention, this is one of the many features that makes APFS such a powerful file system.

Cheers
Jay

 

[Westsurf]

@jaymonkey well I have the strangest of situations. My main hack is on that NvME M2 SSD. It has an Opencore 0.6.7 EFI.

If that NvME M2 SSD drive is removed from my machine I cannot boot from any other Opencore EFI drives whether SSD or USB.

I get the "insert bootable drive" error. This issue arose trying to get a OC 0.6.8 USB to work. Initially thought it was NVRAM error.

I‘ve been racking my brain, reading everything and everywhere I can, and I just can’t find a solution.

 

[Edhawk]

That error is BIOS Boot option related. It is not finding the UEFI partition containing the OC EFI Folder. Change the Boot order in your BIOS so the other drive is set as the default boot drive.

 

[Westsurf]

@Edhawk I have utilised the F12 “Choose boot drive” function on my Gigabyte MB to choose the boot drive when testing and that had worked consistently since i started with this MB until recently. The issue(s) started when I was trying to the latest Opencore update to 0.6.8 and trying to get the visual picker in particular.

I was happily migrating my way out of Clover to Opencore ("OC"). When I started OC journey it was 0.6.5 but quickly went to 0.6.7 and , now, 0.6.8. The whole time using F12 to choose either the USB to boot or a SSD drive.

Initially using OC was purely an experiment to see if I could get a Big Sur install on a spare disk. It required a different SMBIOS than OC suggests for my system to install which I did finally have success in doing. During that time all of the OC upgrades and changes were via an USB test drive before applying the EFI to the relevant SSD EFI.

As OC seemed to be much better than Clover I thought I'd migrate my main Mojave "hack" (which was using Clover and the preferred SMBIOS Imac14,2) which is on the Samsung NvME, and when I started that process Opencore was on 0.6.6 which I then upgraded to 0.6.7 . One thing that I distinctly remember was that to achieve that OC update I had to do a NVRAM reset to actually get the 0.6.7 OC bootloader. I did that and viola it worked showing 0.6.7 bootloader.

I have four OS SSDs on this machine running various versions of OSX and Windows:

1. Main NvME Drive with latest Mojave.
2. BACKUP SSD of Mojave (which I upgraded to Catalina via direct upgrade. Now reverted back to just being the Carbon Copy of the Mojave NvME)
3. SSD with Big Sur
4. Windows 10
5. Various USB sticks as test EFI, installers, etc

I have been doing various OC updates, did a Apple upgrade of Mojave to Catalina on the Mojave clone drive to test Catalina. Everything happily moving along with occasional issues (USB mapping was initially difficult).

Then I noticed , trying to update OC to 0.6.8 and in particular to utilise the external visual picker was that even when using a USB with a test OC 0.6.8 was that the OC bootloader was always stating 0.6.7 and no visual picker. So figured another NVRAM reset ... um no go What was noticeable there is if I tried to clear NVRAM via Terminal and "sudo nvram -c" was that I got the IOKit error in Mojave and Catalina disks.

I did finally find that Opt+CMD+P+R on boot is doing a NVRAM reset as my Apple ID login needed to be reentered. No other NVRAM reset variants worked. Yet despite the NVAM reset, I'm was still stuck on the 0.6.7 OC regardless of what drive was prioritised in the BIOS or chosen as the Override Drive via BIOS or F12 at start up.

It was this stage that I decided to remove the main NvME drive as an experiment to see if my assumption that OC was always defaulting to that drive was correct. That was then the more confusing behaviour was noticed. In that when I remove the Mojave NvME drive (mounted on a Pcie board as the is no MB mounted NvME slot on my MB) every other OSX SSD / USB drive (except the Window 10 drive. It's MBR not UEFI) when chosen as boot drive states "insert bootable media". This is despite all the “media” having EFI folders with OC. This is why I am wondering if the “modded” BIOS required to use a NvME on the GA-Z77-UP5 TH MB may be part of the issue?

So I've re-flashed BIOS, reset and Cleared CMOS, I even removed the CMOS battery and de powered. Nothing has changed.

So here lies my quandary ... is it that an OPENCORE bootloader version is effecting the BIOS?

Is it that modded BIOS version 12f to allow NVME will only default to the NvME EFI partition now?

Is there something sitting in NVRAM always pointing to the NvME drive EFI?

This is where my inexperience and lack of knowledge about Opencore and the NVRAM is seriously inhibiting finding a solution.

Edhawk - I appreciate your comment but there has been a distinct change in the boot behaviour during since I started the with this hack and the process of swapping from Clover to OC and the various updates. I’ve always been able to boot off an appropriately set up USB until now.

I've found solutions to almost every roadblock I've come across during the many years with this Hackintosh. This one has me completely stumped.

 

[Westsurf]

OK some further info. Perhaps it is that I am getting BIOS boot selection. Note that the NvME drive is installed ATM. It's Mojave on the picker screen.

Using BIOS F12 Boot Selection and choosing 0.6.8 USB test:

Start

USB Files [EDIT - Hint the problem is first noticed here]

Picker screen ... note states 0.6.7

Boot off NvME. Different start screen layout.

Picker

Can someone advise is it that the bootXXX.efi file naming changes between DEBUG and RELEASE.

In my downloaded 0.6.7 folders the boot efi is named:

DEBUG - BOOTIA32.efi
RELEASE - BOOTX64.efi

OC 0.6.8 both DEBUG and RELEASE have BOOTIA32.efi

So does the start up screens suggest they are booting from different sources?
Then is the issue still this "locked out of NVRAM" resets? Hence picker still showing 0.6.7?

- OH 32 bit BOOTIA32.efi

For god's sake.

 

[Westsurf]

@jaymonkey @Edhawk

SOLVED ... feel so stupid ATM. The TEST USB had the 32 bit efi files from the 0.6.8 RELEASE not the 64 bit ones.

 

[Middleman]

Can someone advise is it that the bootXXX.efi file naming changes between DEBUG and RELEASE.

In my downloaded 0.6.7 folders the boot efi is named:

DEBUG - BOOTIA32.efi
RELEASE - BOOTX64.efi

OC 0.6.8 both DEBUG and RELEASE have BOOTIA32.efi

So does the start up screens suggest they are booting from different sources?
Then is the issue still this "locked out of NVRAM" resets? Hence picker still showing 0.6.7?

I think you are using the wrong version of Opencore Boot EFI (that's what seems to be causing the problem). You need to use just bootx64.efi - only this file should exist in your EFI/BOOT folder and nothing else (other than EFI/OC with the config.plist and relevant EFI files of course). It should be stated there should also not be any Debug or Release folders at all on the EFI partition.

 

[Westsurf]

I think you are using the wrong version of Opencore Boot EFI (that's what seems to be causing the problem). You need to use just bootx64.efi - only this file should exist in your EFI/BOOT folder and nothing else (other than EFI/OC with the config.plist and relevant EFI files of course). It should be stated there should also not be any Debug or Release folders at all on the EFI partition.

Middleman ... there was only one BOOTXXX.efi .

Sadly it was the one from the 32 bit folder.

Back on track again.

Sore head from banging it against the wall so much the last weeks though.

 

[Middleman]

Middleman ... there was only one BOOTXXX.efi .

Sadly it was the one from the 32 bit folder.

Back on track again.

Sore head from banging it against the wall so much the last weeks though.

Yeah that was what I was referring to. It should have been the 64bit version not 32...