stuck on picker about nucintosh

[laradvance]

[laradvance]

Using it with Big Sur beta 10, no problem
After update to beta 10.0.1, sometimes (not always) the system cannot boot.
Just return to OpenCore picker menu

NUC8i3BEH

[zearp]

I haven't tested with anything newer than beta 10. Please stay with Catalina and use Big Sur for testing only.

There could still be another beta until the GM is ready. Until then things change and things will break. It's not worth the time to keep track of what each beta breaks and how to fix it cuz in the next beta it may be fixed and/or new issues introduced.

You say sometimes it boots and sometimes it doesn't. Would be helpful to know whats happening, like messages displayed; errors or panic. Without those there's not much I can do.

[zearp]

I just downloaded the latest beta and did a clean install without any issues. Didn't have to disable SecureBootModel or change anything other than the Intel wifi kext. I don't know what happened on your end, you gotta provide some logs and more information. If I can do a clean install on a stock NUC it should work for all. So for now I'm closing this issue until more information is provided.

[ex-git]

I also got this issue with the latest Big Sur installation and your latest EFI. Just tested couple reboot and sometimes after selected boot screen will go black for couple seconds and show picker again. But without count down. Repeat couple times will boot eventually. Tried with fresh installation 2 times. No log saved even with some debug flag turned on. Strange. @zearp

[zearp]

I did a clean install of 11.1 a few times this week when testing some Big Sur stuff. Many reboots of the system and didn’t run into this once. Please provide me with steps to reproduce it, else it’s going to be a guessing game.

Try wiping nvram, it may help. You can also setup the debug logging but it will slow down booting up but may reveal why sometimes you see nothing or get stuck. I haven’t experienced any of those issues myself so I don’t know.

If you run other operating systems they could mess with nvram variables too. Many factors could be at play. I only run macOS on mine so my testing here is limited. I just format the disk and wipe nvram when clean installing and after upgrades.

[ex-git]

[snipped — please don’t quote complete posts]

The steps to reproduce the issue is quite simple. Clean install and reboot in different ways. I did reset nvram many times too. Finally I unchecked DevirtualiseMmio and check ProvideCustomSlide under Booter Quirks. Also AppleXcpmCfgLock need to be checked since NUC 8 has locked cfg. I am able to boot without randomly stuck in picker now.

[zearp]

The NUC has no CFG Lock. You can verify that in the bios. It’s not there. You can’t turn it on or off cuz it doesn’t exist. I also can’t reproduce this issue no matter how hard I try. I have several NUCs in use all running macOS. Guess I must be doing something wrong since I have no issues at all on any of my machines.

[zearp]

Just rebooted my main NUC about 20 times and not a single time did I get "stuck" in the picker.

ProvideCustomSlide is not required on the NUC. You can verify this by booting with a debug version and check the logs. I've tested this and its why it's disabled. Feel free to repeat my tests to verify.

Note: The necessity of this quirk is determined by OCABC: Only N/256 slide values are usable! message in the debug log. If the message is present, this option is to be enabled.

As for DevirtualiseMmio, the quirk is technically not needed but it does free up some memory when debugging. Which is a good thing in my book. I doubt any of these quirks have anything to do with getting "stuck" in the picker.

[ex-git]

Ok. I tried a completed fresh install again. Here is what I found:
With DevirtualiseMmio checked. Randomly stuck in picker when reboot. Like you hit enter, black screen, then picker show up again after couple second. Then you repeat. Eventually it will boot into system.
With DevirtualiseMmio unchecked. Won't boot at all.
With DevirtualiseMmio unchecked and ProvideCustomSlide checked. Boot into system without stuck.
With DevirtualiseMmio checked and ProvideCustomSlide checked. Boot into system without stuck.

DevirtualiseMmio:
How it does this is it takes MMIO regions and removes runtime attributes allowing them to be used as space for the kernel to sit comfortably, pair this with ProvideCustomSlide quirk means we can keep the security feature of slide while also getting a bootable machine.

Maybe that is only for my machine. I am using NUC8i7BEH. But if anyone else also having the same issue. Might just try DevirtualiseMmio unchecked and ProvideCustomSlide checked.

For the CFG lock, I couldn't find anything from BIOS also. You are correct AppleXcpmCfgLock is not needed unless Intel hide it under different name.

[zearp]

It must be something in your setup. Maybe different BIOS options or version, I don't know. I have the same models here and haven't ran into this issue and I do install/reinstall and of course reboot quite often.

Your own test shows DevirtualiseMmio doesn't influence anything. You can leave it on or off depending on your preference. Enabling it only leads to positive things as far I can understand the documentation about it:

This option reduces stolen memory footprint from the memory map by removing runtime bit for known memory regions. This quirk may result in the increase of KASLR slides available, but is not necessarily compatible with the target board without additional measures. In general this frees from 64 to 256 megabytes of memory (present in the debug log), and on some platforms it is the only way to boot macOS, which otherwise fails with allocation error at bootloader stage.

This option is generally useful on all types of firmware, except some very old ones such as Sandy Bridge. On some types of firmware, a list of addresses that need virtual addresses for proper NVRAM and hibernation functionality may be required. Use the MmioWhitelist section for this.

As per OpenCore documentation I pasted in my earlier post, providing custom slides is not needed and I don't think ProvideCustomSlide does anything at all without also setting ProvideMaxSlide and/or others. So really weird enabling it would fix this already weird issue.

None of these KASLR slide fixes and quirks apply on the NUC, we do not need any of them which is why they're disabled. If it fixes your weird issue thats good but I'm not going to change the config since I can't reproduce this issue. I've done a lot of rebooting today and didn't manage also on other NUCs, most running Catalina and two running Big Sur.

Theres no logical explanation as to why enabling a quirk that doesn't apply to this platform would fix it. At least I can't think of anything. You can check why/how these options are used if you're curious: https://dortania.github.io/OpenCore-Install-Guide/extras/kaslr-fix.html -- I just know they're not needed and that its very strange it somehow fixes it for you. But at least it's fixed.