Contribute
Register

<< Solved >> OpenCore 0.8.6 - slow to get to drive picker menu

Status
Not open for further replies.
Joined
Feb 25, 2011
Messages
32
Motherboard
Gigabyte H370 Aorus Gaming 3
CPU
i5-8600
Graphics
RX 570
Mac
  1. MacBook Pro
I have a working OpenCore 0.8.6 EFI that boots to Ventura. But after the initial OpenCore load text, I have a long wait - like well over a minute - before OpenCore's drive picker menu comes up. There's nothing on screen during this long pause; it's totally blank, which led me to think that it had actually crashed at first.

After the picker menu finally does come up, I can pick my Ventura drive and all is good.

My OpenCore 0.8.1 EFI, which I still have on another drive, gets to the drive picker menu in just a few seconds. (That version of OpenCore won't boot to Ventura, of course, but is still good for the Monterey install that I have on that disk.)

Not sure how to debug this one. The opencore.txt files in the EFI partition show nothing. Many of them show as "Zero bytes" in fact.
 
Which drive are you using for macOS Ventura?
Which drive are you using for macOS Monterey?

If you are using a Samsung M.2 drive with Ventura the issue may be Trim related. Trim stopped working on Samsung drives, can cause a significant delay in booting, in macOS due to an issue with the Samsung firmware. See the threads/posts below.



Disabling Trim in your config.plist may help.

Others have resorted to using other makes of SSD/NVMe. Using their Samsung drives for Windows or Data storage.
 
Thanks for the responses, guys.

Neither drive is Samsung.

Ventura is on Kingston SA400S37240GMedia. Monterey is on Western Digital WDC WDS500G2BOA-00SM50.

I’m pretty sure trim settings are disabled. I’ll recheck that though.

Update
Confirmed that trim is disabled on both drives.

In the meantime, my slow menu seems to have magically resolved itself :). I did change some BIOS settings - can't remember which now - so may be it was one of those.

A nastier problem is that after running and shutting down Ventura, my PC won't reboot. I can't even get to the BIOS screen. Eventually, if I wait long enough it will eventually restart.

I've seen other posts about this issue and it looks to be USB-related. I'll post separately about that if I can't solve it.


Update 2
Reboot issue fixed. I had to enable EHCI/XHCI Hand-off setting in the BIOS.
 
Last edited:
Actually the slow time to menu has now returned, although it's not as slow as before.

I think I probably need to redo my USB drives. I last did this for Big Sur, I think, and it still had USBInjectAll in the mix. I removed the latter, but I didn't redo the USB drives scan, which I probably need to do.
 
I've remapped my USB ports with USBToolbox and updated the config.

It hasn't helped, sadly :cry:. Time to get to the drive picker menu can take well over a minute, although at other times it's probably about half that.

Definitely feels like it's trying to query something or other, but I can't see what. There's no debugging info on screen, just a blank screen. The opencore-YYYY-MM-DD-######.txt files on the boot EFI drive have no info; they all show as zero bytes for today :think:.

Where else to look?
 
Why didn't you use the USB configuration guide on this site? It is fairly straightforward and easy to follow.


Post a copy of your new USB configuration, so we can see what you are using.
Post a screenshot of Hackintool > USB tab, so we can see what your system is seeing and activating.
 
Why didn't you use the USB configuration guide on this site?

The guide to which you've linked is a thread of 154 pages. Its first page says to use USBInjectAll.kext, which is no longer maintained, I believe.

I followed the USB guide on the Dortania site, and as per their advice, mapped my ports with USBToolBox. So the guide that I followed was actually the Readme on the USBToolBox repo, with a bit of help from this Youtube video. I've attached the UTBMap.kext that it generated.

I didn't use Hackintool but I did check that my config.plist passed ocvalidate.
 

Attachments

  • UTBMap.kext.zip
    1.1 KB · Views: 23
The process for the Beginners USB Configuration guide is all contained on the first page, you follow the process not the whole thread.

Your UTBMap.kext looks a bit short of ports. It only activates 8 of a possible 15 ports.

Screenshot 2022-12-08 at 20.54.22.png Screenshot of Info.plist contents

Your motherboard has the following USB ports available.
  1. 1 x USB Type-C™ port with USB 3.1 Gen 1 support, available through the internal USB header
  2. 1 x USB Type-C™ port on the back panel, with USB 3.1 Gen 2 support
  3. 1 x USB 3.1 Gen 2 Type-A port (red) on the back panel
  4. 4 x USB 3.1 Gen 1 ports (2 ports on the back panel, 2 ports available through the internal USB header)
  5. 6 x USB 2.0/1.1 ports (4 ports on the back panel, 2 ports available through the internal USB header)
You are activating
3 x USB3 ports (HS01/02/03 & SS01/02/03)
2 x USB2 ports (HS04 & HS05)

Neither of the Type-C ports/headers nor the internal USB2 ports are being activated. Only 3 of 5 USB3 ports/headers are being activated.

So your USB configuration is activating 8 ports, when your motherboard contains a maximum of 20 ports. Wouldn't have thought this was ideal.
 
Step 1 on the first page of the Guide thread says to install USBInjectAll.kext. This kext hasn't been updated in 4 years, see their repo here https://github.com/RehabMan/OS-X-USB-Inject-All. Dortania says not to use that kext any more because it's no longer being maintained. Are they wrong?

Thank you very much for your analysis of the USB ports. 8 ports sounds about right in terms of what I can actually see on my PC's case. And all the ones I'm using are working okay.

So I'm not too bothered about the "missing" ones at this point. Unless they might be a possible cause of my menu slowness, do you think?
 
Status
Not open for further replies.
Back
Top