10.6 Snow Leopard PowerPC Development

[barracuda156]

Incidentally, do we yet have a list of software that will run on PowerPC 10.6.8, but not in 10.5.8? Or in 10.6.8, but not even in 10A190/10A96?

I have seen once or twice some 10.6.x software compiled as Universal Binaries, so they'd be perfect for checking this, except I forgot their names.

Opensource – yes, perhaps a lot (at least unless someone goes extra mile to add fixes for 10.5).
Proprietary – it theory it is possible, since Xcode 3.2.6 supports compiling for ppc, SDK supports ppc, so as long as someone was lazy enough to throw away the target, it could compile as UB in a sense by chance, and if binaries are small anyway, not much reason to care. In practice, perhaps, such instances are very rare.

P. S. Better discuss third-party software in a separate thread.

 

[educovas]

Thank you very much.

By the way, can we control version which modified or replaced frameworks report to whatever links to them? For example, I swapped back original 10a190 frameworks (on 10a190), and got two ports broken:

Incompatible library version: /opt/local/bin/toxic requires version 64.0.0 or later, but /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore provides version 1.2.0
Incompatible library version: /opt/local/libexec/vlc2/lib/vlc/plugins/video_output/libcaopengllayer_plugin.dylib requires version 64.0.0 or later, but /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore provides version 1.2.0

The problem is not these ports, of course, it is a matter of rebuilding them, but compatibility of software between 10a190 and 10.6.8 (when 10.5 frameworks are borrowed) in principle. While in some specific cases compatibility genuinely cannot be had (say, when something uses IOSurface), arguably in most such breakage is unnecessary and is caused simply by versions mismatch.

If these can be changed, it is probably sensible to bring versions of 10.5 frameworks to whatever 10a190 has (so that all usable versions of 10.6 have same versions here).

Any thoughts on this?

I think that should be fixable but I don't understand what you're doing... are you using my patched QuartzCore on 10A190 or is that 10.6.8?

 

[barracuda156]

I think that should be fixable but I don't understand what you're doing... are you using my patched QuartzCore on 10A190 or is that 10.6.8?

This is 10a190. I used the patch from here: https://forums.macrumors.com/thread...s.2232031/page-90?post=33080867#post-33080867
It did not work for my installation, i.e. the system was fine, but no hardware acceleration, I guess I missed something needed for Nvidia (I did pull over some kexts, but easily could miss something). Anyway, I had it for a few days, but then decided to revert first to original 10a190 frameworks and kexts which were replaced.
In the meanwhile, when the patch was applied (and therefore frameworks from 10.5.8 used), I built some ports, including those which I refer.
Once I reverted to 10a190 versions, these two ports turned out broken, due to versions mismatch. (Rebuilding them fixed the issue, as expected.)

If we have 10a190 “original” (I know some kexts are replaced anyway, but now I refer specifically to graphics ones), 10a190 with frameworks from 10.5.8 (I am sure there are users who applied that patch and it works correctly for them, at least with ATI cards), 10.6.8 with frameworks from 10.5.8 (your current image) and later 10.6.8 with frameworks from 10a190 (specifically for Nvidia cards), then there are two incompatible versioning for those.
Besides obvious difficulties for anyone switching between the two (as I did), this means that some pre-built software has to exist in two incompatible build versions or it will be broken for a subset of users. Now consider users who are not experts in building stuff from source and tweaking build systems. We already seen some frustration expressed when a pre-built port had an undeclared dependency, which led to MacPorts thinking it is broken. In practice end users (however few of them will be there) are likely to decide that our PowerPC Ports (or something else) is messed up and maintainers do not care about fixing bugs, so they just give up on using such pre-built software distribution systems. Any solution I can think of is rather painful both for me and for end users. (Say, I could make variants of VLC +legacy_gl and VLC +new_gl, but there is no way for the build system to know which is appropriate, so a user must pick the right one manually, which assumes he is gonna study instructions in the first place, which seldom is done LOL; it is also a hassle for me to build two separate variants of such; moreover, we have no real idea which software gonna break, unless someone notices the breakage, so unknown number of ports will be potentially broken on one of the two alternative set-ups.)

 

[Jubadub]

This is 10a190. I used the patch from here: https://forums.macrumors.com/thread...s.2232031/page-90?post=33080867#post-33080867
It did not work for my installation, i.e. the system was fine, but no hardware acceleration, I guess I missed something needed for Nvidia (I did pull over some kexts, but easily could miss something). Anyway, I had it for a few days, but then decided to revert first to original 10a190 frameworks and kexts which were replaced.
In the meanwhile, when the patch was applied (and therefore frameworks from 10.5.8 used), I built some ports, including those which I refer.
Once I reverted to 10a190 versions, these two ports turned out broken, due to versions mismatch. (Rebuilding them fixed the issue, as expected.)

If we have 10a190 “original” (I know some kexts are replaced anyway, but now I refer specifically to graphics ones), 10a190 with frameworks from 10.5.8 (I am sure there are users who applied that patch and it works correctly for them, at least with ATI cards), 10.6.8 with frameworks from 10.5.8 (your current image) and later 10.6.8 with frameworks from 10a190 (specifically for Nvidia cards), then there are two incompatible versioning for those.
Besides obvious difficulties for anyone switching between the two (as I did), this means that some pre-built software has to exist in two incompatible build versions or it will be broken for a subset of users. Now consider users who are not experts in building stuff from source and tweaking build systems. We already seen some frustration expressed when a pre-built port had an undeclared dependency, which led to MacPorts thinking it is broken. In practice end users (however few of them will be there) are likely to decide that our PowerPC Ports (or something else) is messed up and maintainers do not care about fixing bugs, so they just give up on using such pre-built software distribution systems. Any solution I can think of is rather painful both for me and for end users. (Say, I could make variants of VLC +legacy_gl and VLC +new_gl, but there is no way for the build system to know which is appropriate, so a user must pick the right one manually, which assumes he is gonna study instructions in the first place, which seldom is done LOL; it is also a hassle for me to build two separate variants of such; moreover, we have no real idea which software gonna break, unless someone notices the breakage, so unknown number of ports will be potentially broken on one of the two alternative set-ups.)

"End users" will usually want the "latest and greatest" of everything, so they would intuitively pick a 10.6.8 system and not 10A190 or any other alpha, unless if told otherwise. So ideally everything being done for the 10.6.8 build in the end makes more sense for the "end user" than 10A190, so giving priority to and maintaining apps for 10.6.8 makes more sense than the other way around, from that point-of-view.

However, if 10.6.8 is, definitely, worse to stick with than 10A190 (or any other Snow Leo build), then that can be emphasized and communicated, however I doubt that's the case: if by any chance something is broken in 10.6.8 and not in 10A190, what we want in general is not to have 10.6.8 discarded, but rather to have whatever is broken in it fixed instead.

Just commenting as an "outsider" to the project.

EDIT: If the issue, however, remains even if we only stick with 10.6.8, and is instead only tied to which frameworks versions are used (10.5.8, 10A190 etc.), and it makes sense to use one set of frameworks over another depending on the exact Mac model for compatibility reasons, then I see no way to deal with the situation other than, somehow, normalizing the pre-built software to work regardlessly, OR to simply live with the issue and require 2 different builds of each software.

 

[barracuda156]

"End users" will usually want the "latest and greatest" of everything, so they would intuitively pick a 10.6.8 system and not 10A190 or any other alpha, unless if told otherwise. So ideally everything being done for the 10.6.8 build in the end makes more sense for the "end user" than 10A190, so giving priority to and maintaining apps for 10.6.8 makes more sense than the other way around, from that point-of-view.

However, if 10.6.8 is, definitely, worse to stick with than 10A190 (or any other Snow Leo build), then that can be emphasized and communicated, however I doubt that's the case: if by any chance something is broken in 10.6.8 and not in 10A190, what we want in general is not to have 10.6.8 discarded, but rather to have whatever is broken in it fixed instead.

Just commenting as an "outsider" to the project.

10.6.8 has a broken internet at the moment (DNS/DHCP, it practice nearly defunct browsing), which perhaps matters a lot for most of end-users. (Once it is fixed, I will have no reason to use 10a190 myself.)

 

[educovas]

This is 10a190. I used the patch from here: https://forums.macrumors.com/thread...s.2232031/page-90?post=33080867#post-33080867
It did not work for my installation, i.e. the system was fine, but no hardware acceleration, I guess I missed something needed for Nvidia (I did pull over some kexts, but easily could miss something). Anyway, I had it for a few days, but then decided to revert first to original 10a190 frameworks and kexts which were replaced.
In the meanwhile, when the patch was applied (and therefore frameworks from 10.5.8 used), I built some ports, including those which I refer.
Once I reverted to 10a190 versions, these two ports turned out broken, due to versions mismatch. (Rebuilding them fixed the issue, as expected.)

If we have 10a190 “original” (I know some kexts are replaced anyway, but now I refer specifically to graphics ones), 10a190 with frameworks from 10.5.8 (I am sure there are users who applied that patch and it works correctly for them, at least with ATI cards), 10.6.8 with frameworks from 10.5.8 (your current image) and later 10.6.8 with frameworks from 10a190 (specifically for Nvidia cards), then there are two incompatible versioning for those.
Besides obvious difficulties for anyone switching between the two (as I did), this means that some pre-built software has to exist in two incompatible build versions or it will be broken for a subset of users. Now consider users who are not experts in building stuff from source and tweaking build systems. We already seen some frustration expressed when a pre-built port had an undeclared dependency, which led to MacPorts thinking it is broken. In practice end users (however few of them will be there) are likely to decide that our PowerPC Ports (or something else) is messed up and maintainers do not care about fixing bugs, so they just give up on using such pre-built software distribution systems. Any solution I can think of is rather painful both for me and for end users. (Say, I could make variants of VLC +legacy_gl and VLC +new_gl, but there is no way for the build system to know which is appropriate, so a user must pick the right one manually, which assumes he is gonna study instructions in the first place, which seldom is done LOL; it is also a hassle for me to build two separate variants of such; moreover, we have no real idea which software gonna break, unless someone notices the breakage, so unknown number of ports will be potentially broken on one of the two alternative set-ups.)

I'm almost sure I know what happened, the problem is not in the framework itself (QuartzCoreOriginal) but it's on my wrapper (QuartzCore), it was built with an incorrect version so this shouldn't be a problem once I rebuild the frameworks that required wrappers with the correct version.

 

[educovas]

@barracuda156 here is the image for 10.6.8 with OpenGL from 10A190. Using this GL allowed restoring almost every framework previously from 10.5.8 that are related to the graphics acceleration patch.

Image: https://mega.nz/file/8dJQ1IZR#UmaeZkKs20QVSVMl7ZjVtddJV4lH5iljPE0qo6Fpr04

changes:

Nvidia kexts from 10A190
OpenGL.framework from 10A190
ATS.framework from 10.6.8
ColorSync.framework from 10.6.8
CoreGraphics.framework from 10.6.8
CoreText.framework from 10.6.8
ImageIO.framework from 10.6.8
QuartzCore.framework from 10.6.8
ImageKit.framework from 10.6.8
PDFKit.framework from 10.6.8
QuartzComposer.framework from 10.6.8
QuartzFilters.framework from 10.6.8

Just a reminder: this is only for Nvidia PCI/PCIe GPUs and it's intended for testing only.

 

[MarkSokolovsky]

Your KPs could be related to sleep. At least for me the OS is considerably more stable if I disable sleep.

You are 100% correct.

 

[barracuda156]

@barracuda156 here is the image for 10.6.8 with OpenGL from 10A190. Using this GL allowed restoring almost every framework previously from 10.5.8 that are related to the graphics acceleration patch.

Image: https://mega.nz/file/8dJQ1IZR#UmaeZkKs20QVSVMl7ZjVtddJV4lH5iljPE0qo6Fpr04

changes:

Nvidia kexts from 10A190
OpenGL.framework from 10A190
ATS.framework from 10.6.8
ColorSync.framework from 10.6.8
CoreGraphics.framework from 10.6.8
CoreText.framework from 10.6.8
ImageIO.framework from 10.6.8
QuartzCore.framework from 10.6.8
ImageKit.framework from 10.6.8
PDFKit.framework from 10.6.8
QuartzComposer.framework from 10.6.8
QuartzFilters.framework from 10.6.8

Just a reminder: this is only for Nvidia PCI/PCIe GPUs and it's intended for testing only.

Awesome, thank you!

PCI* Nvidia implies this is restricted to PowerMacs?

 

[educovas]

Compatibility should be the same as 10A190 and

Awesome, thank you!

PCI* Nvidia implies this is restricted to PowerMacs?

apparently graphics acceleration only works on PCI/PCIe, no idea if any other ppc Macs had PCI/PCIe GPUs.

 

[Project Alice]

Compatibility should be the same as 10A190 and


apparently graphics acceleration only works on PCI/PCIe, no idea if any other ppc Macs had PCI/PCIe GPUs.

Graphics is working in the image in this thread. It's the mostly vanilla DPs in the other thread that have that problem. I booted it on a PowerBook G4 which is AGP. It appeared to have full acceleration.

Late G5s including the iMac G5 iSight use PCIe graphics. Any PowerMac G4\non-PCIe G5 is able to use PCI GPUs as they do have PCI slots. But it's irrelevant unless you're using the builds in the other thread. This one as stated in other replies, doesn't have networking functionality.

 

[jkchr1s]

I think I might have found something related to DHCP/DNS not working with 10.6.8.

If you hold Cmd+S to boot in single user mode, run the following:

# mount fs as r/w
mount -uw /

# load kextd
launchctl load /System/Library/LaunchDaemons/com.apple.kextd.plist

# load notifyd
launchctl load /System/Library/LaunchDaemons/com.apple.notifyd.plist

# load configd, this brings up networking
launchctl load /System/Library/LaunchDaemons/com.apple.configd.plist

Once you bring up networking, I see this repeated in the console:

SIOPROTOATTACH_IN6: en0 error=17

Bringing the networking up in single user mode helps prevent the noise from everything GUI related starting up and lets you poke around.

I believe IN6 (based on https://github.com/aosm/ppp/blob/master/Helpers/pppd/sys-MacOSX.c#L2331) is related to IPv6 being an issue.

For Hackintoshes, this was typically caused by an incompatible ethernet kext. Basically this would happen when SystemConfiguration.framework or the kernel were incompatible with the kext.

I think there's a difference here between SystemConfiguration.framework and the kext we are using for ethernet. My theory is that the kext expects its configuration in a certain way, and mismatching frameworks/kernels/kexts are conflicting here so that en0/en1 can't be initialized properly.

This is on an iMac G4 1.25GHz.

---

Edit: After digging around kernel docs, I think the issue is that when configd attempts to attach protocols to the network interface, the configuration is invalid for the kernel extension. I believe one of these kernel calls:

• https://developer.apple.com/documentation/kernel/ifnet_attach_proto_param
• https://developer.apple.com/documentation/kernel/ifnet_attach_proto_param_v2
• https://developer.apple.com/documentation/kernel/1397885-ether_add_proto

/System/Library/Extensions/IONetworkingFamily.kext in the 10.6.8 image I'm using seems to be the same version as 10.5.8, and the loaded bundle for my iMac (/System/Library/Extensions/IONetworkingFamily.kext/Contents/Plugins/AppleGMACEthernet.kext) is the same version as 10.5.8 as well.

My theory is that when configd starts and tries attach the protocols, it crashes when it attempts to attach IPv6. At this point I believe it goes in an endless loop trying to configure the interface. Disabling ipv6 via System Preferences doesn't seem to prevent the kernel from trying to attach the protocol to the interface.

I also found an example of a Parallels kext borking the entire networking stack because of the same problem here: https://forum.parallels.com/threads/wpa-and-802-1x-wifi-connectivity-is-broken-10-4-8.5593/ -- so when configd tries to load an invalid protocol, it goes in an endless loop and takes down networking almost entirely.

Some thoughts come to my mind as potential solutions:

• Somehow get 10.6.8 to use the same network configurations as 10.5.8 since we're using the same kext?
• Modify the kernel and ignore IPv6 to see if it makes it further?
• Somehow update the kexts?

 

[jkchr1s]

I made some more progress, and was able to move past the error

SIOPROTOATTACH_IN6: en0 error=17

Since we are using a 10.5.8 kext for IONetworkingFamily.kext, I decided to boot in to 10.5.8 and copy this file to the root of my 10.6.8 partition:

/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

This file is overwritten when the GUI boots up, but not in single user mode So I booted again in single user mode and ran:

mount -uw /

# backup 10.6 plist
cp /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /NetworkInterfaces10.6.plist

# copy my 10.5.8 NetworkInterfaces.plist to 10.6.8
cp /NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

# now try to start services
launchctl load /System/Library/LaunchDaemons/com.apple.kextd.plist
launchctl load /System/Library/LaunchDaemons/com.apple.notifyd.plist
launchctl load /System/Library/LaunchDaemons/com.apple.configd.plist

The good news is that my suspicion that the configuration was invalid was correct, and it didn't error out with the SIOPROTOATTACH_IN6 error! But the bad news is that configd was still crashing repeatedly, and I didn't get a DHCP address.

So I rebooted again into single user mode... but this time, I didn't use launchctl to start configd.

mount -uw /
cp /NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
launchctl load /System/Library/LaunchDaemons/com.apple.kextd.plist
launchctl load /System/Library/LaunchDaemons/com.apple.notifyd.plist

I took a look at the launch daemon plist and determined that it was starting /usr/libexec/configd, so I decided to poke around in that. If you run this command:

/usr/libexec/configd --help

you can see that it supports "-d" to run in foreground (this is nice, we can see the output!) and "-v" enables verbose logging! That's what I want! So, let's start it in the foreground with verbose output!

/usr/libexec/configd -d -v

This gave the output:

Starting thread for plug-ins...
  thread id=0xf0185000
searching for bundles in "."
loading bundles
loading com.apple.print.notification
loading com.apple.SystemConfiguration.PowerManagement
loading com.apple.SystemConfiguration.NetworkIdentification
loading com.apple.SystemConfiguration.Logger (disabled)
loading com.apple.SystemConfiguration.InterfaceNamer
loading com.apple.SystemConfiguration.Bluetooth
loading com.apple.SystemConfiguration.Apple80211
loading com.apple.SystemConfiguration.KernelEventMonitor
loading com.apple.SystemConfiguration.LinkConfiguration
loading com.apple.SystemConfiguration.PreferencesMonitor
loading com.apple.SystemConfiguration.EAPOLController
loading com.apple.SystemConfiguration.IP6Configuration
loading com.apple.SystemConfiguration.IPConfiguration
loading com.apple.SystemConfiguration.IPMonitor
loading com.apple.SystemConfiguration.PPPController
calling bundle load() functions
systemShutdown false
calling bundle start() functions
calling bundle prime() functions
Bus error

So this is in fact loading IPConfiguration now! (which is after IP6Configuration where we were crashing before)... but the Bus error being thrown makes me think it's trying to call something x86.

Not sure where to go from here, but I did make it a step further! I think we need to figure out why configd is crashing, then I think a lot more things will spring to life.

 

[jkchr1s]

I am also fairly confident that configd crashing is what is causing all the /var/log/system.log entries every second.

 

[jkchr1s]

More progress! I found that disabling com.apple.SystemConfiguration.PowerManagement makes configd not crash! It then proceeds to try to assign hostname, DNS, etc!

So, boot in to single user mode and run:

mount -uw /
cp /NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
launchctl load /System/Library/LaunchDaemons/com.apple.kextd.plist
launchctl load /System/Library/LaunchDaemons/com.apple.notifyd.plist
/usr/libexec/configd -v -d -B com.apple.SystemConfiguration.PowerManagement

This, unfortunately, produces some other errors, but configd does not crash! But it gets an error:

IPCConfiguration: IOPMConnectionCreate failed, 0xe00002c9

and also:

InterfaceNamer: timed out waiting for IOKit to quiesce
InterfaceNamer: Busy services :
InterfaceNamer:   PowerMac6,3 [1]

So now, configd is trying to configure the interface, but there's an issue with IOKit.

 

[jkchr1s]

 

[jkchr1s]

So IOPMConnectionCreate appears to be an IPC connection to com.apple.SystemConfiguration.PowerManagement... not sure if we can ignore that one and focus on IOKit?

 

[educovas]

Graphics is working in the image in this thread. It's the mostly vanilla DPs in the other thread that have that problem. I booted it on a PowerBook G4 which is AGP. It appeared to have full acceleration.

Late G5s including the iMac G5 iSight use PCIe graphics. Any PowerMac G4\non-PCIe G5 is able to use PCI GPUs as they do have PCI slots. But it's irrelevant unless you're using the builds in the other thread. This one as stated in other replies, doesn't have networking functionality.

The default 10.6.8 image includes graphics acceleration patches that uses the graphics stack from 10.5.8 but that can cause some incompatibilities with 10.6 software. I a new image for @barracuda156 that uses OpenGL from 10A190 that should have less compatibility problems but only supports GPUs that were supported by 10A190.

 

[educovas]

So IOPMConnectionCreate appears to be an IPC connection to com.apple.SystemConfiguration.PowerManagement... not sure if we can ignore that one and focus on IOKit?

I'll try those steps but using SystemConfiguration from 10.5.8 and check what happens.

 

[jkchr1s]

I'll try those steps but using SystemConfiguration from 10.5.8 and check what happens.

I just had the same thought, replacing the 10.6.8 /System/Library/SystemConfiguration/PowerManagement.bundle with the version from 10.5.8 fixed the IPC error... but still no DHCP.

 

[jkchr1s]

I saw some errors related to ntp not being able to find a DNS server via scutil. I have my configd in verbose mode booted to the GUI, tried setting a static IP address and DNS server, and scutil is blind to any of the settings I make.

I think it's a problem between configd not loading your interface settings. You can verify this by setting a static IP with dns, then run:

scutil --dns

and you don't see your DNS server in there at all. If you run scutil by itself, the network dictionary entries are just blank. There's a lack of communication between System Preferences -> Network and SystemConfiguration.

I also tried using configd from 10A196 (it was a much different binary size). It has some slightly different log outputs, but the result is the same.

TLDR: configd is now properly detecting configuration changes, but SystemConfiguration appears to not reflect any configuration change. I'm wondering if IOKit is still to blame.

---

Edit:Another reason to blame IOKit: Go in System Profiler, then in the left pane go to Software, Extensions. It'll crash, and in the crash logs it gets a Dyld error:

Dyld Error Message:
  Symbol not found: _KXKextManagerCreate
  Referenced from: /System/Library/SystemProfile/SPExtensionsReporter.spreporter/Contents/MacOS/SPExtensionsReporter
  Expected in: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit

Also at boot, all disks get an ioctl error:

disk0s3: ioctl(_IOR,'d',79,4) is unsupported.

 

[educovas]

I saw some errors related to ntp not being able to find a DNS server via scutil. I have my configd in verbose mode booted to the GUI, tried setting a static IP address and DNS server, and scutil is blind to any of the settings I make.

I think it's a problem between configd not loading your interface settings. You can verify this by setting a static IP with dns, then run:

scutil --dns

and you don't see your DNS server in there at all. If you run scutil by itself, the network dictionary entries are just blank. There's a lack of communication between System Preferences -> Network and SystemConfiguration.

I also tried using configd from 10A196 (it was a much different binary size). It has some slightly different log outputs, but the result is the same.

TLDR: configd is now properly detecting configuration changes, but SystemConfiguration appears to not reflect any configuration change. I'm wondering if IOKit is still to blame.

---

Edit:Another reason to blame IOKit: Go in System Profiler, then in the left pane go to Software, Extensions. It'll crash, and in the crash logs it gets a Dyld error:

Dyld Error Message:
  Symbol not found: _KXKextManagerCreate
  Referenced from: /System/Library/SystemProfile/SPExtensionsReporter.spreporter/Contents/MacOS/SPExtensionsReporter
  Expected in: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit

Also at boot, all disks get an ioctl error:

disk0s3: ioctl(_IOR,'d',79,4) is unsupported.

the SPExtensionsReporter crash it not IOKit's fault, it's because I'm using most system profiler panels from 10A190 because it's the latest build with them compiled for ppc.

The ioctl disk error doesn't seem to cause any problems that I've noticed. They did not happen on my 10.6.1 build so I have something to compare with.

 

[barracuda156]

Edit:Another reason to blame IOKit: Go in System Profiler, then in the left pane go to Software, Extensions. It'll crash, and in the crash logs it gets a Dyld error:

Dyld Error Message:
  Symbol not found: _KXKextManagerCreate
  Referenced from: /System/Library/SystemProfile/SPExtensionsReporter.spreporter/Contents/MacOS/SPExtensionsReporter
  Expected in: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit

System Profiler got a bunch of Intel-only stuff inside it (several *Reporters, at least). I had to delete those from 10a190 to get rid of annoying bug in `albafetch` display: it tried to pull in those components, and dyld could not find a suitable image to load (because there is none).

UPD. These had not ppc slices already in 10a190 (and perhaps never had):

 

[educovas]

I've tried to use SystemConfiguration and configd from 10A190 and I saw the same errors so I tried to run those commands on 10A190 and it looks like the power management plugin doesn't work on single user mode because I see no crashes running from the GUI on both 10A190 and 10.6.8. I also see the "timed out waiting for IOKit to quiesce" error so I don't think that's our problem.

 

[educovas]

System Profiler got a bunch of Intel-only stuff inside it (several *Reporters, at least). I had to delete those from 10a190 to get rid of annoying bug in `albafetch` display: it tried to pull in those components, and dyld could not find a suitable image to load (because there is none).

UPD. These had not ppc slices already in 10a190 (and perhaps never had):
View attachment 2459278

those errors should be fixed if you copy them from 10.5.8 or 10A96 but if you don't care deleting is not a problem.