Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
excuse me a question, but on a MacPro 2006 32-bit and can make a change and take a 64-bit? and if you like to do?

thank you.
Your question is not entirely clear. You might want to study the first message of https://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2-1-and-os-x-yosemite.1740775/

That should provide most of the answers you need. As for El Capitan, its compatibility with old Mac Pros is still being implemented by Pike. Mikeboss and myself are simply testing and compiling, respectively, whatever Pike implements in his source code.
 
Herein is the "third" version of build fe3c638bcbc7ea320d4355c94baed457d86e093f. Please, when booted from the Recovery HD, look for the presence of the variable "abc-active-config" in NVRAM (NOT "csr-active-config", mind you).
 

Attachments

  • boot fe3c638bcbc7ea320d4355c94baed457d86e093f version 3.zip
    206 KB · Views: 367
thanks, peter. I'm still unable to submit the csrutil command successfully (same error as yesterday). also there's nothing relevant in the NVRAM to be found. I tested this yesterday with my MacBook Pro which is officially supported. there wasn't an entry in the NVRAM until I manually switched SIP on and/or off.
 
thanks, peter. I'm still unable to submit the csrutil command successfully (same error as yesterday). also there's nothing relevant in the NVRAM to be found. I tested this yesterday with my MacBook Pro which is officially supported. there wasn't an entry in the NVRAM until I manually switched SIP on and/or off.
I take it that there's no "abc-active-config" in NVRAM. Have you let Pike know?
 
Have you let Pike know?

sure did!

csrutil seems to be unable to write to the NVRAM (even the fake abc... entry). what worked though was to manually write the abc-active-config into NVRAM.

-bash-3.2# nvram abc-active-config=”%01%00%00%00″

and this worked (shows up in NVRAM).
 
csrutil seems to be unable to write to the NVRAM (even the fake abc... entry). what worked though was to manually write the abc-active-config into NVRAM.

-bash-3.2# nvram abc-active-config=”%01%00%00%00″

and this worked (shows up in NVRAM).
But it won't work with "csr-active-config", will it? What now? I'm sure Pike has more resources up his sleeve.
 
But it won't work with "csr-active-config", will it? What now? I'm sure Pike has more resources up his sleeve.

no dice. I wasn't even able to create the csr-active-config entry manually in the NVRAM.

pike already posted a comment with a possible solution. not sure though if he plans to commit this or if he wants you to edit the source...
 
Herein, three new versions. I’ve changed back the “abc-active-config” to “csr-active-config”.
 

Attachments

  • boot fe3c638bcbc7ea320d4355c94baed457d86e093f version 4-6.zip
    618.1 KB · Views: 363
all test conducted while booted into the Recovery HD


v4:

nvram -xp -> NO csr entry

-bash-3.2# csrutil status
System Integrity Protection Staus: enabled (Custom Configuration).

Configuration:
Apple Internal: enabled
Kext Signing: enabled
Filesystem Protections: enabled
Debugging Restrictions: enabled
DTrace Restrictions: enabled
NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

-bash-3.2# csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.


v5:

nvram -xp -> NO csr entry

-bash-3.2# csrutil status
System Integrity Protection Staus: enabled (Apple Internal).
-bash-3.2# csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.


v6:

nvram -xp -> NO csr entry

-bash-3.2# csrutil status
System Integrity Protection Staus: enabled (Custom Configuration).

Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: enabled
Debugging Restrictions: enabled
DTrace Restrictions: enabled
NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

-bash-3.2# csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
 
New build of the latest commit.
 

Attachments

  • boot 58c8fec2730113d044318de5c092d07a9180135f.zip
    206 KB · Views: 372
booted into El Capitan Recovery HD with latest boot.efi in place

-bash-3.2# nvram -xp

other NVRAM content
<key>csr-active-config</key>
<data>
eC2/fw==
</data>
other NVRAM content

-bash-3.2# csrutil status
System Integrity Protection staus: enabled.
-bash-3.2# csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
-bash-3.2# csrutil enable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.

-bash-3.2# nvram -d csr-active-config
-bash-3.2# nvram -xp (csr-active-config is still in NVRAM!)
-bash-3.2# nvram -c
-bash-3.2# nvram -xp (csr-active-config is still in NVRAM!)

reboot with option-command-P-R

boot into OS X Yosemite to check content of NVRAM -> no more csr-active-config.

boot into El Capitan Recovery HD with latest boot.efi in place

-bash-3.2# nvram -xp

other NVRAM content
<key>csr-active-config</key>
<data>
eC2/fw==
</data>
other NVRAM content

-bash-3.2# csrutil status
System Integrity Protection staus: enabled.
-bash-3.2# csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
-bash-3.2# csrutil enable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
 
New commit and new build.
 

Attachments

  • boot d897377a6af1b7f7d858a2f5dd51c6b4c352c643.zip
    206 KB · Views: 377
Hey guys - Keep up the good work.

I've a 2006 with 2.1 firmware installed & the upgraded CPUs. I also have the Mac Edition 7950 working with more than a few HDDs lying around (one of them running 10.10). If you want further testing etc PM me. Isn't it about time we bought Pike a 2006 Mac Pro? There must be a few 2GHz ones going for very little on eBay..

I donated to either Pike or Tiamo in the past and would be happy to do so again. Many of us have gained from this work.

F
 
boot with option-command-P-R

boot into OS X Yosemite to check content of NVRAM -> no more csr-active-config.

boot into El Capitan Recovery HD with latest boot.efi in place

-bash-3.2# nvram -xp -> no csr-active-config in NVRAM.
-bash-3.2# csrutil status
System Integrity Protection staus: enabled.
-bash-3.2# csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
-bash-3.2# csrutil enable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
 
I've just seen that there's a new commit available, but I don't think I'll be able to compile it for at least a couple of hours. Sorry. My development environment is on a Windows virtual machine, but I'm currently running a long process on a different virtual machine. If someone else has the right tools and adequate knowledge on how to make a build of the macosxbootloader, El Capitan edition, let them do it. If not, be patient and I'll post it in about two hours, or perhaps a little earlier if we are lucky.
 
Luckily, it was just over one hour. Here's the new build of the latest commit.
 

Attachments

  • boot d9d65783b18cc34a76b236603fd4be345c673cf0.zip
    206 KB · Views: 427
thanks, peter.

-bash-3.2# nvram -xp -> no csr-active-config in NVRAM.
-bash-3.2# csrutil status
System Integrity Protection staus: enabled.
-bash-3.2# csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
-bash-3.2# csrutil enable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
 
New build (Debug/Win32) of latest commit.
 

Attachments

  • boot 16636c2e884bfaefe20c0fced75ee2b5fbe6ccaf.zip
    226.4 KB · Views: 332
It appears Pike prefers the Release/Win32 mode. Therefore, here it is. Disregard the previous one.
 

Attachments

  • boot 16636c2e884bfaefe20c0fced75ee2b5fbe6ccaf Release.zip
    206.1 KB · Views: 338
Since I don't really know which version may suit Pike's purposes better, herein are the Debug and Release versions of commit cafd216ec8da31d527ff79c1ba7d25bf4d440e14.
 

Attachments

  • Boot cafd216ec8da31d527ff79c1ba7d25bf4d440e14.zip
    432.7 KB · Views: 405
"debug" version gave an instant reboot

release version:


-bash-3.2# nvram -xp

other NVRAM content
<key>csr-active-config</key>
<data>
EAAAAA==
</data>
other NVRAM content

-bash-3.2# csrutil status
System Integrity Protection Staus: enabled (Apple Internal).
-bash-3.2# csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
-bash-3.2# csrutil enable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
 
Release/Win32 of latest commit.
 

Attachments

  • boot cb817ff9f373a092aebb4fd0f90b66f330d01cb7.zip
    206.1 KB · Views: 456
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.