Interesting, because I run it on the Quad (also on 2.3DC, both installed and work with no issues).
What does send my Quad into KP is Sonnet PCIe card, so I need to hack it off in OpenFirmware when booting 10A190.
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.
Snow Leopard on Unsupported PowerPC Macs
- Thread starter Larsvonhier
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
What does send my Quad into KP is Sonnet PCIe card, so I need to hack it off in OpenFirmware when booting 10A190.
👍 for finally saving my day/night!
Snowleo PPC doesn't seem to like any PCIe cards too much! After endless trying to get a normal installer to work in any thinkable way...with no success, i restored the clean install dmg another time. "As is" it instantly panicked again. But when i removed all my PCIe-cards except the GPU, it suddenly booted. But as soon as i reinsert anything - the AHCI-SSD in this case - it was giving kernelpanics again.
So, as i like my fast storage more than some experimental operating system, i'm actually cloning my 10.5.8 backup-install to the "Snowleo"-disk and decleare my 10.5.6 PPC-project as ended.
That’s entirely fair!
For what it’s worth, I’ve come to reckon distinct use-cases for each of Builds 10A96 and 10A190: if you want to build and compile software (macports, etc.), go with 10A190. If you want overall stability of your system and compatibility of components, unless you’re willing to conduct your own troubleshooting, Build 10A96 is probably the way to go.
Either build, regardless, still requires fixes outlined in the wikipost to improve stability — many of which I hope to integrate into an “updater” of sorts to cover all those changes in one fell swoop. Build 10A190 needs to borrow more heavily from 10A96 and Leopard components, as Apple had begun to strip out a lot of Universal Binary support by that milestone of development.
Once those fixes are in place, Build 10A96 (what I know best) is actually fairly pleasant to use for a new OS so early in its development.
As for why things didn’t work out for your G5, I don’t know what to offer here. All my testing has happened with Build 10A96 on a G4. Both @barracuda156 and @ChrisCharman have done most of their testing with Build 10A190 on their G5s.
Again, I’m sorry it didn’t work out for you.
Just in case, did you see my fix with OpenFirmware above?
While you cannot use PCIe SSDs with 10.6 PPC, at least not yet, you can have them installed (to use with other OS), and 10.6 PPC booting normally.
I tried to boot 10A96 with Sonnet card in, and without OpenFirmware trick it went into KP just like 10A190.
Thanks for your words. Yes, i was thinking of giving 10A96 a shot too.
But one one hand there was allready too much time spent in the project and on the other i did not really get the point to further play around with some highly experimental OS which is basically older than the refined stable one i am using.
But as far as i get it, this "open firmware trick" means just hiding it to the boot process via PCI probe mask. Meaning it can not be used after booting. So you might as well physically pull the card, right?
This is in no way your fault! So nothing to apologise.
If it did not work for me it might well (and be a lot of fun) for others. So thanks for the time and effort you (and others) have put and are still putting into this.
It’s completely understandable for each of us to have hit all our limits on working with the SL-PPC project. Not too dissimilar from you, I’ve taken a break from it for several months as other life stuff (and, well, the end of pandemic lock-down) have taken centre stage.
At some point I’ll likely come back to it to finish the work on 10A96 I started, and who knows? If I pick up a multi-core G5, I might pick up the reins once more and see what I can do with it there. But at least we’ve all a much better idea than in 2020 what the limits of early development for this OS were. We knew the potential was there, and we followed those potentials to their probable ends — far and beyond what anyone (at Apple or otherwise) would have expected from the user community back in 2008.
Although there lies that remote possibility that some later, internal-only iteration of a UB-accessible build exists out there and manages to surface, I think we’ve all found our way to a pause or rest point on the work we’ve done. And that’s good enough. You’ve done excellent work on the 10A190/G5 side, and I for one am grateful for your volunteerism. 👍
I wonder whether this is a kext issue, of a particular 10A96/10A190 kext and/or framework being the culprit, whereas bringing over a 10.5.8 kext of the same would fix the issue?
After all, there remain several kexts and frameworks for which I have been unable to test adequately on 10A96 because they’re specific to hardware in the G5s, or to Power Macs more generally. One such example was in learning recently that the AHCI-related kexts weren’t, as I originally gleaned, an Intel-only feature of OS X!
Thus, Table 4’s info, for either of 10A96 or 10A190 will not be accurate for those kexts/frameworks/etc. which need to be in place from a more developed build of OS X (like 10.5.8) in order for the KPs on third-party PCIe or PCI(-X) cards to go away (and without a need to fuss with Open Firmware).
Last edited:
Would have been nice. So, as in my case it have been AHCI-devices causing the trouble, i had another look at it to find out that Leo/Sorbet are using version 1.7.0 of the AppleAHCIport.kext while Snow Leo PPC on the pre installed image only has 1.5.2. I once again cloned the Image to a disk and replaced the kext with the newer one. No kextcache to remove as there was none present. But sadly it didn't change a thing.
Last edited:
If I’m not mistaken, all four of the following AHCI-related kexts in SL-PPC require being set aside in 10A96/10A190 (usually, I’ll just change the kext’s extension to “.kext106” to set the SL-PPC version(s) aside and to have them nearby if I have to later switch them back) as root, followed by bringing in the following four kexts from 10.5.8 (also, as root*):
(Ignore the fact that they’re presently labelled in orange; I need to update that.)
The version numbers from 10.5.8 are in the left of the three columns — i.e., 1.2.5, 1.2.0, 1.7.0, and 1.5.0.
* for moving kexts, Frameworks, and/or PrivateFrameworks into place, I personally move everything via command line, logged in as root — almost always, and booted into another build of OS X on that computer (for my SL-PPC mule, I have 10.5.8 on a different partition, and I reboot into this and log into Leopard as root/System Administrator, then do the moving of kexts/FWs/etc. from there. This way, I can be sure that not only will it not bring a running system to a sudden kernel panic, but also the ownership:group and permissions of what I just brought over will have what the system needs). If a test kext/FW/etc. doesn’t work, then I can remove those and then rename the ones I set aside back to “.kext” or “.framework” once more.
EDIT: Upon a second inspection, the ACPI kexts appear to be not related to AHCI, but instead to SMC-related stuff on Intel Macs. Just worry about the pair of AHCI kexts — or, if you want to act with an abundance of caution, move all four over, even though the ACPI-related ones won’t affect anything on a Power Mac G5.
Last edited:
Installed on this preinstalled Image are: 1.2.1, 1.3.0, 1.5.2 and 1.5.0. So a strange mix of outdated and recent anyway. Also the IOAHCIFamily.kexts which i compared, while having the same version number, have completely different filesizes: 1,2MB for the SnowLeo vs. 870k for the Leo-version.
Maybe, one day i will try to just move all of them over from Leo and see, if it works. But for now i'm done. 😟
With exception to the first number, all those match what I pasted above from Table 4 in the WikiPost for what one will find in both developer builds.
Although you won’t be doing the kext swap in the near future, I have a feeling the 10.5.8 kext components will help with the AHCI card you have in your G5.
Well, you might, but convenience is questionable. Assuming the machine has more than 1 version OS bootable, OpenFirmware trick makes a better sense IMO.
I have not had any stability issues with 10A190. Hardware compatibility is better with 10A96, no doubt. With software, 10A96 is strange at best.
Without checking, a quick guess: with ~300kb per arch, removing ppc64 gonna result in 870kb.
Obviously, universal is expected to include archs supported by the OS to begin with. ppc64 is not supported in 10.6, be it 10.6 PPC or 10.6.8 Rosetta.
So i couldn't resist to give it another...
Transferred all four AHCI-related kexts from a working Leo-install. I even reset the PRAM. But sadly with the same result. ☹️
And this was following a kext cache flush as well, yes?
Something tells me this is a topic of interest I’m going to throw myself into (in order to understand more of what’s happening beneath the bonnet), once I start tinkering with SL-PPC on a multi-core G5…
Oops! Just noticed, that the 10A190-image well has some extensions.mkext, but not where expected, on the root level of System/Library, but instead nested in System/Library/Caches/com.apple.kext.caches. So i will give it one last try with the contents of Cache-folder completely deleted.
Update: Still no! Seems that Snow Leo PPC just doesn't like AHCI. Sorry!
Last edited:
I’m starting to wonder whether there might be more needed for AHCI compliance. When I start testing with a G5, I’ll need to add a plan to observe logs in Leopard to know everything AHCI support relies on. The train of thought goes, “If everything Leopard requires for AHCI support is migrated to the SL-PPC setting, it ought to work.” — ought, as opposed to should. Testing will need to bear this out, and my work will be cut out.
If it is in the kernel, we are out of luck, at least until someone rebuilds a newer kernel for 10A190.