MP 1,1-5,1 Latebloom - An experimental workaround for the 11.3+ race condition

[macrumorsnumpty]

I wish I knew coding and programming.
Is there a way of stopping the boot hardware checks entirely?
Just stop it looking under the bed for monsters and let it wake up in the morning all refreshed.

 

[kkinto]

Stepping down by 10 I revised my config to 150/20 & debug=1, -v still no problems doing cold boot (lb 0.17), warm boot still iffy but now and again successful (1 in 5). Think I will leave it here while you guys continue except for upgrading latebloom to 0.19. Keen to check out Monterey beta. Boot time increase even with verbose hardly even perceptible really! This is awesome, thank you again and good luck with further development.

Spoiler

----------------------
mid 2010 Mac Pro 5,1
BootROM v: 9144.0.7.1.0. (Martin 0.71 Config with factory Wifi/Bluetooth factory patch)
2 x 3.33 GHz X5680
4 x 16GB 1066
WiFi factory
Bluetooth factory
1 x factory DVD R
1 x WD WDS 1 TB SSD in CD 2 Bay. (OS Big Sur 11.2.3) APFS
Int Bay 1 - Samsung 840 EVO 512 SSD SATA (formatter Mojave) APFS
Int Bay 2 - Seagate TGB formatter unknown (HFS+)
Int Bay 3 - Seagate TGB formatter unknown (HFS+)
Int Bay 4 - WD Blue 4TB formatter OS Mojave (HFS+)
PCI 1 - Radeon RX580 Sapphire / Dell 27U18 / DisplayPort
PCI 2 - IOCrest (SI-PEX40129) Dual NVMe Controller with 2 x Samsung 970 EVO NVMe 1TB 1 of them formatted by Mojave and other (current 11.4) formatted by BS 11.2.3 APFS (one is OS newly installed, other APFS data only)
PCI 3 - Sonnet Allegro Pro USB3.1 Type C (USB3C-4PM-E) -- 4 port 1 x USB3 Hub (2 x Seagate 3TB), 4TB External WD, spare formatters unknown / old (all HFS+)
PCI 4 - Sonnet Allegro Pro USB3 Type A -- 4 port 1 x USB 3 Hub (2 x 2TB Seagate in each of 2 bays), formatters unknown (Yosemite era), connector to dell monitor USB3 port (all HFS+)
Apple wired keyboard aluminium - via extender -> Mac Pro built in
USB3 Portable 2TB Seagate via Dell monitor -> Mac Pro built in
Logitech wireless mouse M325 (Unifying interface)

Booting 11.4 install with external Apple Wired (plastic) because one on USB extender does not work for OC booting[/spoiler

 

[Martin Lauren]

My cMP 5,1 has been a very stubborn beast and, as posted twice before, I've had little repeatable success (with 0.17)...up until now!! I'm pleased to finally report that latebloom v.0.19, with OCLP 0.23, and installing and multiple rebooting of Monterey beta 3 is looking pretty stable and successful...so far. I've skipped over 11.3/4/5 for now (keeping 11.2.3 as my daily OS).

LB settings used: latebloom=220 lb_range=20 lb_debug=1
Other boot-args: keepsyms=1 debug=0x100 -lilubetaall -v amfi_get_out_of_my_way=1 -no_compat_check

My hardware is in my signature. I can edit/provide in a fuller list if required. The only things missing to make Monterey a future regular OS is internal BT 4.2, off an upgrade BCM943602CDP card, not working and neither are both Ethernet ports. With the latter, there appear to be a couple of incompatible lines of code in the IONetwork cache support files. Maybe someone will add a workaround to OCLP at some stage. In the meantime, I'm buying a cheap USB3 Gigabit Ethernet adapter to get back up to speed, and may add a USB BT dongle if I have to, for Airdrop etc, as well.

Thank you Syncretic and any other developers/testers!!

UPDATE: Well, wouldn't you know...my 2 Ethernet ports just started working [under 12.0b3], so I don't need the adapter I just bought :-( Maybe I just needed to reboot a few more times with latebloom doing its work. While I'm peeved about the wasted purchase, it's great that (just maybe) latebloom can force the hardware to start talking again, which in turn updates the various kext and plist strings needed to get the devices to be recognised, as they were pre-11.3.

Hi!

How you are able to get working Ethernet ports on Monterey?
What's the procedure?

Best!

 

[Macschrauber]

I put in an Apple USB Ethernet adapter.

also universal one worked, like that i tested what was in a USB 3 Hub.

someone reported he got Ethernet back with beta 3.

 

[PeterHolbrook]

At long last, success with a genuine Mac Pro 5,1.

User	Peter Holbrook
CPU	1× X5675 3.07 GHz
GPU	AMD Radeon HD 7970 3 GB
Wi-Fi/Bluetooth	BCM943602CDP
Boot ROM	144.0.0.0.0
PCe S1	GPU
PCe S2	Empty (nothing will fit, because of the height of the GPU)
PCe S3	Factory Firewire card
PCe S4	Gigabyte (flashed) Titan Ridge Thunderbolt 3.1card @ 40 Gb/s
SATA 1	4TB TOSHIBA HDWE140 Media, APFS, with BS 11.2.3
SATA 2	1TB WDC WD10EZEX-08WN4A0 Media, Hybrid GPT/MBR, with 64-bit Windows 10
SATA 3	4TB ST4000DM004-2CV104 Media, APFS, with experimental BS 11.4
SATA 4	Empty (see below)
OpenCore	0.7.1
Kexts	Lilu – WhateverGreen – AppleALC – SidecarFixup – latebloom
Latebloom delay	15
Latebloom range	5
Latebloom debug	1

I don't actually know how significant the above configuration may be to others, or how beneficial my settings might be to others. The most significant change, after A LOT of unsuccessful attempts, came as a result of a hunch this morning. I had tried to remove almost all "unneeded" hardware from my Mac, with one single exception: The hard drive in bay 4. It is a 1TB WDC WD10EZRZ-00Z5HB0 spinner with several partitions: 1) Snow Leopard (HFS+); 2) High Sierra (HFS+); 3) Catalina (APFS). So, after making sure the disk itself was OK, I simply removed it. Miracle of miracles: Big Sur 11.4 booted on the second, third and fourth attempts (all cold boots). Before booting a fifth time, I reinserted the offending disk in bay 4. The boot failed. I removed it again. Boot successful.

I have no idea whether my computer might now be one of those odd cases that were kind of "compatible" with 11.3+. In other words, I don't know if it might be able to boot with just OpenCore without latebloom. And, quite certainly, I don't know which parameters of latebloom may trigger a non-booting condition.

I wonder if my offending disk might be physically incompatible with BS 11.4 or, far more likely, there's something on its partition map that Big Sur doesn't like. I suppose I'll reformat it as HFS+ and simply install Mojave. Any comments?

 

[cdf]

I have no idea whether my computer might now be one of those odd cases that were kind of "compatible" with 11.3+. In other words, I don't know if it might be able to boot with just OpenCore without latebloom. And, quite certainly, I don't know which parameters of latebloom may trigger a non-booting condition.

These questions should be easy to answer with a bit of testing. Please let us know.

 

[paalb]

I wonder if my offending disk might be physically incompatible with BS 11.4 or, far more likely, there's something on its partition map that Big Sur doesn't like.

It would be interesting to know if Big Sur Disk Utility repair would fix it.

 

[borp99]

Hi!

How you are able to get working Ethernet ports on Monterey?
What's the procedure?

Best!

I did nothing special. Both ports were inactive under 12.0 beta 2, 0.17 latebloom and OCLP 0.2.3, quite apart from the fact that I couldn't get consecutive reboots to the desktop. Once I swapped over to 0.19 latebloom and installed Beta 3 (which went through to the setup screen unattended - no hard restarts / which I barely believed) with 220/+-20/1 settings, I didn't have Ethernet for about the first few reboots. Actually, these initial reboots started to hang at USB hub and speed negotiation verbose messages. However, after a few more reboots, the USB hold-ups stopped and, to my further utter surprise, I casually checked the Network preference pane and my Ethernet ports were working (even swapping immediately to the other port and automatically setting up the DHCP settings if I changed the cat-5 cable over).

So, lets hope that my experience isn't the odd one out. I just rebooted from 11.2.3 back into 12.0b3 to check that the Ethernet ports are still doing fine [they are], before writing this reply. The lady I just bought a USB 3 Ethernet adapter from has even offered to refund my purchase if I post it back to her. Win, win!

 

[PeterHolbrook]

It would be interesting to know if Big Sur Disk Utility repair would fix it.

Disk Utility didn’t detect anything wrong.

 

[Macschrauber]

Maybe just an idea: Big Sur / Monterey did not like none apfs partitions.

as I tried to install Monterey beta 3 it hung forever into searching disks. I removed my other disks (containing HFSplus and Linux file systems) it started to install.

just an idea…

 

[PeterHolbrook]

Maybe just an idea: Big Sur / Monteray did not like none apfs partitions.

as I tried to install Monterey beta 3 it hung forever into searching disks. I removed my other disks (containing HFSplus and Linux file systems) it started to install.

just an idea…

No, that doesn’t seem to apply to my case. Now the disk has three APFS containers: one with Mojave, a second one with Catalina and a third empty one. If I try to boot BS 11.4 with that disk in place, it will hang.

 

[startergo]

Disk Utility didn’t detect anything wrong.

You can try putting it in another slot. If the problem moves with the disk it is the disk.

 

[PeterHolbrook]

You can try putting it in another slot. If the problem moves with the disk it is the disk.

To me, it’s clear it was the structure of the disk. After formatting it with one single APFS container with no data, the BS 11.4 boots just fine. I’ll install Mojave to that pristine APFS container.

 

[tsialex]

To me, it’s clear it was the structure of the disk. After formatting it with one single APFS container with no data, the BS 11.4 boots just fine. I’ll install Mojave to that pristine APFS container.

Use separate disks for Mojave and Big Sur. Doing the way you want is sure way to data corruption in the long run. APFS evolved a lot since Mojave.

 

[PeterHolbrook]

Use separate disks for Mojave and Big Sur. Doing the way you want is sure way to data corruption in the long run. APFS evolved a lot since Mojave.

Yes, of course. Already done.

 

[joevt]

Use separate disks for Mojave and Big Sur. Doing the way you want is sure way to data corruption in the long run. APFS evolved a lot since Mojave.

What about separate partitions (different APFS containers on the same disk) for Mojave and Big Sur?

 

[PeterHolbrook]

What about separate partitions (different APFS containers on the same disk) for Mojave and Big Sur?

That didn’t work for me with the latebloom parameters specified above.

 

[PeterHolbrook]

These questions should be easy to answer with a bit of testing. Please let us know.

As far as I can tell for now, it appears my Mac Pro 5,1 is now capable of booting Big Sur 11.4 (at the very least, through OpenCore) without resorting to latebloom. In my case, the entire cause of the 11.3+ incompatibility seems to have been the presence of multiple partitions and/or containers (HFS+, HFS+ and APFS, or three APFS containers) on one single disk. Once I got rid of such complex partition maps, Big Sur has no boot issues. Right now, my only non-APFS disk is a hybrid (GPT/MBR) Windows disk, and, fortunately, that is no problem for the latest versions of Big Sur. In the next few weeks, I'll probably convert my legacy installation of Windows to UEFI.

EDIT: Please, notice that the detected incompatibility of "complex" partition maps with the latest releases of Big Sur and Monterey might be exclusively related to OLD partitions. In other words, if I were to emulate a "complex" partitioning map using the BS 11.4+ Disk Utility, chances are that would work just fine. My hunch is that the issue is caused by complex partitioning maps that were created or modified by old versions of Disk Utility, such as those in High Sierra or Mojave.

EDIT2: See important caveat below!

 

[JedNZ]

Just pondering on what the problem might be with this race condition thingy, and not knowing anything about the intricacies of APFS, but has APFS changed in some way from/with Mojave, Catalina, Big Sur and now Monterey so that the support for APFS formatted drives in our 144.0.0.0.0 firmware is no longer up to date and compatible with the newest version of APFS?

When running Mojave I get this message after every restart because I have Catalina and Big Sur installed on other drives and I'm guessing Mojave's version of APFS isn't able to read/understand the later versions of APFS (Container Groups etc).

 

[PeterHolbrook]

@JedNZ: Yes, I noticed that yesterday too, for the first time. I removed Mojave in favour of Catalina two years ago. Now that I have Mojave again, that problem has come to the forefront.

 

[tsialex]

What about separate partitions (different APFS containers on the same disk) for Mojave and Big Sur?

My personal opinion is that one of the things that should work in theory but in the end performs poorly in practice. I had data corruption several times doing it.

Just pondering on what the problem might be with this race condition thingy, and not knowing anything about the intricacies of APFS, but has APFS changed in some way from/with Mojave, Catalina, Big Sur and now Monterey so that the support for APFS formatted drives in our 144.0.0.0.0 firmware is no longer up to date and compatible with the newest version of APFS?

View attachment 1807832

MacPro5,1 BootROM don't have the APFS EFI module itself, but a module that configure and loads it from the disk, APFSJumpStart. So, Apple can continuously improve the APFS code without the need to issue a new BootROM.

EFI Jumpstart
A partition formatted using the Apple File System contains an embedded EFI driver thatʼs used to boot a machine from that partition.
Booting from an Apple File System Partition
You can locate the EFI driver by reading a few data structures, starting at a known physical address on disk. You donʼt need any support for reading or mounting Apple File System to locate the EFI driver. This design intentionally simplifies the steps needed to boot, which means the code needed to boot a piece of hardware or virtualization software can likewise be simpler. To boot using the embedded EFI driver, do the following:

1. Read physical block zero from the partition. This block contains a copy of the container superblock, which is an instance of nx_superblock_t.
2. Read the nx_o field of the superblock, which is an instance of obj_phys_t. Then read the o_cksum field of the nx_o field of the superblock, which contains the Fletcher 64 checksum of the object. Verify that the checksum is correct.
3. Readthenx_magicfieldofthesuperblock.VerifythatthefieldʼsvalueisNX_MAGIC(thefour-charactercode 'BSXN').
4. Read the nx_efi_jumpstart field of the superblock. This field contains the physical block address (also referred to as the physical object identifier) for the EFI jumpstart information, which is an instance of nx_efi_jumpstart_t.
5. Read the nej_magic field of the EFI jumpstart information. Verify that the fieldʼs value is NX_EFI_JUMP START_MAGIC (the four-character code 'RDSJ').
6. Read the nej_o field of the EFI jumpstart information, which is an instance of obj_phys_t. Then read the o_cksum field of the nej_o field of the jumpstart information, which contains the Fletcher 64 checksum of the object. Verify that the checksum is correct.
7. Read the nej_version field of the EFI jumpstart information. This field contains the EFI jumpstart version number. Verify that the fieldʼs value is NX_EFI_JUMPSTART_VERSION (the number one).
8. Read the nej_efi_file_len field of the jumpstart information. This field contains the length, in bytes, of the embedded EFI driver. Allocate a contiguous block of memory of at least that size, which youʼll later use to store the EFI driver.
9. Read the nej_num_extents field of the jumpstart information, and then read that number of prange_t records from the nej_rec_extents field.
10. ReadeachextentoftheEFIdriverintomemory,contiguously,intheordertheyʼrelisted.
11. LoadtheEFIdriverandstartexecutingit.

https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf

 

[Dayo]

I'm guessing Mojave's version of APFS isn't able to read/understand the later versions of APFS

As explained, the APFS driver is not baked into the firmware and APFSJumpStart is used to load the required driver.

You can provide APFS support when absent in the firmware by activating APFSJumpStart in OpenCore (EnableJumpstart) or in RefindPlus (supply_apfs) or by loading the APFSJumpStart.efi driver as Clover does.

This will load the relevant APFS driver for the Mac OS version being booted, in your case, that for Mojave, which along with that in HiSierra, are Gen 1 implementations.

These Gen 1 APFS were transitional and were basically just HFS+ with largely cosmetic changes. This is why both HiSierra and Mojave support both HFS+ and APFS (Mojave has an artificially imposed APFS limitation).

"Real" APFS (Gen 2) came with Catalina ("System" was split from "Data") while Big Sur (Gen 3) added system encryption and a requirement to use the PreBoot volume unless SIP is disabled. I expect PreBoot to soon be always required (not sure if already so in Monterey).

Anyway, the pseudo APFS in Mojave, essentially just HFS+ with containers, can't understand the format as from Catalina. Hence the message.

PS: It had always been the case that newer APFS drivers could understand and work with the older versions but might well be that this backward compatibility was broken in 11.3+.

Wonder whether a launch daemon to unmount older Mac OS when booting into 11.x plus might help.

 

[PeterHolbrook]

One important caveat about the BS 11.3+ compatibility of my spinners

As I said before, I don't actually need latebloom in order to boot BS 11.4 off a 5400 rpm spinner, where I had reinstalled 11.4 a few days before using latebloom (300/20/1). I've just wasted three hours trying to update my 11.2.3 to 11.4 (on a 7200 rpm spinner) both without and with latebloom (same settings). After about one dozen tries, I've given up. Perhaps something like 100/20/1 or 60/20/1 would work in this setting. Further tests are required. I suppose I can boot my experimental BS 11.4 and migrate my whole 11.2.3 thereto. Then, perhaps I could use the faster spinner as the target for a CCC operation and see if that boots up.

 

[blckdvc]

upgrade successful from 11.2.3 (Mac Pro 4.1 > 5.1) latebloom value = 100

Front USB ports allows charging but no OS communication. Any idea on how to restore the two front USB ports ?

Thank you very much for this work ! Impressive !

 

[eVasilis]

You can provide APFS support when absent in the firmware by activating APFSJumpStart in OpenCore (EnableJumpstart) or in RefindPlus (supply_apfs) or by loading the APFSJumpStart.efi driver as Clover does.

What will happen on a 5,1 if APFSJumpStart is enabled in the config.plist? From what I see it is disabled by default. I remember in the other thread (11.3 broken...) that the problems with 11.4 and later could also be attributed to the apfs driver. Will enabling it in OC make any difference?

Thanks!