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 Mac OS 11.3 has broken support for older Mac Pros
- Thread starter VitaminK
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
- Status
I'm both disappointed and surprised that no one else seems to be getting any positive results from the "osenvironment" patch. There must be something about my system that makes it more effective here than elsewhere. I'm continuing to test (only two failures so far, both "manufactured" with unusually (for me) large drive/USB counts), and I'm continuing to look for additional startup items to patch.
Also, out of curiosity, which of the cMPs in your signature are you testing on?
(* x86_64 uses RIP-relative addressing, so it's trivial to relocate the entire binary intact (which is how kernel slide works), but inserting/deleting within the binary causes chaos. I guess it's more correct to say "fixed-relative" addresses, but you get the idea.)
I chose "prevent-restores" because despite that comment in the source, it is never referenced in either the source or binary code, and is therefore either an unnecessary holdover or it's somehow used for internal testing (or, conceivably, by a kext; I haven't exhaustively scanned the kexts for that reference). If that choice eventually proves to be problematic, we can try another element from the list (such as "one-time-boot-command", which also appears to be unused at present). For now, I'm more concerned with finding something that works; once we have that, we can try to find an ideal long-term injection point with minimal side-effects.
I'll check in here later today to see if any other results get posted. In the meantime, I'll be looking for additional startup tweaks we can try. Sorry if this one got anyone's hopes up; I did try to temper expectations in my original post (apparently with good reason ;-).
Hopefully, the change in where it hangs indicates that the patch is doing something on your system, and perhaps future additional startup patches will make a more positive difference. Maybe.
Also, out of curiosity, which of the cMPs in your signature are you testing on?
How does "1 out of 2,3 reboots" compare to what you saw before? Any change, or is it basically the same?
Binary patching, especially in x86_64, doesn't work that way. The memory map is set when the kernel is linked - all the jumps, calls, and data references have fixed* addresses, and inserting/deleting something would move things around in memory, causing things to break. The best you can do is either identify something superfluous or innocuous to overwrite (as I did in this case), or, in the case of code patches, you can sometimes effectively relocate the original code by overwriting it with a long jump and replicating the original code in some (allocated) memory that you control, adding your patches there (which is how MouSSE works).
(* x86_64 uses RIP-relative addressing, so it's trivial to relocate the entire binary intact (which is how kernel slide works), but inserting/deleting within the binary causes chaos. I guess it's more correct to say "fixed-relative" addresses, but you get the idea.)
I chose "prevent-restores" because despite that comment in the source, it is never referenced in either the source or binary code, and is therefore either an unnecessary holdover or it's somehow used for internal testing (or, conceivably, by a kext; I haven't exhaustively scanned the kexts for that reference). If that choice eventually proves to be problematic, we can try another element from the list (such as "one-time-boot-command", which also appears to be unused at present). For now, I'm more concerned with finding something that works; once we have that, we can try to find an ideal long-term injection point with minimal side-effects.
I'll check in here later today to see if any other results get posted. In the meantime, I'll be looking for additional startup tweaks we can try. Sorry if this one got anyone's hopes up; I did try to temper expectations in my original post (apparently with good reason ;-).
Yes, it definitely made a change. I used to get very random hangs (with a few being more common, just not sequentially), but now it seems that every hang was at initializing ethernet. I'm testing Macschrauber's suggestion of pulling USB devices. Being a test machine, the only USB device is an Apple keyboard, which does contain a USB2 hub. The only problem with that is I encrypted my 11.3.1 drive to test that theory, so need to type in my password after OpenCore, but before boot, so I have to be quick.
I was curious if the white text in my signature wasn't readable with a light theme. I use a dark theme and it looks like the screenshot below on my screen. I'm using the middle system (2x X5677's) for all of this testing, which has several HDD's & SSD's, one being on a PCIe card, with several versions of macOS (currently 11.3.1, 11.4RC, and 11.5b1). My primary system is running 11.2.3 only.
The only USB device I have connected on my test system is an Apple keyboard (which has a USB hub). I was getting about 50% success/fail with almost perfect success, fail, power off/on, success, fail, power off/on... (OXOXOX).
Since I have FileVault on my 11.3.1 drive, I need to plug the keyboard in when I get to the passcode screen, then immediately unplug it after hitting enter. It seemed at first like I was getting better results with 3x successful reboots, then a fail, power off/on, success, fail, done. (OOOXOX).
Did you pull the USB connector to the BlueTooth adapter? I haven't done that, and use an original Apple trackpad with it.
i have no Filevault but also Apple Keyboard and Cinema Display. So 2 Hubs. i pulled bluetooth, too. Its a usb device as well. I have all in chain so its one usb plug to pull.
btw I use my Apple Trackpad 2 wired On my other Mac Pros. Dont mind for this cable.
I can start via OpenCore with usb, select something in OC and pull usb. Then plug it in if it has booted half way thru.
but on my test machine I can now let all usb stuff in with the pikera boot-arg.
I know that it gives nothing to others. Its just one data point.
also know that pikera is active in MartinLo package.
Last edited:
Finally got to try to upgrade from 11.2.3 to 11.3.1. Here's my report:
Before Upgrade
Same result as most of you who tried to upgrade: the system eventually managed to finalize the OS upgrade, but the booting fails in unpredictable ways.
The next step would be to try adding the patch from @Syncretic. I will try it, but I need a bit of a break from this long (and painful) process so I won't try the patch today. Before I try, I would need some guidance on adding the patch to my config file. reminder I am using Martin's package. I assume the following are the steps to follow? Not sure about step 3.
Before Upgrade
- I kept the system configured as shown in my signature plus the following: 2.5" SSD on Bay 1 (Mojave), HDD in Bay 2 (Data), HDD in Bay 3 (Data), HDD in Bay 4 (High Sierra + Martin's OpenCore 0.6.8), HDD in Optical Bay (Data) and NO optical drive installed, 2 monitors via DP inputs, Apple wired keyboard and wired mouse to USB2.
- I had both wired Ethernet and WIFI internet connections.
- On my Dual NMVe PCIe Card in Slot 2: I cloned my 1st blade (my regular 11.2.3 boot drive) to the 2nd blade on the card. I did not remove the 1st blade with 11.2.3, I simply selected the 2nd blade as Startup Disk and then embarked on the upgrade process via System Preferences-Software Update.
- The upgrade process failed multiple times, alternating between 1) the progress bar frozen at about 1/4 and 2) the prohibition sign with link to apple support startup web page. I had to do 'forced power off/cold boot' multiple times as follows.
- After 6 forced power off/cold boots, I removed the Inateck USB 3.0 card from PCIe slot 3 and the Sonnet Fusion Raid card from PCIe slot 4. No improvement, I still got failures.
- After 2 additional forced power off/cold boots, I unplugged the Ethernet cable. This made a difference, the upgrade process resumed reaching a system initiated warm boot, yet it froze again after that.
- After 2 additional forced power off/cold boots, I removed the SSD/HDD drives from Bay 1-2-3 and Optical Bay, leaving only the HDD in Bay 4 with OpenCore. This made a difference, and the system successfully booted into 11.3.1
- I tested 11.3.1 , opened multiple apps, ran Geekbench 5, plugged encrypted USB drives, all worked normally, the system was stable.
- I did one warm boot back into 11.3.1 successfully. Then I tried several iterations of '1 cold boot+2 warm boots' but got very inconsistent results with failures happening randomly after either warm boot or cold boot.
- It seems that unplugging the USB keyboard/mouse during the boot process helps to reach the login screen, plugging them back at login works fine. But I could not replicate successfully.
Same result as most of you who tried to upgrade: the system eventually managed to finalize the OS upgrade, but the booting fails in unpredictable ways.
The next step would be to try adding the patch from @Syncretic. I will try it, but I need a bit of a break from this long (and painful) process so I won't try the patch today. Before I try, I would need some guidance on adding the patch to my config file. reminder I am using Martin's package. I assume the following are the steps to follow? Not sure about step 3.
- Copy/paste the patch with BBEdit
- Save the edited config file
- Re-bless via Martin's automator script?
- Kneel, pray, then reboot...
Last edited:
Replace step 3 with... Run this terminal command from /EFI/EFI/OC to test your config.plist, and reformat it as necessary. Syncretic says this patch is picky about spaces, and if you simply cut & paste, all indentations are done with spaces, not tabs. This should clean that up (check it before and after to see).
- Copy/paste the patch with BBEdit
- Save the edited config file
- Re-bless via Martin's automator script?
- Kneel, pray, then reboot...
Code:
plutil -convert xml1 config.plist && plutil config.plistPS - See my screenshot in this post for what it should look like. #872
I’m not sure if it helps, but running OC 0.68 with graphical boot picker hidden, when I hold Escape and choose “Big Sur” 11.3.1 housed on its own PCIe NVMe, the machine boots properly seemingly every time. I’ll have to keep an eye on this and confirm.
Edit: added OC version and hidden boot picker
Edit: added OC version and hidden boot picker
Last edited:
Are you hiding your boot picker in OC? Is it the same as selecting 11.3.1 in OC boot picker? Or what exactly does ESC do in the process?
Can you describe the circumstances in which it does not boot?
Well, then you shouldn't be using the light theme. Get with the program, man. Mojave was SO 2 OS's ago...
j/kFine... gray it is... should be visible in both light and dark themes now.
If I let the machine go through it’s normal boot routine (without touching anything on the keyboard), then it will start Big Sur, show the Apple and status bar, then stall at about 30% or so.
Contrary to "Alternative Facts" widely circulated on the web, Mojave is perfectly capable of being set to the horrid dark mode ... thankfully something connoisseurs can disable.
Indeed. Light Themers now know what your test and primary rigs are!
I had a similar experience tapping the EJECT Key but it could be my own crazyness. I'm going to try the ESCAPE key.
UPDATE: Holding the ESCAPE Key and continueously tapping the enter key worked great.
Last edited:
My 5,1 seems to be mostly OK with installing Big Sur 11.3.1 using OC 0.6.9 (and syncretic's unaltered config.plist) and then booting. One thing I learned the hard way was that I had to use a completely unaltered version of syncretic's config.plist file. My 5,1 crashed when I had altered the posted file for just legacy wifi and retina boot. I started with a SATA drive and moved on to an NVMe drive.
------------
Here's more detail on what I did
------------
Installed syncretic's config.plist file that had been posted to the facebook OpenCore on the Mac Pro group. I altered it for retina boot & legacy wifi support (oops...).
Booted to Big Sur 11.2.3. Then formatted a fresh SATA SSD and installed Big Sur 11.3.1
crashed on boot after install install finished.
verbose boot screen - last two lines
Intel82574L::start - Built Apr 22 2021 21:08:15 -- running on device at b9 d0 f0
Intel82574L::start - Built Apr 22 2021 21:08:15 -- running on device at b10 d0 f0
Then I booted from my 11.2.3 Big Sur drive. I updated the config.plist file so that it was EXACTLY the same as the syncretic config.plist file posted to the OpenCore on the Mac Pro group.
Then it booted OK!!
I was able to use CCCv6 to replicate to a disk image (used legacy bootable copy mode).
I then used CCCv6 to replicate from the 11.3.1 disk image to a Samsung 970pro NVMe drive. The first time I tried booting from the NVMe drive and it crashed on boot, but then I tried booting several more times from the NVMe and it booted OK each time other than the 1st try. Holy cow CCC v6 us so much faster than CCC v5!
2009 Mac Pro, 48Gb RAM, R9 280x video card, 3.33GHz 6-core single processor
For clarification, I built that config based on Martin's and applied Syncretic's kernel patch, and provided it for anyone who wanted to help test in the "OpenCore - on the Mac Pro" Facebook group.
Looks like we have another machine that hangs on the ethernet initialization with this patch applied.
If at first you don't succeed, try, try again. I've had installs take the first time with no issues, I've had most fail 1/2/3 times requiring a power cycle, and I've had the system drive become corrupted during install, 5x now actually. Twice I was able to recover by booting into recovery and performing a reinstall, but I've also had to wipe the system drive and start over.
- Status