Bootstrap causes BIOS corruption on Gigabyte Z87 if to make reset CMOS

[sandymc]

Configuration: OpenCore 0.6.2, Haswell CPU, Gigabyte Z87-UD3H motherboard with "F7" BIOS

Setup: Bootstrap enabled

<key>BootProtect</key>
			<string>Bootstrap</string>

Symptoms:

1. "OpenCore" shows as first entry on boot list
2. "OpenCore" entry is retained, even if the drive with OpenCore installed is physically removed.
3. It is not possible to enter BIOS setup. If the CMOS is reset, then the motherboard effectively becomes "bricked". This can only be recovered by reflashing the BIOS, or switching to backup BIOS
4. If you attempt to enter BIOS setup, a blank screen with a cursor is displayed - the BIOS appears to waiting for something.

Resolution:

1. Reflash BIOS
2. Disable Bootstrap:

<key>BootProtect</key>
			<string>None</string>

Comments:

1. This issue has been documented in multiple threads, e.g., https://www.tonymacx86.com/threads/opencore-locks-out-bios.303762/, https://www.reddit.com/r/hackintosh/comments/i5otbx/failed_opencore_install_broke_bios_cant_boot/, https://www.reddit.com/r/hackintosh/comments/frg1ph/opencore_catalina_cant_access_my_bios_anymore/, etc, etc
2. It appears to be mostly Haswell CPUs on either Z87 or Z97 motherboards
3. IMHO, even if the corruption issue didn't exist, (2) above, the OpenCore entry remaining after drive removal, is unacceptable.

[vit9696]

Well, I have a Z87 board, and it works for me. We cannot control the BIOS boot options when we are not executing, and the options we create are following UEFI spec, so all of this is a BIOS flaw.

There is a note in the pdf that on some boards Bootstrap may cause issues, so I guess there is nothing to change on our side. Sorry for inconvenience.

[Andrey1970AppleLife]

I confirm this bug on Gigabyte GA-Z87X-UD4H too.
I am stimulated to refuse use Bootstrap, because reset CMOS "Kills" BIOS.

[mhaeuser]

Is it really the CMOS reset itself that kills the board? On my Z77X-UD3H, Dual BIOS kicking in bricked the main chip. It was only visible to me it kicked in because the backup chip FW chip had a different boot screen from the latest available usually on the main chip.

[sandymc]

What happens is, at least on my system, until you reset the CMOS, the board can still boot, although you can't access the BIOS setup screen to change settings. However, if you then reset the CMOS, then the board attempts to boot into the BIOS settings screen, which it can't do becuase the BIOS is corrupt. So then, unless you can recover via e.g., switching to the secondary BIOS, the board is effectively bricked. However, if the board still boots, you can use a BIOS flash program to reflash the BIOS.

[Andrey1970AppleLife]

But if not to use Bootstrap, reset CMOS doesn't cause a problem.

[sandymc]

BTW, the change to the bug title from what I originally posted is misleading. The various threads I quoted in the original post make it clear that this occurs on multiple different mother boards, both Z87 and Z97, and from multiple manufacturers. But almost all reports are of Haswell CPUs.

[sandymc]

On my board at least, not using Bootstrap doesn't corrupt the BIOS, so then CMOS reset isn't a problem.

[Andrey1970AppleLife]

BTW, the change to the bug title from what I originally posted is misleading. The various threads I quoted in the original post make it clear that this occurs on multiple different mother boards, both Z87 and Z97, and from multiple manufacturers. But almost all reports are of Haswell CPUs.

Most likely the vendor Gigabyte therefore other vendors have no such problem here is important.

[sandymc]

The issue has also been reported on Asus boards.

[Andrey1970AppleLife]

@vit9696 doesn't confirm a problem on Asus Z87.

[naidb]

Good news for me now opencore no longer causes the bios to be locked. Many thanks to developers.

[kaoskinkae64]

When did I start using opencore for version 0.5? I already had the first corruption of the bios of my gigabyte z77x-d3h and I did not know the reason now I think that the corruption of the bios is confirmed for a third time, making it impossible to enter with the delete key or f12. Is there any viable solution to be able to use opencore without corruption of bio if I will have to stay with clover

[mhaeuser]

@kaoskinkae64 Using latest OC may resolve the issue by its own, or it may be resolved by using BootProtect=BootstrapShort: acidanthera/OpenCorePkg@b2bec0f

[kaoskinkae64]

I'll wait for the official version 0.6.4 and the documentation on BootstrapShort. Anyway, on my new gigabyte z390 board, I have it disabled, I do not trust the use of the bios as a boot issue, I prefer to select the hard drive with opencore and the others disabled

[mhaeuser]

@kaoskinkae64 That is fine, BootProtect was mainly introduced for machines that do not automatically scan storage devices (well, for anything but Windows) so you don't have to manually add an entry via UEFI Shell and do so again after each NVRAM reset. If the FW works OOTB, there is no reason to enable this.

[kaoskinkae64]

@Download-Fritz Thanks for your time so the best recommendation if you have multiple boot (m2 bigsur, ssd bissurbeta, windows 10) is to have it disabled. And even for security, I also in hackintosh spain facebook I recommend always having it disabled and starting via bios

[vit9696]

We did a rather broad research on boot option issues, and discovered a large amount of implementation flaws in the firmwares across different broads. While this is quite sad, for the boards we had at hand we were able to synthesise some workarounds, and as a result modern OpenCore (0.6.4) should mostly work fine.

We applied these workarounds whether or not BootProtect is enabled. So, to reduce the chance of an issue of e.g. boot option duplicates, BootProtect is no longer required. It is still recommended for usage, and we believe that presently either Bootstrap or BootstrapShort, or both are compatible with practically any board in the wild. However, to reduce the risks of guessing when configuring a new board, BootProtect is set to None in the Sample.plist. You are advised to enable this after you are done configuring your board.

When upgrading to 0.6.4 we recommend:

1. Turn off BootProtect (set to None)
2. Make sure that you have RequestBootVarRouting enabled.
3. Perform NVRAM reset (as long as you know it is compatible with your firmware) to cleanup the leftovers of the previous implementation.
4. Enable BootProtect once again. The safer approach is for older boards (approximately Haswell and earlier) to use BootstrapShort and for newer boards go with just Bootstrap.

Non-comprehensive issue summary:

• Options with full device paths (i.e. the ones including your HDD information, produced by Bootstrap) are mishandled by older boards. This was observed on GA-Z77-DS3H (AMI BIOS) and HP 15-ab237ne (InsydeH2O BIOS). One can diagnose it by the appearance of a new OpenCore option in the BIOS preferences after each boot of OpenCore with BootProtect = Bootstrap. The workaround is to use BootstrapShort.

• Boot0000 option is reserved on ASUS boards and is treated as a deleted entry. This was observed on ASUS ROG STRIX Z370-F GAMING (AMI BIOS). One can diagnose it by repeating options in the end of the list in the BIOS preferences increasing after the use of removable drives. This should not happen with OpenCore as long as you use release builds and made sure to follow the upgrade steps with NVRAM cleanup.

  • An important detail of this issue is NOT to boot and especially install Windows or Linux outside of OpenCore. I.e. via BIOS preferences. These operating systems are known to create Boot0000 on their own will, which can brick your BIOS unless something prevents it. To be clear, the problem is not related to OpenCore, but OpenCore can protect your firmware from these operating systems.

• Firmware may create corrupted boot option list by erroneously accessing Boot#### variables outside of EFI Global Variable GUID namespace. This was observed on ASUS ROG STRIX Z370-F GAMING (AMI BIOS), ASUS Z170m-Plus (AMI BIOS), and many other ASUS boards. OpenCore keeps a list of Boot#### options in its private namespace to keep track of which operating system it should boot first. Due to a terrible mistake in the ASUS firmwares they may try to access this private list. The workaround implemented in OpenCore 0.6.4 is to avoid using the word Boot in the variable names.

  • It is recommended to make sure that Fast Boot is disabled in the firmware preferences as its code is responsible for creating corrupted boot option list. While modern OpenCore should work with and without Fast Boot, the exact consequences of having it enabled are still not fully understood.

• Higher boot option numbers are discarded by the firmware. This was observed in HP 15-ab237ne (InsydeH2O BIOS). The workaround was to abandon the idea of Boot9696 as an OpenCore option and use the lowest available number starting from 0001. This is implemented as of the current 0.6.4, and following the upgrade steps above should resolve the problem.

I request this to be carefully taken into account and mentioned in the guides to help the users troubleshoot their setups.
CC @Andrey1970AppleLife @dhinakg @Download-Fritz @khronokernel @zhen-zen.

[Andrey1970AppleLife]

Now in last the version OpenCore Bootstrap or BootstrapShort don't corruption BIOS if to make reset CMOS
Thanks.

[narcyzzo]

i can confirm this problem on ASUS Z97 too, I will check this update

[telepati]

There is something I cannot understand. If an operating system other than macOS is not installed on our system, is it the best option to set Bootstrap "None"? Or do we still need the Bootprotect option? If it is irrelevant, please ignore the question.

[vit9696]

I would say it depends on the firmware. BootProtect is definitely not a requirement, and if you do not have another operating system on your computer, given a properly functioning firmware there can be little need in this option. It can be of help if your computer prefers external drives to internal ones, and you would like to ensure that your system boots from the internal drive even if you insert a USB flash.

[Abbasm234]

is there any 0.6.5? i tried build tool still showing 0.6.4

[narcyzzo]

Confirmed 0.6.4 Release and BootstrapShort Fixed this! Great work guys. ASUS Z97 Pro Gamer

[Abbasm234]

After updating to Opencore 0.6.4, Windows is not showing on OpenCore Menu! i installed it via bootcamp

[kaoskinkae64]

And in the case of not being able to start from OC with windows since having a DSDT patched by Maldonado Olarila it is impossible to start. And in functional dual systems which would be the best option to boot from OC or from bios (gibabyte f12)

[dreamwhite]

And in the case of not being able to start from OC with windows since having a DSDT patched by Maldonado Olarila it is impossible to start. And in functional dual systems which would be the best option to boot from OC or from bios (gibabyte f12)

DSDT patched by Maldonado Olarila, really? Why should you even use it's dsdt? There's no documentation about what it does and may be dangerous for your system. Best approach is writing ssdt from hand :")

[dreamwhite]

@vit9696 I've updated another hackintosh to OpenCore 0.6.4 (it's a Z370 Prime A II with i7-9700K and 5700Xt) without disabling BootProtect. Do you think that disabling it, resetting NVRAM, updating to OpenCore 0.6.4 and re-enabling it is the best approach even if old Bootstrap implementation was working before?

[vit9696]

It is not too critical as in this case the only thing that is not going to be updated is the identifier of the Bootstrap option (9696 instead of lowest available). On some boards that may cause duplicated entries to appear or failing to enter firmware preferences. Yours might be unaffected, but in general we tried to keep safe and recommend resetting NVRAM to all people. I would say you could postpone resetting the NVRAM on your firmware till you see any issues as I did.

[kaoskinkae64]

@dreamwhite Well, if you are so kind to explain to me why not use the Maldonado Olarila dsdt patched for OC because everyone trusts it

[dreamwhite]

@dreamwhite Well, if you are so kind to explain to me why not use the Maldonado Olarila dsdt patched for OC because everyone trusts it

First of all that's not the right place where to ask this but I'll try to write a short response

Adding random ACPI devices because rEaL mAcS HaVe ThEm" isn't a good reply :"). Even acidanthera suggests using less ACPI patching because if you exceed with them you'll probably have an unstable machine.
Also, does maldon share its knowledge with the hackintosh community? I don't think so. The patches he applies are a secret sauce that nobody knows except him. From what I saw when I was in Olarila forum, he uses the same patches for 100/200/300/400 series motherboard. That's not the right way to adopt when patching ACPI. I even found AWAC device for a Asus Z370 which doesn't require it.
Do you need more explanation or we can leave this conversation? ❤️

[kaoskinkae64]

@dreamwite sorry for the intrusion but I've been turning the issue of the patched dsdt for some time and even your answer has been clear to me. Thanks for replying to the topic

[Jolopu]

I followed the OC update instructions to update to 0.6.4. BootProtect set to None, reset NVRAM and so on. But when I reboot I get the error "Unable to load OC configuration!" I reverted back to 0.6.3 and everything is fine on my Haswell i7 4790 and Gigabyte GA-H87-HD3.

[dreamwhite]

I followed the OC update instructions to update to 0.6.4. BootProtect set to None, reset NVRAM and so on. But when I reboot I get the error "Unable to load OC configuration!" I reverted back to 0.6.3 and everything is fine on my Haswell i7 4790 and Gigabyte GA-H87-HD3.

Have you double checked bootx64.efi and the other files?

[Abbasm234]

Your EFi must be in a folder or your Plist is not there.

[Jolopu]

I copied the files again and now it works! Thanks!!

[neemagha]

@vit9696, for those of us with ASUS motherboards, what are the recommended settings to protect against this problem? Thank you.

[vit9696]

I would say:

• RequestBootVarRouting = YES
• BootProtected = Bootstrap
• DuduplicateBootOrder = NO

Bootstrap is a good thing to turn on, but it is no longer mandatory. Also DeduplicateBootOrder is now deprecated.

[ErbiumStrike]

when I boot windows 10 from opencore bootloader, system manufacturer etc. is showing as Acidenthera and even i have to sign in again to microsoft account and also iTunes on windows is signed out. Is there anyway to fix it?

[anaaarki]

@vit9696, привет.

BootstrapShort is good. But it still breaks boot priorities in my BIOS. It is important for me to use the windows 10 loader in the first place. But after loading the OpenCore, the windows 10 loader takes second place (I can set the priority manually in the BIOS, but after loading the OpenCore, the windows 10 loader will return to second place). What's my mistake? I need the loader of windows 10 to be the first, because windows do not load successfully from an OpenCore due to ACPI.
I am using Chinese X79T board (Q77 chipset) with bad chinese made AMI BIOS and IvyBridge-E CPU (Xeon E5-1650v2)

OpenCore 0.6.4
Bootstrap: BootstrapShort
RequestBootVarRouting: No

Thank for you work

[vit9696]

@aussiekendoll you could use Custom SMBIOS mode.

@anaaarki works as intended. Bootstrap always sets OpenCore to the first position. I suggest you fix your ACPI.

This thread is becoming a support topic, so I will rather lock it to avoid extra misunderstanding. Use the forums for other inquires.