Missing internal drives and extremely long boot times after Monterey upgrade - HELP

[dmcnaugh15]

After upgrading to Monterey, I'm having a couple problems, as follows:

 

1. Boot times are extremely long.  After selecting the appropriate drive from the boot picker, it takes over 4 minutes to load to the mac screen (versus 16 seconds on Big Sur).  That's using the exact same EFI folder with OC 0.7.5 on the same computer.
2. Internal hard drives are all missing (see screenshots).  Just as for number 1 (above), I'm using the exact same EFI folder as I'm using for Big Sur, on the same computer.  Drives are visible for Big Sur, but not Monterey.

 

I've included debugging logs, my EFI folder, and config file.

 

Monterey screenshot (no drives):

Big Sur screenshot (drives present):

EFI Folder and debug log: http://DAMDAS.myqnapcloud.com:8082/share.cgi?ssid=cebeef9f960240328f7db0f5196af5c1

config file:

config.plist

Edited November 4, 2021 by dmcnaugh15
Cleanup original post

[le0nardwashingt0n]

I'm having very similar issues.

[dmcnaugh15]

What’s you’re build?  Curious if there are any similarities.

[le0nardwashingt0n]

Our systems look fairly similar we both have asus z390 chipsets, i9-9900k chips, and discrete AMD gpus. My build is in my signature. I am on OpenCore 0.7.5 that's fairly vanilla. It was working almost perfectly in Big Sur and now all the drives are gone. I can't even put a USB drive in and have disk utility recognize it. I have an appleraid that I can see in disk utility, but it's saying it's not initialized and i can't mount it.

 

I tried disabling SIP but that didn't work. I might try a different method because I read somewhere disabling SIP in Monterey isn't working as smoothly.

[dmcnaugh15]

My apology for not seeing your signature.  I was browsing the message on my iPhone, and it wasn't readily apparent there.

 

I was able to disable SIP by logging into my backup Big Sur system and then modifying the Monterey config file.  Problem persists with SIP disabled.

 

Here are some other things I've tried:

1. Rebuilding config file from scratch.
2. Switching out my SSDTTime generate ACPI files for Dortania prebuilt files.
3. Updating all kexts to their most current versions.
4. Getting a new serial number via GenSMBIOS.

Let me know if you think of any other ideas, or if something works for you.  I'll keep playing around too.

 

 

[saCULar]

I have a Gigabyte Z390 with and i9 also have a very slow boot. There is some conjecture that it is the Samsung EVO 970 ssd that might be causing the slow boot.

 

 

[Taruga]

6 hours ago, saCULar said:

I have a Gigabyte Z390 with and i9 also have a very slow boot. There is some conjecture that it is the Samsung EVO 970 ssd that might be causing the slow boot.

I have different hardware, but same 970 EVO. Boot process took 4m11s after updating to Monterey. Then  I've made a clean install and restored my data from time machine and the boot now takes around 28s which is a huge difference.

Not sure if it will stay like this or not. Maybe there is some incompatibility of trim with the local time machine snapshots or something else, lets see if from now forward the boot time stays short or if it keeps increasing the delay.

I have another PC with same hardware but with a SATA SSD instead of the 970 EVO that it's normal. 

My nephew also has a big boot delay with a 970 EVO PLUS

[Cyberdevs]

Have you tried using NVMeFix.kext maybe it fixes the slow boot time.

[dmcnaugh15]

Taruga:  My system boot drive is a Samsung SSD 860 Evo 1TB.  But, I also have the same problems when attempting a vanilla install from a SanDisk USB drive.

 

Cyberdevs:  Tried NVMeFix.kext.  No dice.  Thanks for the suggestion though.

Edited November 5, 2021 by dmcnaugh15

[Cyberdevs]

you can always boot in verbose mode and see where it stalls.

[Guest 5T33Z0]

@dmcnaugh15 Do you have trim enabled via csrutil?

 

Because if I enable trim via sudo crutil trimforce enable and then switch to a different SSD (which I found out about that it does work well with trim), then boot times are extremely slow. If I then disable trim again, it starts fast again.

 

Edited November 5, 2021 by 5T33Z0

[le0nardwashingt0n]

14 hours ago, dmcnaugh15 said:

My apology for not seeing your signature.  I was browsing the message on my iPhone, and it wasn't readily apparent there.

 

I was able to disable SIP by logging into my backup Big Sur system and then modifying the Monterey config file.  Problem persists with SIP disabled.

 

Here are some other things I've tried:

1. Rebuilding config file from scratch.
2. Switching out my SSDTTime generate ACPI files for Dortania prebuilt files.
3. Updating all kexts to their most current versions.
4. Getting a new serial number via GenSMBIOS.

Let me know if you think of any other ideas, or if something works for you.  I'll keep playing around too.

 

 

I'll try some more stuff this weekend and let you know. My main concern is the missing drives, I will work on the slow boot once I have access to my drives again. I'm nervous about playing around with the EFI folder on my boot drive in case I mess something up. I do seem to be able to boot from USB but once I've booted into macOS I can't access that USB drive. I can't say for certain but it looks like to me that macOS sees the other drives (and may even be assigning them drive numbers) but is ignoring them and only acknowledging the ones that are APFS.

 

About the slow boot, mine machine seems to be stalling on IOUSBHOST. My plan is to fix the drive thing, address bluetooth, and see where that leaves me with regard to my boot times. I have a samsung 970 nvme ssd as my mac boot drive.

[Taruga]

3 hours ago, Cyberdevs said:

you can always boot in verbose mode and see where it stalls.

Verbose mode doesn't give a clear picture of what is going on,  I used this command to check trims duration:

log show --predicate "processID == 0" | grep spaceman

Look for your SSD disk id and you should see something like this:

 

 kernel: (apfs) spaceman_scan_free_blocks:3153: disk10 scan took 66.606504 s, trims took 66.510656 s

And 2 or 3 days after my clean install and the boot delay is increasing (as I sort of expected), trims for the EVO took 66 seconds.  
The sistem was booting in 28 seconds 2 or 3 days ago, and at the moment I have a 66 second boot delay
Soon I'll be with the same 250 seconds (or more) boot delay.

[Guest 5T33Z0]

20 minutes ago, Taruga said:

Verbose mode doesn't give a clear picture of what is going on,  I used this command to check trims duration:

log show --predicate "processID == 0" | grep spaceman

Look for your SSD disk id and you should see something like this:

 

 kernel: (apfs) spaceman_scan_free_blocks:3153: disk10 scan took 66.606504 s, trims took 66.510656 s

And 2 or 3 days after my clean install and the boot delay is increasing (as I sort of expected), trims for the EVO took 66 seconds.  
The sistem was booting in 28 seconds 2 or 3 days ago, and at the moment I have a 66 second boot delay
Soon I'll be with the same 250 seconds (or more) boot delay.

 

Just out of interest, I enabled trim, restarted and then tried your command. I had no output in terminal. Do I have to modify it or change something inside the OpenCore config?

[Taruga]

1 hour ago, 5T33Z0 said:

Just out of interest, I enabled trim, restarted and then tried your command. 

 I had no output in terminal

You have to wait a little, it takes some time to display the ouput, around 11 seconds on my pc. Not sure if something needs to be changed on opencore config.

Output example:

Edited November 5, 2021 by Taruga

[Guest 5T33Z0]

Hmmm, it works on my desktop. On my laptop the screen was just blank for a whiile then the cursor returned to normal.

 

Does it perform an actual trim or does it simulate it?

 

Edited November 5, 2021 by 5T33Z0

[dmcnaugh15]

This is first I've heard of the trimforce operation.  My boot drive is a Crucial SSD, but I do have some Samsung SSD 860 Evo drives connected to the same computer.   So, I did give it a try, by typing the following into terminal:

• sudo trimforce disable
• Enter

I did not notice a difference in my boot time. 

 

Not sure if I did it correctly.

[le0nardwashingt0n]

5 hours ago, le0nardwashingt0n said:

I'll try some more stuff this weekend and let you know. My main concern is the missing drives, I will work on the slow boot once I have access to my drives again. I'm nervous about playing around with the EFI folder on my boot drive in case I mess something up. I do seem to be able to boot from USB but once I've booted into macOS I can't access that USB drive. I can't say for certain but it looks like to me that macOS sees the other drives (and may even be assigning them drive numbers) but is ignoring them and only acknowledging the ones that are APFS.

 

About the slow boot, mine machine seems to be stalling on IOUSBHOST. My plan is to fix the drive thing, address bluetooth, and see where that leaves me with regard to my boot times. I have a samsung 970 nvme ssd as my mac boot drive.

Adding a little more info. For me these drives do show up in the System Information application under the SATA and USB categories, so there is some recognition of them. It just seems like Monterey is ignoring them.

[dmcnaugh15]

 

le0nardwashingt0:  I can confirm the same behavior on my system (see screenshot).  And, I agree with you, the missing drives problem bothers me more than the long boot times, although both suck.

 

 

Edited November 5, 2021 by dmcnaugh15

[Benjamin Franklin]

5 hours ago, Taruga said:

You have to wait a little, it takes some time to display the ouput, around 11 seconds on my pc. Not sure if something needs to be changed on opencore config.

Output example:

 

Here's mine:

It sucks waiting so long. Total boot took three minutes!

It's a Samsung 970 EVO.

 

 

[le0nardwashingt0n]

Try this: 

 

Edited November 6, 2021 by le0nardwashingt0n

[dmcnaugh15]

le0nardwashingt0:  Just went to your reddit post and saw the tip to disable IntelBluetoothInjector.kext.  That fixed the problem for me too.  Actually, if fixed both problems.  Everything boots quickly and drives show up normally. 

 

I'll submit that on the acidanthera bugtracker, if no one else has.

[dmcnaugh15]

Submitted to bugtracker:

 

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

[dmcnaugh15]

Evidently, the intelbluetooth firmware is a different project.  Had to post there: https://github.com/OpenIntelWireless/IntelBluetoothFirmware/issues/358

[dmcnaugh15]

The OpenIntelWireless github team responded and said the problem was a "user mistake", and recommended reading the documentation.  I've attached it.

 

 

https://openintelwireless.github.io/IntelBluetoothFirmware/FAQ.html