zearp/Nucintosh

Question about startup speed difference between EFI versions.

naryfa opened this issue · 7 comments

naryfa commented

Hey,

I downloaded the most recent EFI 0.8.9 from your repo but noticed a substantial boot time difference from the 0.8.7 that I previously had. The old one just flies without ever stopping on any line, while 0.8.9 hangs several times for 3-10 seconds.

Do you experience this as well? I will attach my old sanitized EFI here (without serials, MLB, etc.), perhaps you could test and see how fast it boots for you?

My specs:
Ventura 13.1
i7-8359u NUC8i7BEH
Intel SATA SSD 520 series 480GB
32GB Kingston DDR4 2400
BCM 94360CS2 WiFi/BT.

EFI.zip

zearp commented

tl;dr coming up, also for others lurking around!

I have not experienced this on my NUCs but I do notice differences between versions of OpenCore and their kexts on all of my builds, this is normal but can be difficult to pin point exact causes because there are many moving parts, luckily not all parts change but it's some work to figure out causes. Also macOS updates can change things that might be fixed in newer versions of either OpenCore or kexts.

It is a bit tricky to save complete bootlog but you could record it with your phone and see where it stalls and if those same spots don't have stalls or simply don't scroll by on others. There are simply too many possible causes for me to do much. It could even be an edge case like a combination of a newer kext with your specific disk. The possibilities are really endless with so many moving parts. Excluding possibilities and logs are the best way.

You could find the differences between a version that causes the stalls and one that doesn't. That would already help me help you. Even better would be me being able to reproduce. I always ask for the steps to reproduce but in this case I just installed a clean install last night using the last release as I always do before publishing a release and didn't notice any boot staling. I'm using a Crucial NVMe in my test NUC.

The config itself hasn't really changed in a very long time. I just add new entries as they're added to OpenCore and all of them have been disabled by default. We don't need any of it for our buil so it's only added and then disabled so it passes the OpenCore sanity check tool with 0 errors.

There are plenty of other causes though, full bootlegs would help you best to pin point it down. IT could be doing more trimming or maybe the way it trims changes though OpenCore doesn't do that, that's all macOS. Once the kernel starts loading OpenCore doesn't do anything anymore.

ACPI patches and kexts are active thought but for sure ACPI patches have no changed at all. So then maybe it's a kext that could cause it as well. Perfectly possible. It will take some troubleshooting on your part to find out what exactly causes/fixes those delays you have. I don't have them on any of my NUCs but they're not all running the latest version. I have 1 test NUC I do clean installs on before a release and everything seemed fine to me using the release I posted yesterday.

I am working on making a new HP based hackintosh and have a consistent stall on every single boot. It is really weird as everything else works perfectly fine. I'll try some older versions of OpenCore and see if it helps or not. It could be some things related to APFS got changed the past versions or something else. There are many possibilities. It might even be related to what you experience.

What is the last line you see when booting verbose when its stalling? Mine stalls for about 30 seconds at "all done, ready to go home" or something like that. Then it just loads macOS and everything is fast and works fine. But every single boot it stalls. I can't figure it out so maybe it is related somehow to this.

Good luck and let me know if you get any information on this so we can make changes and hopefully fix it and prevent it.

If you don't want to help that's fine, no worries! Just use the EFI version that works best for you. They will all work fine with Ventura and its updates and likely also works on the next macOS version Apple will release later this year.

I am just keeping there EFI up to date but on my installs I rarely change OpenCore, if it works then it works and there's no need to change it. Treat it like a BIOS in a way, no need to update or change when you have no problems and the updates don't offer anything significant like better performance or new features. We're already getting the most out of this build. It would be cool if the OpenCore team or some kext dev could improve performance with something. But I doubt that'll happen at this point.

I consider this build and my Optiplex build to be pretty much complete. Other than TB3 hot plugging whichI can't test because I don't have enough TB3 devices to make it worth it for me. I have a few docks which work fine when connected at boot. I don't really need to hot plug anything and don't fancy spending more time that I already did on that. People have reported eGPU also works. All TB3 devices work as long as they're connected at boot and not hotpugged.

Long story shoer, I don't think I can do much for you as I don't experience it myself using the latest release on my stock test NUC with no modifications. I am interested in what kind of messages you see when its stalling as that would be the most helpful thing.

Depending on where in the boot process it happens you may already have it logged but it might happen too early for the system logs and too late for the OpenCore ones. OpenCore really just hands you off to macOS after loading ACPI patches and the config, once the macOS kernel loads OpenCore is done.

I'll close this but please keep me updated. I will also update here if I find downgrading OpenCore helps on my new build which has a similar issue. Fact remains you have a clear difference between 2 different versions, once we know the differences between them and have logs it shouldn't be difficult to find the cause. A solution might be harder but that all depends on the cause, of course.

naryfa commented

Man, you blew my mind with your response.

I did notice that HfsPlus.efi caused slower boots than OpenHfsPlus.efi. That's why I put OpenHfsPlus.efi into the new EFI.

It resonates with me, what you said about the possibility of a kext and an SSD drive hang somewhere in the code. Who knows?

I'll record old and new EFI boot sequences and try to post them here. These hangs aren't long, but they certainly add up to the whole. When you boot in 18 seconds and then in 1:05, you can feel it 😂

PS. I think I forgot that you ought to reset NVRAM on a new EFI, correct?

naryfa commented

OK, here we go. I posted them on YouTube.

0.8.7:
Link Removed.

0.8.9:
Link Removed.

I won't keep them there for long, but anyhow, take a look at how fast 0.8.7 flies.

naryfa commented

I've got an update on this.

On my old EFI the TRIM is disabled. I remember I did that and the whole startup procedure shortened. It irked me the previous time so I decided to sacrifice some of the SSD life for the boot speed.

But I do not know, whether that could be related to your HP build.

I do owe you a big credit for this build anyways. I've been lucky to have you help me so many times, for which I am grateful. This truly is a nearly perfect machine.

zearp commented

Trim is always a bit of a gamble. Some disks have no issues with it and are fine with or without. some need it or they become super slow and some don't need it because it lags them out when macSO tries to trim it.

If trim is fully disabled you have to keep an eye on the garbage collection though. You could trim it manually from time to time by running a disk check from the recovery partition. I think that trims the filesystem as well.

There is a setting in the config that always enabled trim:

https://github.com/zearp/Nucintosh/blob/master/EFI/OC/config.plist#L627-L628

You need to set that value to false that and maybe also manually disable it in macOS with sudo trimforce disable. Personally I always ruin into issues with trim disabled so that's why the ThirdPartyDrive is on by default. It enables trim no matter what.

I'm not sure what was in the videos, I wouldn't have the time to fully inspect and read all the logs to see whats stalling your boot. It is much h easier for you to do that and quickly test older/newer EFI version to see where it starts to lag. Once you know in which version it started I could help fix it much more easily.

It may be a good idea to search around on your drive model and/or drive controller chipset and see if there's any issues relating to macOS/trim/etc. It may also be good to check for firmware updates.

I actually had an ssd a few years ago that was super slow in macSO but fine in Linux. Happened to be some bug in the firmware that caused performance degradation when formatted with APFS. So yeah, there are always many possibilities to check and exclude as optional causes. It is part of the troubleshooting fun if you're into that kind of stuff.

Good luck and thanks for the feedback!

naryfa commented

I did sudo trimforce disable and yes, it does help. I'll TRIM manually every now and then. Found this somewhere:

...by booting to single user mode (reboot while holding command-s) and entering "fsck -fy"

zearp commented

Be careful using the y option as it just enters yes to whatever fsck wants to do. There could be other things wrong with the disk you may not want fsck to mess with but use the macOS disk util for instead. Not likely to happen but it is possible it finds some folder or file corruption and wants to delete it or something like that where you don't want to default to yes.

I think most modern ssd's do trimming in the controller/firmware so it should be ok unless there are some incompatibilities with macOS. On NVMe there isn't a trim option at all, it's all done on disk as far as I know.

I mainly use Samsung ssd's in my builds and enabling trim causes no problems but I think it could also be turned off. It's really up to the end user to decide and experiment with I guess.

It's always a bit of trial and error with 3rd party hardware in Macs. We depend on Apples drivers (kexts) to support it or have to make our own drivers.

Even in real Macs this is a thing. If you install a 3rd party ssd trim won't be automatically enabled. It is automatically enabled on Apple disks. I think they modify the firmware on their rebrands. You'd need a 3rd part tool to enable it and at some point Apple added the "trimforce" command. But fact remains some disks don't benefit from it, some do and some aren't affected by it at all.

Use what works best/fastest for you, just be sure your ssd and specially nvme has the latest firmware. T