Resolved 2006/2007 Mac Pro (1,1/2,1) and OS X Yosemite

[Hennesie2000]

check your inbox

Thanks, and after putting that in place and reinstalling the AppleHDA.kext using Kext Drop everything is working great except for iMessage. I only have one Apple ID so I haven't tried what you mentioned earlier about creating a new one and trying that.

 

[gpatpandp]

Thanks, and after putting that in place and reinstalling the AppleHDA.kext using Kext Drop everything is working great except for iMessage. I only have one Apple ID so I haven't tried what you mentioned earlier about creating a new one and trying that.

I know this may be a hassle however booting your partition once in clover and signing in in there will guarantee a working iMessage and FaceTime from this point forward when booting in Chameleon thereafter.

 

[Hennesie2000]

I know this may be a hassle however booting your partition once in clover and signing in in there will guarantee a working iMessage and FaceTime from this point forward when booting in Chameleon thereafter.

I found instructions on the InsanelyMac forum to be able to use the FileNVRAM.dylib but unfortunately it still does not allow me to log into iMessage. I redid the entire install to start fresh and this time around with the dsdt.aml file in place from the beginning I did not have any issues with USB, SATA, or audio. It all just worked.

 

[PeterHolbrook]

check your inbox

Just one or two questions: Is that dsdt.aml the same as the one published, for example, by Jabbawok (17,571 bytes)? If not, can you share it?

 

[JoSch]

I’m pretty sure they drop things unnecessarily. In absolute terms it’s a matter of opinion I suppose but in relative terms…….

They have a reason: It's a bag of hurt to support the machines. While I'm savvy enough to keep MacOSX running on my Macpro, I wouldn't trust anyone in my family to do that. That means I would have to support that, which I wouldn't like to do.

I have an SSD in my Pro that has a copy of Windows 7 that I use for gaming. Two things;
Boot camp for my pro does not support 7.
I also have 7 running on an old and cheap PC I bought for £20, (with no hacks), it installed without putting up a fight with a lot less than the minimum specified RAM.
This would not happen with ANYTHING that sports an Apple logo.

That recent Boot camp doesn't support your Mac, doesn't mean, that Win7 wouldn't run. I have Win7 running with recent Boot camp drivers on my Macpro 2,1.

 

[ProfDrLuigi]

Problems with booting on my 2,1

Hi folx.

I installed 10.10 yesterday on my 2,1. The Install went smoot. But if I try to boot the fresh installed system the boot process stops as seen on the picture.



Makes no difference if I use Clover or Chameleon. It stops at the same place.

Cache is renewed, rights are checked/fixed and kext-dev-mode=1. Don´t know why it will not boot up. Any idea?

If I boot in Non-Verbose Mode the Background is black. Normally its grey. Perhaps my Install-Application is not ok?

I installed 10.10 side by side on my SSD with 10.9. But i don´t think that could be the problem.

 

[PeterHolbrook]

Makes no difference if I use Clover or Chameleon. It stops at the same place.

By any chance, is that output from Tiamo's boot.efi? That boot.efi is incompatible with Yosemite.

 

[ProfDrLuigi]

No its the Vanilla One.

 

[Hennesie2000]

They have a reason: It's a bag of hurt to support the machines. While I'm savvy enough to keep MacOSX running on my Macpro, I wouldn't trust anyone in my family to do that. That means I would have to support that, which I wouldn't like to do.


That recent Boot camp doesn't support your Mac, doesn't mean, that Win7 wouldn't run. I have Win7 running with recent Boot camp drivers on my Macpro 2,1.

Tiamo's boot.efi proves that it would not be a lot of trouble to support these machines that are fully 64bit capable but have the 32bit efi. The installer could easily check for the 32bit efi and then install a different boot.efi that is compatible. This is why if you create an install DVD using tiamos boot.efi and modify the osinstall.mpkg with the right board id, Mavericks will install just as if it were a supported machine.

 

[JoSch]

Tiamo's boot.efi proves that it would not be a lot of trouble to support these machines that are fully 64bit capable but have the 32bit efi. The installer could easily check for the 32bit efi and then install a different boot.efi that is compatible. This is why if you create an install DVD using tiamos boot.efi and modify the osinstall.mpkg with the right board id, Mavericks will install just as if it were a supported machine.

I didn't mean, that they couldn't technically support running a 64bit kernel on mac 1,1/2,1.
I meant, that they probably don't want to support all the little problems like older graphic cards, "no boot menu screen" on newer cards etc. All these little problems, nobody in their right mind wants to handle, if they can avoid it.

 

[ProfDrLuigi]

Managed it. Booting with

kext-dev-mode=0

solves my Problem.

 

[Hennesie2000]

I didn't mean, that they couldn't technically support running a 64bit kernel on mac 1,1/2,1.
I meant, that they probably don't want to support all the little problems like older graphic cards, "no boot menu screen" on newer cards etc. All these little problems, nobody in their right mind wants to handle, if they can avoid it.

They already support no boot menu screen and have since 10.7 which was supported on the 1,1/2,1. 10.7 included all the drivers needed to use a PC Nvidia card with out any injectors or helper cards. They also don't have to support the older cards in these machines because the cards are upgradable. You just make it a minimum system requirement of the OS. You also have a choice of not boot menu or not. If you want it then just buy a official efi Mac card or flash one.

 

[H2SO4]

They have a reason: It's a bag of hurt to support the machines. While I'm savvy enough to keep MacOSX running on my Macpro, I wouldn't trust anyone in my family to do that. That means I would have to support that, which I wouldn't like to do.


That recent Boot camp doesn't support your Mac, doesn't mean, that Win7 wouldn't run. I have Win7 running with recent Boot camp drivers on my Macpro 2,1.

You’re missing the point. Rather than just declare, ‘We don’t support X’, they actively discourage it. That’s different. I mean they actually put effort into preventing it from running rather than just a) Going about their business and take the attitude that if it runs it runs, or B) Refusing to support.
For the record I have Win 7 running on my 1,1 brilliantly. But I’d suggest that Apple actively prevent it if they can.

My company makes a number of large products. When they become EOL we just tell clients that they can still run whichever way they choose it but we will support while we can and for as long as parts are available.
We don’t actively refuse to help or arbitrarily put up prices etc etc.

 

[Hennesie2000]

I'm wondering if my iMessage issues are Hardware UUID related. When booted with chameleon it is completely different than when booted natively in Lion or in Mavericks with Tiamo's boot.efi.

 

[genex]

ok, so i figure one part, if i format BOOT partition as HFS+ it won't boot clover, i f it is FAT then will boot but still want go more i am inside clover i see all disks but when i select Installer it just refresh screen

 

[Hennesie2000]

New official Chameleon bootloader coming out soon! Hopefully this will fix some of the NVRAM issues.

UPDATE:

New version of chameleon (2.2 r2380) does not require the mach_kernel in the root of the Yosemite partition. Use this in your org.chameleon.Boot.plist to have it auto find the kernel.

<key>Kernel</key>
<string>/System/Library/Kernels/kernel</string>

You can also remove the kernel flag:

kext-dev-mode=1

 

[JoSch]

You’re missing the point. Rather than just declare, ‘We don’t support X’, they actively discourage it. That’s different. I mean they actually put effort into preventing it from running rather than just a) Going about their business and take the attitude that if it runs it runs, or B) Refusing to support.

How does Apple actively prevent that? I don't see that. Prove your point, please.

----------

They already support no boot menu screen and have since 10.7 which was supported on the 1,1/2,1. 10.7 included all the drivers needed to use a PC Nvidia card with out any injectors or helper cards. They also don't have to support the older cards in these machines because the cards are upgradable. You just make it a minimum system requirement of the OS. You also have a choice of not boot menu or not. If you want it then just buy a official efi Mac card or flash one.

Really? Apple supports, that you have no boot screen?
In my opinion, "support" is a bit of exaggeration of the situation. Booting just don't fail, that's all.

 

[H2SO4]

How does Apple actively prevent that? I don't see that. Prove your point, please.

----------



Really? Apple supports, that you have no boot screen?
In my opinion, "support" is a bit of exaggeration of the situation. Booting just don't fail, that's all.

We’re obviously going to agree to disagree. I’ve said enough already that you’ve ignored. I’ll make one more statement then we’ll call it a day.
Apples OS, (mobile and otherwise), WILL work on more hardware than is officially supported. Apples reasoning is that it will spoil the user experience and they specifically write a plist to prevent what ever it is that doesn’t fit their ideals, they limit the AppStore also. How about I be the judge of what works as it’s my money, tell me what’s minimum and I’ll decide?

 

[PeterHolbrook]

We’re obviously going to agree to disagree. I’ve said enough already that you’ve ignored. I’ll make one more statement then we’ll call it a day.
Apples OS, (mobile and otherwise), WILL work on more hardware than is officially supported. Apples reasoning is that it will spoil the user experience and they specifically write a plist to prevent what ever it is that doesn’t fit their ideals, they limit the AppStore also. How about I be the judge of what works as it’s my money, tell me what’s minimum and I’ll decide?

Although, in theory, you might have a point, your point would only be valid in a "perfect" world in which all Apple clients were expert users, capable of tweaking their systems in whatever was needed to make them work with the latest incarnation of an OS. Obviously, that is not the case. Of all the owners of early Mac Pros, for instance, only a small percentage know how to install Chameleon or similar solutions to bypass the 32-bit EFI hurdle. Now, if we were all experts, perhaps Apple could say that Mountain Lion was compatible with all Mac Pros and leave to the individual user the task of creating a special installer, et cetera. But, as I say, we aren't all experts. Do you actually contemplate a scenario wherein, if you were Apple, you'd receive tens of thousands of complaints from unsuspecting early Mac Pro users surprised that Mountain Lion won't boot on their systems? Would you consider it is your task to educate such users to tweak the installation so that it will succeed on 32-bit EFI machines for which the OS was never intended? I wouldn't want to do such a thing if I were Apple.

It is far more reasonable to leave it to the expert user's ingenuity to see how far they can make their old hardware work with the latest OS. Obviously, there'll be some limitations, eased by the obvious savings, but Apple won't be involved in supporting such obsolete machines. It is only fair that the relevant plist should exclude early Mac Pros from the supported hardware list, because most users have no idea how to bypass that.

 

[JoSch]

It is far more reasonable to leave it to the expert user's ingenuity to see how far they can make their old hardware work with the latest OS. Obviously, there'll be some limitations, eased by the obvious savings, but Apple won't be involved in supporting such obsolete machines. It is only fair that the relevant plist should exclude early Mac Pros from the supported hardware list, because most users have no idea how to bypass that.

Moreover, if Apple really wanted to hinder us using Macpro 1,1 with ML and later, neither Tiamo's boot.efi nor Chameleon/Clover would work.

 

[JoSch]

We’re obviously going to agree to disagree. I’ve said enough already that you’ve ignored. I’ll make one more statement then we’ll call it a day.

I didn't ignore what you said. You never really argued. You just state, that you feel, that "Apple is evil", because they don't support your hardware in all eternity.

 

[gpatpandp]

Fudge...

Late last night I was refining my Yosemite set-up. Due to an experience I had in the past, I always prevent my Chameleon "BOOT" partition from auto mounting after boot. Since I had not done the procedure in a while, I looked through an archive of terminal commands I maintain and incorrectly selected these to perform the task:

/usr/sbin/diskutil unmount /dev/disk2s3
/usr/sbin/asr adjust --target /dev/disk2s3 -settype BOOT

...I have since identified these commands as ones that are instead meant to hide the Recovery Partition in this fashion:

/usr/sbin/diskutil unmount /dev/disk2s3
/usr/sbin/asr adjust --target /dev/disk2s3 -settype Apple_Boot

Long story short, I created one big headache for myself. Not only did incorrectly applying these commands kill my Chameleon BOOT partition, it has done something that has left me completely and utterly stumped and I cannot for the life of me figure out how to resolve the issue. Furthermore I am not even finding much about what I am experiencing to be able to troubleshoot it.

Basically in both OS X 10.6 and 10.7, when enabling the Debug tab in disk utility and listing all partitions, any EFI partition associated with any disk that I have mounted in either OS X system at the time will appear as shown in the Pic on the left. It is listed as the partition number, NOT as "EFI", and WILL NOT MOUNT.

Conversely, when having the exact same hard drives mounted in OS X 10.9 when the same Debug tab is enabled and listing all partitions, the EFI partition is identified correctly as "EFI" and the partition itself can be mounted/unmounted at will with absolutely no issue as shown in the pic on the right hand side of this page.

As I mentioned, I have no explanation for this odd behavior and frankly it has completely confused me. Anyone have any suggestions on a potential fix and at least a place to start ?

 

[Hennesie2000]

Moreover, if Apple really wanted to hinder us using Macpro 1,1 with ML and later, neither Tiamo's boot.efi nor Chameleon/Clover would work.

That's not true. How can they fully stop something that is developed third party as a workaround? It's like saying Apple would have completely stopped jail breaking after iOS 1. They release their OS and THEN developers get to work. Sure they can release a patch like they do on iOS of the jailbreak method involves a security exploit to run the code.

 

[JoSch]

That's not true. How can they fully stop something that is developed third party as a workaround? It's like saying Apple would have completely stopped jail breaking after iOS 1. They release their OS and THEN developers get to work. Sure they can release a patch like they do on iOS of the jailbreak method involves a security exploit to run the code.

At least, they would make it really really hard.

 

[Hennesie2000]

Late last night I was refining my Yosemite set-up. Due to an experience I had in the past, I always prevent my Chameleon "BOOT" partition from auto mounting after boot. Since I had not done the procedure in a while, I looked through an archive of terminal commands I maintain and incorrectly selected these to perform the task:

/usr/sbin/diskutil unmount /dev/disk2s3
/usr/sbin/asr adjust --target /dev/disk2s3 -settype BOOT

...I have since identified these commands as ones that are instead meant to hide the Recovery Partition in this fashion:

/usr/sbin/diskutil unmount /dev/disk2s3
/usr/sbin/asr adjust --target /dev/disk2s3 -settype Apple_Boot

Long story short, I created one big headache for myself. Not only did incorrectly applying these commands kill my Chameleon BOOT partition, it has done something that has left me completely and utterly stumped and I cannot for the life of me figure out how to resolve the issue. Furthermore I am not even finding much about what I am experiencing to be able to troubleshoot it.

Basically in both OS X 10.6 and 10.7, when enabling the Debug tab in disk utility and listing all partitions, any EFI partition associated with any disk that I have mounted in either OS X system at the time will appear as shown in the Pic on the left. It is listed as the partition number, NOT as "EFI", and WILL NOT MOUNT.

Conversely, when having the exact same hard drives mounted in OS X 10.9 when the same Debug tab is enabled and listing all partitions, the EFI partition is identified correctly as "EFI" and the partition itself can be mounted/unmounted at will with absolutely no issue as shown in the pic on the right hand side of this page.

As I mentioned, I have no explanation for this odd behavior and frankly it has completely confused me. Anyone have any suggestions on a potential fix and at least a place to start ?

This is just a hunch but could it be anything to do with 64bit vs 32bit? I don't know if you are running 10.7 in 64bit or booting it natively as 32bit but perhaps the EFI partitions are somehow unreadable when in a 32bit environment since they were created using a 64bit only OS? I can boot up my 10.7 Install if you want me to check and see if I have a similar result when looking at my 10.10 install's EFI partition.

If you don't have it here are the commands you want to stop a partition from automounting:

sudo pico /etc/fstab

UUID=NUMBER none hfs rw,noauto

where 'NUMBER' is the UUID of the partition you don't want to mount