Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Hi all, I have a mac mini 3,1 (early 2009) and have tried running the latest patcher by dosdude1 but I still get the 'NO' symbol about 2/3 of the way when I boot off the external drive. Any ideas?
It may be that the USB hasn't been implemented for the Mini3,1 properly. I'll check and probably update the tool later today.
 
I'll try dosdude's tool on my MacMini3.1 tomarrow, its got a

en1:

Card Type:AirPort Extreme (0x14E4, 0x90)

Firmware Version:Broadcom BCM43xx 1.0 (5.10.131.36.16)

MAC Address:Nope! Not sharing that!

Locale:FCC

Country Code:US

Supported PHY Modes:802.11 a/b/g/n

Supported Channels:1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, 149, 153, 157, 161, 165

Wake On Wireless:Supported

Status:Connected
 
I have an early 2008 (3,1) Mac Pro and it's a thing of beauty! With a couple of SSDs and 16GB of RAM it runs everything I need (primarily Xcode) perfectly. I really don't want to have to buy new hardware, but as someone who is (trying!) to make living as an indie iOS app developer, I know I need to be on the latest OS. You can bet that sooner or later Xcode 8 will need/require macOS Sierra ;)

I'm sorely tempted to use the fantastic work of dosdude1 and others to "hack" my 3,1 Mac Pro into running Sierra. But my (possibly unfounded) fear is that when I submit app bundles for review Apple will detect in some way that it was compiled on an unsupported Mac and take action against me, like cancelling my developer account, etc. :eek:

I guess what I'm asking is, is it illegal to hack Sierra to run on a 3,1 Mac Pro (in which case I won't do it), or is it simply ill-advised/unsupported?
 
I have an early 2008 (3,1) Mac Pro and it's a thing of beauty! With a couple of SSDs and 16GB of RAM it runs everything I need (primarily Xcode) perfectly. I really don't want to have to buy new hardware, but as someone who is (trying!) to make living as an indie iOS app developer, I know I need to be on the latest OS. You can bet that sooner or later Xcode 8 will need/require macOS Sierra ;)

I'm sorely tempted to use the fantastic work of dosdude1 and others to "hack" my 3,1 Mac Pro into running Sierra. But my (possibly unfounded) fear is that when I submit app bundles for review Apple will detect in some way that it was compiled on an unsupported Mac and take action against me, like cancelling my developer account, etc. :eek:

I guess what I'm asking is, is it illegal to hack Sierra to run on a 3,1 Mac Pro (in which case I won't do it), or is it simply ill-advised/unsupported?
Technically yes but mostly ill-advised. You shouldn't worry about your developer account being taken. They won't. Apple really doesn't care about what we, the hackintosh, or jailbreakers do. They'll just tighten security or change things up the next OS.
I get countless web traffic from Cupertino. When I call Apple Support to speak with senior engineers to get iMessage enabled on MacPostFactor'd/OSXE Macs, they're already prepared to do it since they get those calls often now.
The only thing gets taken away would be AppleCare support since obviously they they won't help you with these software related issues; just make you go back to the last supported OS.
 
Technically yes but mostly ill-advised. You shouldn't worry about your developer account being taken. They won't. Apple really doesn't care about what we, the hackintosh, or jailbreakers do. They'll just tighten security or change things up the next OS.
I get countless web traffic from Cupertino. When I call Apple Support to speak with senior engineers to get iMessage enabled on MacPostFactor'd/OSXE Macs, they're already prepared to do it since they get those calls often now.
The only thing gets taken away would be AppleCare support since obviously they they won't help you with these software related issues; just make you go back to the last supported OS.

Thanks a lot for the feedback TMRJIJ, much appreciated.

Interesting that Apple don't appear to care too much about hackintosh or jailbroken machines - I had assumed they'd be pretty down on it!
 
The only thing gets taken away would be AppleCare support since obviously they they won't help you with these software related issues; just make you go back to the last supported OS.
No Mac that is still covered by AppleCare wouldn't support the latest OS anyway, so that's not an issue. If your Mac doesn't support Sierra, you sure as hell don't have AppleCare anymore.
 
@dosdude1: One worry is that people with non-EFI PC graphics cards won't be able to boot into the installer after every OS update, to run the "post-install patch".

What does the "post-install patch" option do? I assume that all it does is replaces "/System/Library/CoreServices/PlatformSupport.plist" with one containing the board-ID + model identifier of more Macs.

In that case, couldn't you instead write a /System/Library/LaunchDaemons script? Those scripts run at boot, before the GUI is even available. It could have a simple action in it like "cp /whatever/PlatformSupport.plist /System/Library/CoreServices/PlatformSupport.plist".

If that's possible, it would mean people can just reboot as usual after OS updates, without worrying about running the patcher each time.

But maybe they check the board-ID before the launchdaemons run... In that case, does anyone have any other ideas for automating the patching process?

EDIT: @parrotgeek1: That's really good stuff! It'll make the initial install even easier, with no need to manually run the post-install script. Do you have any ideas for automating the support-patching at every reboot, as mentioned above?

EDIT2: Idea... Would it be possible to add "no_compat_check" to the NVRAM Boot-Args, to make the system permanently bootable without any PlatformSupport.plist patching anymore? In that case, people would just have to patch the initial installer. Then run "sudo nvram boot-args="something..."", and then just reboot as usual after every update since the system has disabled the platform check. And if the nvram is ever cleared, they just need to boot the OS X installer, go to Terminal, and type "sudo nvram boot-args..." again. Sounds like a slick method IF the "com.apple.Boot.plist" no_compat_check flag can be put inside of nvram.
 
Last edited:
Since my birthday is coming up soon, I just ordered myselve a view mac goodies.
Among my selection is a combo between a 512GB SSD AHCI Flashblade with this awsome heatsink Adapter That has the LED light mod, to lift my Hex into the Jear 2016 of Common Read SSDSpeed 1500/mBsec..





Thanks for this wise review about how consumers are milked by the big companies.
With a family of Macs ranging from PowerPCs with Leopard, white iMacs with Lion (due to the 32bit EFi), MB2008alu (officially abandoned by the Sierra-Upgrade) and a MBP2012 (non retina) I have been loosing enthusiasm to participate the yearly upgrade circus.
A lot of "new" functions are only eye-candy or nice to have.
Looking at Siri or other AI-assistants it's great to see the overall progress into "science-fiction" and I wouldn't mind to have certain features at hand with my old machines, but currently they are not life-changing.
AND: to make them work wouldn't be impossible even with ten year old hardware. It's all about proper coding.
Video editing/playing currently is the only hurdle for old hardware - the rest is only a matter of time to complete any task.
For basic working and entertainment even the "old" macOS (aka MacOS9) on a Clamshell is capable.
Starting at that base line and see how things worked fine even 15y ago (email, browsing, DVD-play, music, office, webDAV, file-sharing, (s)ftp, screensharing etc.) the new macOS is loosing a lot of it's momentum and makes me think twice about any urge to upgrade to the latest OS.
If you see, how clever people make Sierra work on abandoned/'condemned to obsolescence' Macs within a few days that really proofs fraud of Apple against their fellow customers.
(I could understand, if Sierra was a payed upgrade for certain capable old hardware, but the current behavior is really a bad reputation for Apple).
 
Thanks a lot for the feedback TMRJIJ, much appreciated.

Interesting that Apple don't appear to care too much about hackintosh or jailbroken machines - I had assumed they'd be pretty down on it!
They're following us. We're using Sierra on Mac products so we're just info and feedback on how they're going to "improve" Sierra. Given we're on DP1, I expect significant changes as we progress to full production release in the Fall as has been the case in past with Yosemite & El Capitan.

BTW, keep up the good work, guys. I'm hoping to extend my wife's 2009 17" MBP for another couple of years.
 
Last edited:
[USER=1033441]@parrotgeek1: That's really good stuff! It'll make the initial install even easier, with no need to manually run the post-install script. Do you have any ideas for automating the support-patching at every reboot, as mentioned above?[/USER]

with my method it does not modify platformsupport, it modifies com.apple.Boot.plist
which is NOT in /System it is in /Library
meaning it will NEVER be overwritten by an update so you will NEVER need to redo the patch

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel Flags</key>
<string>-no_compat_check mbasd=1</string>
</dict>
</plist>

@dosdude1
 
Last edited:
@parrotgeek1: Holy sh.... :) You're a genius. If that can be extended into a permanent patch, so that we only need to patch the installer disc once, and then we're set forever, then that's a HUGE boon for everyone with non-EFI PC graphics cards. I wasn't looking forward to a future of constantly swapping in the old GT120 card just to redo the patch after every OS update. That thing takes like 30 minutes to swap in and out.

By the way... It seems like the only important flag is "-no_compat_check".

The "mbasd=1" is for MacBook Air SuperDrive support, so only a few people need it.

And why is nvda_drv=1 in your boot.plist? That flag belongs in NVRAM, so that people can change their NVRAM to nv_disable=1 whenever needed, otherwise they'll be stuck in a boot-loop if the OS tries (and fails due to OS X version mismatch) to load the previous OS X version of the nvidia driver after an OS update. The driver must be disabled, the OS updated, the new driver installed, and then the driver enabled again. That's all done via "sudo nvram boot-args". So why put it in boot.plist? Seems like it would interfere with the ability to disable the nvidia driver when necessary.
 
Gonna try install the Dev Preview on my MacBookPro5,3. Gonna try Dosdude's method, will report back. I have the preview on my MacBookPro12,1 but unfortunately that is my work laptop.. and I use the 5,3 at home... Probably should upgrade but it's still going so strong with an SSD and 8GB ram :/

Just a side note, has anyone tried out Firewire on these older macs?
 
i put mbasd=1 because cd drive in my imac9,1 is broken but you can remove it. It won't hurt though

Ah, okay. Yeah it seems harmless to also include that flag. The guy that discovered the flag (http://www.hardturm.ch/luz/2011/10/how-to-make-the-macbook-air-superdrive-work-with-any-mac/) says that it just enables the possibility of loading the SuperDrive driver, and that it changes some USB power management (but only for the USB SuperDrive, not any other ports), so it sounds totally harmless:

Apparently, Apple engineers had the need to test the superdrive with non-MacBookAir computers themselves, so the driver already has an option built-in to work on officially unsupported machines! All you need to do is enable that option, as follows:

The driver recognizes a boot parameter named “mbasd” (Mac Book Air Super Drive), which sets a flag in the driver which both overrides the check for the MBA and also tweaks something related to USB power management (the superdrive probably needs more power than regular USB allows). So just editing /Library/Preferences/SystemConfiguration/com.apple.Boot.plist and inserting the “mbasd=1″ into the “Kernel Flags” does the trick.

And as for nvidia? I see you made a commit on github 3 minutes ago that removed the nvidia driver flag. So now it just says "<string>-no_compat_check mbasd=1</string>". Seems good to me.

How do we know that system updates will never replace the Boot.plist file? Is it just that OS updates can't write to /Library but can only write to /System or what? Or is it just a history of them never touching /Library that "guarantees" it? Just asking, since we may still need a "post-install patch" recovery item in our installers (to re-do the Boot.plist patch), if Boot.plist ever changes.

Either way, wow, great progress! This is looking so slick now that I almost don't mind Apple dropping computer support! ;)

@dosdude1: Check the conversation between me and parrotgeek1, and his Github. There's great news for your patcher. It'll be easier than ever after you implement these changes. It will add automatic post-install patching (no need to reboot and use the menu item you added). And we will never have to re-patch after OS updates. In fact the only reason to keep the "patch" menu item in the installer will be in case something changes Boot.plist, so after these changes people will almost guaranteed never have to touch that menu item, and will only need it for very rare rescue. Hell yes! :) This is awesome!
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.