maybe this silliness has gone on long enough. I think we have made our point now.
+1 and I didn't intend to drag things out/off topic. Sorry, folks.
My small on-topic contribution (if this was already posted, sorry):
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.
macOS 10.12 Sierra Unsupported Macs Thread
- Thread starter redheeler
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
+1 and I didn't intend to drag things out/off topic. Sorry, folks.
My small on-topic contribution (if this was already posted, sorry):
Really! You naughty, naughty boy!
Seriously, I think there needs to be a balance on boards such as this. In other words, discuss the serious stuff as we all do, but at the same time, don't be so stiff under the collar that we become easily offended, don't have a sense of humor, can't laugh at ourselves, or can't lighten up and be flexible when necessary.
So here's an odd one: Since creating the new USB installer with the GM (using v 4.0.2 of dosdude's patch tool), none of my encrypted volumes (which includes my startup disk) appear as options for install -- rather, DiskUtility sees them as "unformatted volumes" (meaning I can't manually unlock and mount them via the thumb drive either). Anyone else see this behavior? Thoughts?
You'll have to un-encrypt the volume in which OS is installed. Just go into your system preferences and turn off file vault. Then you will be able to upgrade without issues. Once you're done you can re-enable file vault.
This is abnormal behavior for a macOS install -- the installer has no issue upgrading the OS on officially supported machines with encrypted drives, and this has never occurred in any prior release of macOS. Disk Utility should be able to correctly recognize encrypted volumes and allow for a manual unlock.
Is it possible that this is yet another new security "feature" that Apple is adding to the OS? We've all seen how Apple has been slowly tightening the ship beginning with sandboxing apps, SIP, etc. Maybe it wasn't normal before, but maybe it will be from this point forward. Just guessing here.
I doubt it. I'm fairly sure that I did a little testing of installations with Core Storage.
I did notice that SIP sometimes made it difficult to set boot arguments in NVRAM, and (in the absence of knowledge about El Capitan) I assumed that SIP had always been protective at that level, but today I read something that suggested otherwise.
So how was this achieved?It seems possible to enable upgrades without a patcher at all, and within OS X itself
Before
After
Strange mine is a 9,1 model, I'd assume that other than the wifi card it's mostly the same internals of your second mac.
No, actually the iMac 9,1 is drastically different than the iMac 8,1. It uses a completely different chipset, supports DDR3 RAM, and is an entirely different logic board.
I've had trouble in the past with installing over encrypted drives. Yosemite to Captain comes to mind. Reason why, if I truly feel the need to, I encrypt data partitions only, leaving the OS partition alone. For me at least, performance tanks with file vault on.
I think it's particularly odd because I had no problem when upgrading from El Capitan to Sierra DP1 using the USB drive (which was a full installer using the same post-install patch) on the encrypted volume. This behavior is new as of the GM.
*sadface*
Just one thing comes to mind: if I recall correctly, installations produced by early pre-releases were not recognisable to the Startup Disk pane of System Preferences in e.g. Mavericks.
I don't know when or how that was fixed but (a long shot) if there's something early/outdated at the storage system layer, then maybe that thing is contributory to the anomalies that are now observed.
What that thing might be, I can't guess. fsck_cs(8) does not perform an exhaustive validation, nor is it able to fix many of the inconsistencies that it does detect. Gee, thanks, Apple, and yo closed source storage system, and yo Core Storage man left Apple in 2013, and so on, yo on, roll on Apple File System but yo's truly ain't convinced that dat code will be open sourced. Fasten your seatbelts, ladies and gentlemen …
I would agree that it is odd but turning off file vault and attempting the upgrade worked for me. Once I completed the upgrade I simply re-enabled file vault.
You've got to do a complete install, as the GM isn't available as a software update.
I added the link to the webpage of the patcher tool. http://dosdude1.com/sierrapatch.html
Last edited:
They're exactly the same, 16A319 is just the developer version. The contents of both are identical.
The developer version is 16A320 as well. GM2 was released at the same time as the public beta version.
Yeah. That's the second build of the GM released to developers. But it doesn't really qualify to be called GM2 for the reasons dosdude1 said. Apple are only calling it GM, not GM2.
There may be a GM2 before public release but this isn't it. They only released this build to developers to make it the same as public beta testers.
We know for sure public release won't be build 16A319. It may be 16A320 if there are no more GMs. Although in the past public release had a different build number to even the final GM. So that might happen again too for Sierra.
In any case both 16A319, 16A320 or any subsequent GM will all be able to be updated to the point release betas, wereas DP1-DP8 and PB1-PB7 cannot.
So as long as you have at least build 16A319 you should be OK to update to the first 10.12.1 beta, and all subsequent betas.
Last edited: