MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[Bmju]

FYI Toggle SIP feature added to OC.

Btw, the aim is not to make it easy for people to turn SIP off, but to make it easier for people to have SIP enabled most of the time (as you should!), by making it less painfully slow to turn it off and on again on the rare times when you do need to (i.e. no need to go all the way into Recovery to change it).

 

[khronokernel]

Apologies if this is a common question, though have others noticed their MacPro3,1's NICs performing awfully slow for a Gigabit controller in Big Sur? Intel 80003ES2LAN(8086:1096) for reference.

Running a speedtest on my Gigabit network, I found that I max out around 220mbps and 20MB/s(160mbps) local between machines:

Ironically I actually get faster speeds off my BCM94360CD(about 300mbps) so extremely confused since it's on an x1 PCIe link. Even if the Ethernet controller is on an x1 PCIe 1.1 link, it should get 2000mbps (250MB/s) link no?

Would at least understand the technical limitation even if it can't be alleviated without a newer NIC. Also verified macOS, the cables and router, all report 1gbps link.

 

[joevt]

Apologies if this is a common question, though have others noticed their MacPro3,1's NICs performing awfully slow for a Gigabit controller in Big Sur? Intel 80003ES2LAN(8086:1096) for reference.

Running a speedtest on my Gigabit network, I found that I max out around 220mbps and 20MB/s(160mbps) local between machines:

View attachment 1783176View attachment 1783182

Ironically I actually get faster speeds off my BCM94360CD(about 300mbps) so extremely confused since it's on an x1 PCIe link. Even if the Ethernet controller is on an x1 PCIe 1.1 link, it should get 2000mbps (250MB/s) link no?

Would at least understand the technical limitation even if it can't be alleviated without a newer NIC. Also verified macOS, the cables and router, all report 1gbps link.

From my MacPro3,1 running Catalina 10.15.7 connected to a Mac mini 2018 running Big Sur, using SMB (file sharing), AmorphousDiskMark gets read/write MB/s : 114/59. That's 908/474 Mbps.

Gigabit means 1000 Mbps so 908 is pretty good (considering Ethernet and SMB overhead).

 

[khronokernel]

From my MacPro3,1 running Catalina 10.15.7 connected to a Mac mini 2018 running Big Sur, using SMB (file sharing), AmorphousDiskMark gets read/write MB/s : 114/59. That's 908/474 Mbps.

Gigabit means 1000 Mbps so 908 is pretty good (considering Ethernet and SMB overhead).

Thanks for the data point! So issue is on my end somewhere, will keep digging

 

[joevt]

Thanks for the data point! So issue is on my end somewhere, will keep digging

Try an AmorphousDiskMark benchmark for comparison? I have it set to 4 tries, 1 GiB, SEQ1M QD8.

 

[Angelus]

I haven’t read this thread fully for a few weeks so apologies if already covered.

I’m currently on Big Sur 11.2.3 and watching the “Broken on Mac Pro” thread for updates.

If I decide to go back to Catalina for ongoing security updates, what’s the best way forward to install Catalina?

My drives are setup as per the Wiki (OC and Big Sur on a single SSD). Do I just wipe the entire drive and start from scratch or is there a way to wipe the OS only and just install Catalina again?

 

[tsialex]

I haven’t read this thread fully for a few weeks so apologies if already covered.

I’m currently on Big Sur 11.2.3 and watching the “Broken on Mac Pro” thread for updates.

If I decide to go back to Catalina for ongoing security updates, what’s the best way forward to install Catalina?

My drives are setup as per the Wiki (OC and Big Sur on a single SSD). Do I just wipe the entire drive and start from scratch or is there a way to wipe the OS only and just install Catalina again?

The best way to do it is to fully wipe the disk, what we call nuke it. Boot Catalina installer, unmount all the mounted containers, recreate the partition table for the real disk and finally do a clean install.

• boot Catalina createinstallmedia using OpenCore
• open Terminal
• run diskutil list to see the list of disks, your real disk and the container will be on the start of the list.
• usually the real disk have a inferior number then the container disk,
  now you have to unmount the container disk, unmount the container diskutil unmount diskXX, remember to change diskXX to the real device.
• format the real disk with diskutil erasedisk jhfs+ Macintosh\ HD GPT diskXX remember to change diskXX to the real device.

Yes, use JHFS+, macOS install will convert it to APFS when the installer reboots automatically. No need to manually do/create anything else unless you have specific needs.

 

[Bmju]

I was just wondering, what is the reason for the recommendation to use plutil -convert xml1 config.plist && plutil config.plist to validate config.plist on p.1? Why not the OC ocvalidate tool?

 

[IceHouse]

Use this setting for SIP:

<key>csr-active-config</key>
                <data>fwgAAA==</data>

nvram csr-active-config
csr-active-config    %7f%08%00%00

Thank's for the hint but that option is allready incl. in Martin Lo's OC package.

 

[Bmju]

Thank's for the hint but that option is already incl. in Martin Lo's OC package.

You're on Catalina, if you want csrutil not to report "unknown (Custom Configuration)", then you need to use 0x77 instead of 0x7F.

If you need that higher bit set as well, the most direct equivalent would be 0x877 (aka w%08%0%00, or dwgAAA==).

Note that the latest OC build, to be released in 0.7.0 includes tools to allow you to much more easily toggle SIP to between enabled and disabled when you need to - as it really should be discouraged to run with SIP disabled all the time (you are just removing useful OS protection, for the very occasional time when you actually need to do something which SIP disallows).

 

[SarenSabertooth]

Apologies if this is a common question, though have others noticed their MacPro3,1's NICs performing awfully slow for a Gigabit controller in Big Sur? Intel 80003ES2LAN(8086:1096) for reference.

Running a speedtest on my Gigabit network, I found that I max out around 220mbps and 20MB/s(160mbps) local between machines:

View attachment 1783176View attachment 1783182

Ironically I actually get faster speeds off my BCM94360CD(about 300mbps) so extremely confused since it's on an x1 PCIe link. Even if the Ethernet controller is on an x1 PCIe 1.1 link, it should get 2000mbps (250MB/s) link no?

Would at least understand the technical limitation even if it can't be alleviated without a newer NIC. Also verified macOS, the cables and router, all report 1gbps link.

Had a similar issue, funnily also around 200mbps which was pretty low for fibre optics.
I had to change my ethernet hardware settings under network to duplex: full duplex, speed: 1000T
That did the trick for me. I'm no expert, but maybe try and tinker with the settings.

 

[cdf]

I was just wondering, what is the reason for the recommendation to use plutil -convert xml1 config.plist && plutil config.plist to validate config.plist on p.1? Why not the OC ocvalidate tool?

Actually both are used in the guide: plutil is used to verify the config and ocvalidate is used to validate it. The first procedure consists of reformatting the config with proper spacing and indentation (which ocvalidate does not do) and checking its integrity. This procedure is sufficient for the closely guided edits in the guide. The second procedure is for checking that the config is up to spec. This procedure is used when updating OC (see part 3 of the guide), which is much less closely guided.

 

[startergo]

You're on Catalina, if you want csrutil not to report "unknown (Custom Configuration)", then you need to use 0x77 instead of 0x7F.

If you need that higher bit set as well, the most direct equivalent would be 0x877 (aka w%08%0%00, or dwgAAA==).

Note that the latest OC build, to be released in 0.7.0 includes tools to allow you to much more easily toggle SIP to between enabled and disabled when you need to - as it really should be discouraged to run with SIP disabled all the time (you are just removing useful OS protection, for the very occasional time when you actually need to do something which SIP disallows).

I just tested SIP function. This is what I get when I disable SIP:

nvram csr-active-config
csr-active-config    o%00%00%00
bwAAAA==
0x0000006F
1101111

Makes no sense. Perhaps the function of this is to enable SIP rather than disable.

 

[Bmju]

I just tested SIP function. This is what I get when I disable SIP:

nvram csr-active-config
csr-active-config    o%00%00%00
bwAAAA==
0x0000006F
1101111

Makes no sense. Perhaps the function of this is to enable SIP rather than disable.

It's meant to be 0x6F. There's some debate about whether the 'correct' value is 0x6F or 0x7F. The 0x10 difference between them is an 'Apple Internal' bit (if anyone can point to a functional difference - anything macOS actually does differently, based on this bit, that would be helpful). If you prefer the 0x7F value you can just set up CsrUtil.efi as a tool, with args toggle 0x7F.

I'm not sure if you're confused by the print of o%00%00%00, but that's just how Apple prints 0x0000006F (the true UINT32 value).

And obviously, as you can confirm for yourself with Apple's tool, setting the bits in csr-active-config is what _disables_ SIP. (Each bit set disables some aspect of security.) All zero, completely missing (or, in fact, 0x10) reports as enabled.

So I don't think there's any issue?

 

[Bmju]

Btw @startergo, I should have also said, but rather than just looking at the nvram value, try typing `csrutil status` (works fine in non-Recovery boot), and see what Apple thinks your SIP status is with 0x6F!

 

[Bmju]

Also `Toggle SIP (Disabled)` does not mean 'disable SIP', it means that SIP _is_ disabled. Is that the confusion? I argued for just 'SIP: Disabled' in fact - but was overruled!

 

[startergo]

Btw @startergo, I should have also said, but rather than just looking at the nvram value, try typing `csrutil status` (works fine in non-Recovery boot), and see what Apple thinks your SIP status is with 0x6F!

I just tested in BS 6F reports disabled.

 

[startergo]

Also `Toggle SIP (Disabled)` does not mean 'disable SIP', it means that SIP _is_ disabled. Is that the confusion? I argued for just 'SIP: Disabled' in fact - but was overruled!

This off course does not disable authenticated-root. Both default+authenticated-root is 87F

 

[Bmju]

This off course does not disable authenticated-root. Both default+authenticated-root is 87F

It does what Apple's csrutil disable does. If you want non-standard values just set up CsrUtil.efi as a tool, to toggle whatever value you need.

 

[Angelus]

The best way to do it is to fully wipe the disk, what we call nuke it. Boot Catalina installer, unmount all the mounted containers, recreate the partition table for the real disk and finally do a clean install.

• boot Catalina createinstallmedia using OpenCore
• open Terminal
• run diskutil list to see the list of disks, your real disk and the container will be on the start of the list.
• usually the real disk have a inferior number then the container disk,
  now you have to unmount the container disk, unmount the container diskutil unmount diskXX, remember to change diskXX to the real device.
• format the real disk with diskutil erasedisk jhfs+ Macintosh\ HD GPT diskXX remember to change diskXX to the real device.

Yes, use JHFS+, macOS install will convert it to APFS when the installer reboots automatically. No need to manually do/create anything else unless you have specific needs.

Thanks tsialex.

As I mentioned in my previous post, this disk for me as per the guide contains Big Sur (plus OC in the EFI.)

Even though I booted the Catalina installer using Opencore, am I correct in believing that this action will wipe the disk including the EFI containing Opencore?

If so, by clean install do you mean I will need to start afresh in the Opencore guide?

 

[tsialex]

Thanks tsialex.

As I mentioned in my previous post, this disk for me as per the guide contains Big Sur (plus OC in the EFI.)

Even though I booted the Catalina installer using Opencore, am I correct in believing that this action will wipe the disk including the EFI containing Opencore?

If so, by clean install do you mean I will need to start afresh in the Opencore guide?

Yes, move the OC config to a different disk or an USB key, then nuke the disk you want to downgrade from BigSur and follow the steps on the guide for a clean install of Catalina.

 

[TECK]

Why not the OC ocvalidate tool?

You need to use both, plutil will check and fix your formatting, ocvalidate will validate if your config content (keys/values) is okay. I do plutil, xattr and ocvalidate checks in Plistlib generator.

 

[Angelus]

Yes, move the OC config to a different disk or an USB key, then nuke the disk you want to downgrade from BigSur and follow the steps on the guide for a clean install of Catalina.

Thanks tsialex.

In preparation for possibly going back down to Catalina, I've decided to move Opencore as tsialex suggested to a USB.

I gave it a trial today and in preparation for that did the following:
-Copied Opencore files to my bootable USB
-Disabled Opencore on my "Disk A" with Big Sur.
-I removed Disk A from the bay and then followed the guides instructions to bless the bootable USB using the 1st boot process.

After this however, my Mac wouldn't boot. It would chime and then after about 30 secs switch off. I tried following the recovery process (NVRAM reset etc) in the guide and eventually got back to my Mojave login screen.

I tried a further two times to bless the USB using the guide instructions but with the same outcome.

I reinstalled my Disk A with Opencore/Big Sur and followed the guide to:
1. Re-enable opencore
2. Follow the 1st boot process

My system is back to normal and I'm typing this on Big Sur again.

I've tried searching the forum and also googling to troubleshoot blessing a USB but to no avail. I'm currently creating a new install media bootable USB in case it was an issue there. I saw on one post online that I may need to disable SIP in order for the bless to work properly but would appreciate advice from anyone who's been through the process.

 

[Bmju]

@startergo -

Some collective wisdom has been applied, both in choosing exactly which SIP bits OC should set by default (one change there), and in explaining which bits OC doesn't set, now documented.

New info (in docs) is:

OC uses 0x26F even though csrutil disable on Big Sur sets 0x7F. To explain the choice:

• csrutil disable --no-internal actually sets 0x6F, and this is preferable because CSR_ALLOW_APPLE_INTERNAL (0x10) prevents updates (unless you are running an internal build of macOS).
• CSR_ALLOW_UNAPPROVED_KEXTS (0x200) is generally useful, in the case where you do need to have SIP disabled, as it allows installing unsigned kexts without manual approval in System Preferences.
• CSR_ALLOW_UNAUTHENTICATED_ROOT (0x800) is not practical as it prevents incremental (non-full) OTA updates.

It was news to me actually that certain SIP bits can mess up updates in the ways mentioned, but people much older and wiser than me in the ways of running macOS on unsupported hardware confirm it!

 

[Bmju]

You need to use both, plutil will check and fix your formatting, ocvalidate will validate if your config content (keys/values) is okay. I do plutil, xattr and ocvalidate checks in Plistlib generator.

So p.1 does not mention ocvalidate at all. Actually this does seem like an omission to me, though obviously @cdf may have his reasons? (Though also recalling that ocvalidate is relatively new...!)

Also, FWIW, ocvalidate does also validate the formatting - it won't normalize it, as the plutil step would, but it won't process the file, and will complain, if it is not valid.