Legacyboot is broken for anything under Big Sur with OC 0.8.8

[ct85msi]

Anything under Mac OS 11 gives me this error when I select MacOS Installer in the picker menu: OCB Loadimage Filed - Unsupported.

I tested this with 3 legacy systems, Penryn, Nehalem and Lynnfield and I could not install anything, only Big Sur+.

If I`m installing MacOS with an online image, it boots in recovery DMG, it completes the 1st stage of the installation and at the picker menu, when I select MacOS Installer it hangs with OCB Loadimage Filed - Unsupported.

If I`m doing an offline install, it gives me the error right at the first step when I select MacOS Installer in the picker menu.

Big Sur boots and installs fine with no modifications to the EFI folder.

I have emulated nvram.

I attached the Lynnfield EFI. EFI.zip

L.E. Attached and the Penryn EFI.

EFI-Penryn.zip

opencore-2023-01-25-113923.txt

L.E. I can confirm that OC 0.8.7 works, does not have this bug.

[ruckusman]

I was also stuck on this also, now having issues even getting OpenCore to boot - it seems that the Legacy Boot has been broken for quite some time.

Can I ask which version you used to get the boot disk made as the BootInstall_X64.tool from 0.8.7 isn't working for me. I either get non system disk from the BIOS or if I use enoch to get the first bootloader, boot, loading from the EFI partition I am then hit with BOOT MISMATCH! BOOT FAIL!

This is just copying the files from the release package to the EFI/OC folder

There seems to be a lot of mismatches in the various elements to even get OpenCore.efi to load successfully

Update - using the 0.8.9 DEBUG: BootInstall_X64.tool successfully loads the GPT partition then I'm still hit with BOOT MISMATCH! BOOT ERROR!

[ct85msi]

I used 0.8.7 and it worked. Try to set SecureBootModel to Disabled and not Optional. I has the same error I think and after setting secureboot to disabled, it worked.

[ruckusman]

Thank you, I'll try that again - I do recall having tried it previously, but I'll start with a clean slate.

I came across your post because of the imageload error

I came across this page: https://github.com/acidanthera/OpenCorePkg/tree/master/Legacy

So from the error, it seems that it's not the OpenCore.efi version that's at issue for the boot mismatch, it's the boot0 and boot1f32 which are the issue.

I have had this working, but I sought out other MBR and GPT boot sector codes, I'm going to work through my notes again and see if I can replicate the success

[HippoInWindow20]

Following, trying to boot Mavericks on Legacy Boot, instead I'm using 0.8.5

[mikebeaton]

Required installers and compiled files are also in Utilities/LegacyBoot of OpenCore releases.

[ruckusman]

Those legacy boot files are broken - I've compiled the boot0.nasm and boot1f32nasm an they bear no similarity to the files in the release. Not sure which source the included legacy boot files are compiled from, but it's not in the available source files.

[ruckusman]

Following, trying to boot Mavericks on Legacy Boot, instead I'm using 0.8.5

I've posted a solution to the Legacy boot failing here if you're having difficulty getting the USB to boot.

https://github.com/acidanthera/bugtracker/issues/2210

The is with the bootX64 in the legacy tools - replacing 'boot' in the root directory of the EFI partition with the one from the zip file at least gets OpenCore.efi to load.

[savvamitrofanov]

@ruckusman The problem with USB boot seen by me and was related to BDS on buggy hardware. The problem isn't in boot files, with them all ok. Try to increase timeout before BootDeviceSelect here (https://github.com/acidanthera/OpenCorePkg/blob/1244a542562bee51c6e79a7437057aea41b93b89/Legacy/BootPlatform/BdsDxe/BdsEntry.c#L475) to 6000000, for example and test again.

[ruckusman]

I wish that were true, I can boot reliably on a GPT formatted USB with the boot file in the EFI partition using both Enoch [Chameleon] and Clover without issue. I used the legacy BIOS block IO in Clover to boot from the GPT formatted USB -> EFI/boot

The issue previously was I believe to do with BIOS block IO being broken, it seems to have re-emerged.

I did try compiling from source, but it threw errors and failed - too much hassle right now given I spent days diagnosing what I thought was MBR and PBR issues when it was the boot file all that time.

Check what I posted here https://github.com/acidanthera/bugtracker/issues/2210 as with OC boot sectors and the modified Clover 'boot' file I can load opencore successfully

[savvamitrofanov]

@ruckusman I perform several tests in past for different legacy hardware, there is no problem with BIOS block IO driver. I compiled 0.8.9 with duet files for x64 and ia32 with mentioned patch. Please try and report if the problem is gone. Be patient boot time increased twice duet_debug.zip duet_release.zip OpenCore-0.8.9-DEBUG.zip OpenCore-0.8.9-RELEASE.zip

[ruckusman]

Thank you, apologies for the late reply.

I did try an EFI folder with the new files and ran the BootInstall_X64.tool from your compilation also. There is a quirk where I need to run fdisk manually to make the first {EFI} partition active otherwise I receive non-system disk error. With the first partition marked active I still get the BOOT MISMATCH! BOOT ERROR!.

One thing that I have noticed is using the OpenCore Patcher, which I have used successfully to make and use Monterey install media for my iMac, it creates a /System/Library/CoreServices/boot.efi, whereas a similar efi file BOOTx64.efi is located in /EFI/BOOT/BOOTx64 is in the zipped release package.

Is there an incompatibility between these files, I've inspected them in a hex viewer and they have similar strings, but they are not the same file by any means.

To me it seems that something is out of sync, is it with these files?

[mikebeaton]

Is someone reporting this issue able to do a bisect and report the specific commit at which the issue first appears, please?

[ruckusman]

Of the two issues in respect of Legacy Boot: I've put the USB install media boot issue here https://github.com/acidanthera/bugtracker/issues/2210. I will work through back releases 0.7.9 -> 0.6.9...to try and locate the release where the issue first occurs.

For reference BOOT MISMATCH also occurred here https://github.com/acidanthera/bugtracker/issues/1326 back at 0.6.4

For the second error I can confirm that 0.8.7 doesn't have the ImageLoad error when the created install media is an SSD/HDD.

EDIT: Update, I've tried going back stepwise to get USB boot working the HP XW8600, 0.7.9, 0.6.9, 0.6.4, 0.6.3 - none work for booting from a GPT partitioned USB drive. Same error in all instances BOOT MISMATCH! BOOT ERROR!

Seems that the XW8600 may be an outlier if GPT partitioned USB keys can boot OpenCore on other systems. Of note I can get GPT partitioned USB keys to boot successfully when setup with either Enoch [Chameleon} and Clover, so it's not the XW8600 BIOS that's incapabable.

[chris1111]

My issue here

it's a shame because for me OC 0.8.0 Duet worked well for me and the changes made on revisions after this one ? to fix the Duet around certain config completely screwed up the boot because the proof here I compiled OC 0.8.9 myself this evening At the source and I use the Duet OC 0.8.0 boot file and I boot without problem Monterey, Ventura and install macOS Ventura 13.2 from USB install Media Using EFI folder OC O.8.9

In fact I boot Catalina until ventura 13

See boot picker

EDIT **

See Video Boot

[mikebeaton]

Please can you confirm whether or not this is fixed by: https://github.com/acidanthera/OpenCorePkg/commit/092af5d99c764cbe06372dfed3fa03af719550cc

Download the macOS XCODE5 Artifacts zip file from the bottom of page https://github.com/acidanthera/OpenCorePkg/actions/runs/3840701149 , and check whether the contained version of OC fixes the problem.

[chris1111]

Please can you confirm whether or not this is fixed by: acidanthera/OpenCorePkg@092af5d

Download the macOS XCODE5 Artifacts zip file from the bottom of page https://github.com/acidanthera/OpenCorePkg/actions/runs/3840701149 , and check whether the contained version of OC fixes the problem.

Not working, same issue for me descrid here

[chris1111]

@mikebeaton Ive test LegacyDuet boot file of release 0.8.9, 0.8.8, 0.8.7, 0.8.6, 0.8.5, 0.8.4 , 0.8.3 Same isssue LegacyDuet boot file0.8.2 Boot OK on EFI 0.8.9 ✅

So in my opinion some thing wrong in LegacyDuet Release 0.8.3 I see Added emulated NVRAM driver for use separately from OpenDuet ?

[mikebeaton]

@chris1111 - Apologies for directing you here, it was a separate issue.

@ruckusman - I am not convinced there is a real issue here. I am not getting any such issue using OpenDuet in OVMF. BOOT MISMATCH! means OpenDuet could not find OpenCore.efi on the drive on which it is installed. BOOT FAIL! means it could not find OpenCore.efi on any other drive either. Are you certain you have at least one bootable FAT drive with OpenCore on? Preferably the one onto which you installed OpenDuet.

@ct85msi - It seems you have resolved your error, correct?

[mikebeaton]

Replicating some related issues now - thanks for heads up @ct85msi

[ct85msi]

Thank you very much.

[ruckusman]

Late in catching up, I have tried the latest compile https://github.com/acidanthera/OpenCorePkg/actions/runs/3840701149 of 0.8.9 on a USB - it still fails with BOOT MISMATCH! BOOT FAIL!

Interestingly I get the above error with USB set as first boot AND if it's the only storage device on the system. BUT if I set USB as first boot device AND I attach my working OpenCore SSD, it does throw the BOOT MISMATCH! error. BUT it then jumps to booting OpenCore from the EFI on the SSD.

As noted previously, the XW8600 can boot from GPT partitioned [EFI - fat32 formatted] using either Enoch Chameleon and Clover.

Given that the XW8600 seems to be an outlier in being incapable of booting OpenCore on a GPT partitioned USB AND I have a working solution booting OpenCore from an SSD, it may not be worth the effort to diagnose further unless it affects other systems also.

My main aim was to eliminate 'other' programs altogether and simplify the process -> GPT partitioned USB -> Opencore -> createinstallmedia command.

[mikebeaton]

Interestingly I get the above error with USB set as first boot AND if it's the only storage device on the system. BUT if I set USB as first boot device AND I attach my working OpenCore SSD, it does throw the BOOT MISMATCH! error. BUT it then jumps to booting OpenCore from the EFI on the SSD.

This is correct. As stated previously, 'BOOT MISMATCH!' means OpenDuet cannot find OpenCore in the drive on which it was installed, 'BOOT FAIL!' means it subsequently cannot find any OpenCore instance on any drive.

Therefore this is as expected, and the only issue is that there is no (usable) OpenCore on the drive on which you installed OpenDuet.

This is a separate issue to the one which @ct85msi has reported, and I believe should be a support/forum issue.

[vit9696]

Could you please link to a build that introduced an issue? I know of no issues with LegacyBoot besides 10.4.x issues.

[chris1111]

Could you please link to a build that introduced an issue? I know of no issues with LegacyBoot besides 10.4.x issues.

Do you please just check my opinion some thing wrong in LegacyDuet Release 0.8.3

EDIT **** Added emulated NVRAM driver for use separately from OpenDuet

[mikebeaton]

@chris1111 These are separate issues. Closed issues are read on this bugtracker - I believe you have a configuration issue, and I believe it is nothing to do with the emulated nvram update. My apologies for initially thinking your issue and this issue were related and directing you here, but please could you follow up on https://github.com/acidanthera/bugtracker/issues/2215 .

[vit9696]

Could you please link to a build that introduced an issue? I know of no issues with LegacyBoot besides 10.4.x issues.

Do you please just check my opinion some thing wrong in LegacyDuet Release 0.8.3

EDIT **** Added emulated NVRAM driver for use separately from OpenDuet

A build, not a release. We need a particular commit when it stopped working. You can use https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true

[mikebeaton]

@chris1111 - Well @vit9696 is happy to treat these together, and perhaps yours is the same issue.

On your issue specifically:

• You were getting a warning message followed by halting on critical error, but this warning message is expected on first start (it just means you have no initial /NVRAM/nvram.plist - the location of nvram.plist was moved into that subfolder, along with other related files), and you had your system set to halt on warning messages.
• Once you changed your system to not halt on warning messages, you got a different, kernel dump crash.
• The upgrade to 0.8.3 was extensively tested on hacks, with no issues.
• I also run it, not on a hack but in OVMF/QEMU, and I have no issues - not then, and not with the 0.8.8 release either.

For anybody with either issue, the specific commit at which your problem appears would be very useful (i.e. as per @vit9696's message).

---

For anybody who is not aware (and perhaps you both/all are) the technique of bisection is very fast - must faster than testing each commit one by one - to find the problem: you just choose a commit half-way between the known good and known bad commit, each time, and depending on whether that is good or bad you carry on from there, until you have two commits next to each other, one good and one bad. (This approach assumes that the issue comes in at a certain commit, within the range being tested, and stays in from then, but that's a good working assumption.)

[chris1111]

Please see this my comment on my issue ➦ Here this morning

[vit9696]

Any progress on finding the relevant commit as per https://github.com/acidanthera/bugtracker/issues/2206#issuecomment-1442571576? I am willing to close this issue as there is no evidence on the particular change breaking things and on our systems legacy boot is working fine.

cc @Goldfish64 just in case

[chris1111]

@vit9696 on my side I can not finding the relevant commit Sorry :) I solved my problem by modifying BootInstallBase.sh

This part ☟

I simply added an nvram.used file in the LegacyBoot folder; thereby creating the missing nvram.plist file in the NVRAM folder. I added a last command to lock the nvram.plist file because MacOS Ventura Installer can try to modify it during the installation of macOS this is what I noticed

nvram.used.zip BootInstallBase.sh.zip

This way I can install macOS with the latest OpenCore update and I use the same procedure for post install on the SSD where macOS is installed My config is a Dell Optiplex 790 boot Legacy because it is impossible to put OpenCore UEFI on the latest Dell Bios it's a really Cheep Bios

As I already mentioned before OpenCore 0.8.3 there was no NVRAM folder created by OpenCore Duet so no I not need to modify the script .

[mikebeaton]

As mentioned above, I believe there is no genuine issue the the emulated NVRAM code here; and if there is, it should probably be raised as a separate issue.

OCVAR: Emulated NVRAM load failed - Not Found
Halting on critical error

only makes sense if you have you Misc/Security/HaltLevel set to include WARN, which is not a recommended setting (it should normally be set to 2147483648 (i.e. 0x80000000), to include ERROR only).

[vit9696]

Yeah, the NVRAM thing is a separate issue. I more wonder about @ct85msi and @ruckusman issue.

——

@chris1111, regarding NVRAM, can you please provide your config.plist?

@mikebeaton, I wonder if there is a possibility of some memory corruption here?

[chris1111]

Yeah, the NVRAM thing is a separate issue. I more wonder about @ct85msi and @ruckusman issue.

——

@chris1111, regarding NVRAM, can you please provide your config.plist?

Yea its here attaching

config.plist.zip

[vit9696]

Yeah, you have HaltLevel set to 2147483650 (DEBUG_WARN and DEBUG_ERROR), should be 2147483648 (DEBUG_ERROR) for the current implementation not to stop loading.

@mikebeaton, I wonder whether we should actually change this to INFO? After all, there is nothing wrong with missing NVRAM contents if we view a warning as something that the user should correct. When halting at warnings is enabled, the setup becomes unbootable after NVRAM reset.

[chris1111]

@vit9696 Yea you right 2147483648 not to stop loading. then I use Ctrl+Enter to the Ventura Icon disk then it create

NVRAM Folder and nvram.plist Message OCVAR: Emulated NVRAM load failed - Not Found Is GONE at next boot

Wonderfull !!!! thanks

[chris1111]

@vit9696 @mikebeaton Thank you both of you

[mikebeaton]

@mikebeaton, I wonder whether we should actually change this to INFO? After all, there is nothing wrong with missing NVRAM contents if we view a warning as something that the user should correct. When halting at warnings is enabled, the setup becomes unbootable after NVRAM reset.

Okay, I just updated it.

(Tbh I went both ways about this for ages - it kind of is a WARN after first boot, but since you can't tell if it's first boot in a way that's properly separate from whether the file exists, then as suggested it should not be a WARN.)

[chris1111]

@mikebeaton as i said then I use Ctrl+Enter to the Ventura Icon disk then it create

NVRAM Folder and nvram.plist Message OCVAR: Emulated NVRAM load failed - Not Found Is GONE at next boot

[mikebeaton]

Thanks, I know. With my recent change it would never have caused you all this trouble even with your previous settings.

[chris1111]

Thanks, I know. With my recent change it would never have caused you all this trouble even with your previous settings.

Test its work, see REL-092-2023-05-07 😅 No message at boot

[vit9696]

Closing this issue, because

• the original issue starters do not seem to provide any information about the commits causing issues for them.
• the second issue with NVRAM is resolved.

[chris1111]

@mikebeaton After updated Monterey , booting on macOS Installer this is the message I receive, with HaltLevel set to 2147483650 do you have a solution for this?

Sorry to reposting here, I thought I would do that instead of opening another issue

[mikebeaton]

So, emulated NVRAM was never initially written under the assumption that it should never warn in normal day to day operation. I don't think there is anything which warns every boot in normal usage, but there may be things such as the two you've discovered which warn on untypical but not actually fatal issues.

I need to do an audit and put it though its paces with halt on warn enabled, as you have, and fix any remaining cases of 'warn but there's nothing for the user to fix'.

In the meantime you will need to run with HaltLevel 2147483648.

[mikebeaton]

I believe that is the only remaining INFO/WARN issue, so have resolved it, and successfully run a Monterey update with HaltLevel 2147483650 using emulated NVRAM on a machine here.