The point is you don't need latebloom for 11.2.3. That is why it was set with this minimum Kernel version.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Latebloom - An experimental workaround for the 11.3+ race condition
- Thread starter Syncretic
- Start date
- Sort by reaction score
- Status
I do know that. I changed the minkernel so as to try an upgrade installation from 11.2.3
I think, you should not do this. Just try upgrading to 11.4. When macOS reboots, the new kernel and the kext will be loaded. 11.2.3 boots fine, but maybe the kext has implications with 11.2.3 and lower. Therefore the kernel version is set to `20.4.0` as protection.
After messing around with this for a few hours, I was able to successfully get it loaded. For the sake of simplicity, I've attached the original Martin LO OC config.plist with the following parameters:
This also includes the kext lines which are required and mentioned in post: https://forums.macrumors.com/thread...on.2303986/page-2?post=30090448#post-30090448
This modified config file is for OpenCore 0.7.1 provided by Martin LO here.
The only thing that someone would need to do (if they wish) is either replace their config.plist contents with that of mine or overwrite the config.plist entirely.
Code:
latebloom=100 lb_range=20 lb_debugThis also includes the kext lines which are required and mentioned in post: https://forums.macrumors.com/thread...on.2303986/page-2?post=30090448#post-30090448
This modified config file is for OpenCore 0.7.1 provided by Martin LO here.
The only thing that someone would need to do (if they wish) is either replace their config.plist contents with that of mine or overwrite the config.plist entirely.
@eVasilis, you need to really pay attention to the direction and the things that people here are helping you with.
I also think that if you are having issues, you should wait until there is a more complete solution or the testing has been flushed out a bit more.
Well, there were no adverse effects on 11.2.3 with latebloom loaded but the upgrade install did not work out. Trying a clean install as we speak.
Besides the fact that all that is beyond my area of expertise, I am paying attention. I wouldn’t have come that far if I didn’t.
Cheers
I understand. But you just said that this beyond your "area of expertise." I just think maybe you should give it some time and wait until this is flushed out a bit more.
Just had a chance to try this out and it works perfectly with latebloom=100 lb_range=20
The progress bar loading behavior has changed with this workaround enabled as the loading speeds up after slowly progressing between 1% and 3~5% which confirms latebloom is doing its magic!
Excellent work!
The progress bar loading behavior has changed with this workaround enabled as the loading speeds up after slowly progressing between 1% and 3~5% which confirms latebloom is doing its magic!
Excellent work!
Not exactly, as mentioned with this post a number of machines are affected however were reported in other forums/discords outside of the main 11.3 thread. This creates an unfortunate bias internally that only MacPro4,1/5,1 were affected when in reality many more machines including iMac7,1-iMac11,x as well as MacPro3,1 can experience these issues
@Syncretic ... Perhaps I am mis-interpreting the MinKernel setting but shouldn't the value actually be
MinKernel 20.2.4 (Mac OS 11.2.4 and above - in reality Mac OS 11.3.0 plus ... Can also be MinKernel 20.3.0 to be safer) as opposed to MinKernel 20.4.0 (Mac OS 11.4.0 and above) which actually excludes Mac OS 11.3?If I am correct, this might explain some of the odd results as LB is actually not injected for those testing 11.3.
(on mobile, can't verify right now) My recollection is that Darwin 20.3.x was MacOS 11.2.* and Darwin 20.4.0 appeared with MacOS 11.3. I'm fairly certain I checked that on my own 11.3 installation. (I am, as always, also prepared to be proven wrong.)
I think you might be right. I am currently on 11.4 and performing a uname -a reports,
Code:
20.5.0 Darwin Kernel Version 20.5.0:I would assume that 11.3 was 20.4.0.
Makes sense then. Just somehow worked on the basis of the "x" in Darwin x.y.z being essentially "VersionMacOS" + 9 with the rest being the same values but likely to be wrong as hazy about where that came from.
Last edited:
Just an update. It works now smoothly but I had to set the parameters to `latebloom=250 lb_range=0` (`lb_range=0` could be removed because it is the default). Without the parameters or with the default values, my Mac Pro hang after the installer finished and rebooted. I am now on macOS 11.4 
.
Many thanks to @Syncretic and all the other people here, for keeping the Cheese grater running more than 10 years, its so cool.
PS: For testing, i used Carbon Copy Cloner to create a bootable backup, which gets automatically listed in the OpenCore picker, just in case.
.Many thanks to @Syncretic and all the other people here, for keeping the Cheese grater running more than 10 years, its so cool.
PS: For testing, i used Carbon Copy Cloner to create a bootable backup, which gets automatically listed in the OpenCore picker, just in case.
Last edited:
I've just finished over 3 1/2 hours of experimenting and am no further on. My previous attempts using settings from 50-130ms all stalled at AMFIInitializedLocalSigningPublicKey. After reading later posts, I've tried from 150 and increasing by multiples of 10ms (eg. 160, 170. etc) up to 250, then 300, 350, 500 and other combinations in-between and, on my 5,1 system, I only get a successful boot through to the Monterey desktop on an almost random, non-repeatable, basis. One boot and kext load success - confirmed using the AppleScript posted by Macschrauber and running the Terminal checks (using a highish delay setting) stalls at AMFI on the next reboot every time.
I did find that moving the kext string to 2nd place after Lilu failed every time, whereas keeping it last offered a better chance of success - although, again, non-repeatable.
Each verbose boot screen (on the successful and unsuccessful boots) all did show 'Hook placed successfully. Count = 0', but this was always followed by:
Kext AAA.LoadEarly.latebloom did not start (return code 0x1)
Kext AAA.LoadEarly.latebloom start failed (result 0x1)
Kext AAA.LoadEarly.latebloom failed to load (0xdc000017)
Failed to load kext AAA.LoadEarly.latebloom (error (0xdc000017)
Is this correct / do other members see these error messages, even though the 'Hook' is successful?
I've attached images extracted from an iPhone video file, in order to capture the rolling messages. They're a bit fuzzy but I hope are sufficiently readable to maybe be useful to someone (NB. the images got uploaded in reverse order). I've disabled the latebloom kext and am back to reliable boots with just OCLP 0.2.3, which is a significant step forward for me in getting more mileage out of my cMP.
Attachments
Last edited:
Perhaps I'm just imagining things, but
- It seems that increasing the delay does not always increase reliability. For example, my success rate seems higher with 100 ms than with 200 ms.
- My success rate seems higher with
lb_debug=1even when not booting in verbose mode. Could debug messages have a positive effect on the timing?
That’s the classic programming conundrum - “it works with debugging output, but fails without it.” In this case, the additional output adds a few milliseconds for each output line, so yes - debug messages absolutely can have an effect (positive or negative) on the timing.
Have you tried
lb_debug=1? Do you then see a long list of latebloom PCI LOOP # lines?
Apple just released the RC for 11.5, only via software update at this moment, build 20G70:
Since 11.5 correct so many things, I'm installing and moving my tests to it.
Code:
Software Update found the following new or updated software:
* Label: macOS Big Sur 11.5-20G70
Title: macOS Big Sur 11.5, Version: 11.5, Size: 11239136K, Recommended: YES, Action: restart,Since 11.5 correct so many things, I'm installing and moving my tests to it.
Are you keeping the delay the same or will you change any of the parameters before installing?
- Status