search

barrykn / big-sur-micropatcher

A primitive USB patcher for installing macOS Big Sur on unsupported Macs
1.25k stars 174 forks source link

Consider eventually creating an alternate, OpenCore-based patcher #80

Open barrykn opened 4 years ago

barrykn commented 4 years ago

Originally posted by @Ribero in https://github.com/barrykn/big-sur-micropatcher/issues/25#issuecomment-712155738 (but Ribero started their comment by quoting me --just mentioning that for clarity)

@Ribero jackluke (jacklukem on GitHub) has a preconfigured prepackaged OpenCore setup for temporarily spoofing a supported Mac model in order to do delta updates. That may be what @eduard-comanici used.

Thanks a lot.

There's always one point that leaves me wondering: If OpenCore allows my mac to pretend to be a supported model (and assuming my mac has supported hardware components, especially the Wifi card), we could imagine installing BigSur with an original unmodified installer, couldn't we?

If that's the case, some machines like this one, which are very close to officially supported mac hardware, might not need a patch (or at least, just the NVRAM config part) and use BigSur natively just by booting with OpenCore. May be there are other aspects I haven't understood yet (perfs?, reliability?).

Sorry to ask these questions which are probably a bit off topic. Feel free to ask me to delete these comments or hide them if necessary.

barrykn commented 4 years ago

Yes, in principle someone could create a patcher based on OpenCore. OpenCore can even inject kexts without having to install them on the APFS system volume. (That may not be quite as helpful as it would first seem, if the patcher ends up having to install userspace patches as well as kernel extension patches. So far the patcher basically doesn't do that, but I have not yet ruled out the possibility of modifying the WiFi patch to include a userspace component in addition to the current kexts.)

There are enough technical details that would change that I think it needs to be done as a separate patcher. If anyone else wants to do this, go ahead -- I almost certainly won't get around to trying this until well after Big Sur GM. It's possible that an OpenCore-based patcher would work more smoothly with Apple delta updates, so it may be worth trying. In the meantime, reinstalling from patched installer USBs will still be a viable update method for roughly another year, so there's time to try this eventually, there's no need to rush and do it right now.

(When I first created this patcher, OpenCore's kext injection did not yet work with Big Sur, so I did not see much benefit in going with OpenCore at that time.)

daemonspudguy commented 4 years ago

Someone more qualified than me needs to make this.

barrykn commented 4 years ago

For what it's worth, there are instructions here for using OpenCore on unsupported Macs: https://dortania.github.io/OpenCore-For-Legacy-Macs/

barrykn commented 3 years ago

For what it's worth, @MikeBeaton (on issue #70) brought this to my attention: https://forums.macrumors.com/threads/macos-11-big-sur-on-unsupported-macs-thread.2242172/post-29162400

mikebeaton commented 3 years ago

I think the updates made in OpenCore in response to this are already enough to make this not be a problem for any potential OpenCore based Big Sur patcher (i.e. OpenCore 0.6.4 and upwards provides a way to block Apple's new method of EFI flashing). 😊 Links here.

Ribero commented 3 years ago

@MikeBeaton Thanks. Your link point to the one already given by Barry. Is it expected ?

barrykn commented 3 years ago

@Ribero The link I posted is originally from @MikeBeaton, as I mentioned in my comment.

Ribero commented 3 years ago

Ok, got it. Thanks

Ribero commented 3 years ago

Juste tried to install using the guide from https://dortania.github.io/OpenCore-For-Legacy-Macs/ A very well presented and detailed guide. Really.

I tried using the public release of Big Sur.

I was able to build the "custom EFI" partition to boot macOS Big Sur unmodified installer. The mac boots correctly on the installer (trackpad, keyboard, video, wi-fi is working). But when trying to select the drive to install Big Sur I get the infamous message "cannot install on this volume, this computer not compatible with Big Sur" (or something like that).

End of the test.

The only modification I made compared to the tutorial is that I disabled every permanent EFI settings (which include mac hardware spoofing). It should have worked but I haven't yet found what's prevent it from installing...

Will re-do a test next week.

PS : I use a MacBook Pro Retina mid-2012 with an upgraded wifi card (ac)

Ribero commented 3 years ago

Just to give you a quick update:

Once the mac rebooted everything works perfectly:

My understanding:

mikebeaton commented 3 years ago

@Ribero Look online, e.g.: https://www.google.com/search?q=macos+big+sur+brick

It is no longer at all clear that this black screen problem is caused by Big Sur applying the wrong EFI update - and certainly not because of a lethal combination with OpenCore - because Big Sur is also bricking fully supported Macs in the same way!

I have a retina MBP 13" late 2012 and I got exactly the same problem (as you perhaps know, if you followed my links), but after the problem it looks to me as if my EFI was correctly updated - assuming that having a different and new 'no entry' warning screen means that.

The fact that my EFI update took (after disconnecting the battery, as you had to do) combined with the fact that Big Sur is bricking supported Macs in the same way makes me think that it may well not be the wrong firmware that is being applied, but perhaps more something that is broken (in Big Sur, nothing to do with OpenCore) about how they are applying the firmware.

Btw, if you are booting entirely within OpenCore, then as I mentioned above my understanding is that OC 0.6.4 when released will allow you to block this new-style of Mac EFI update.

Ribero commented 3 years ago

Ok thanks for the clarification.

Were you able to use FileVault?

mikebeaton commented 3 years ago

Were you able to use FileVault?

I don't use it and haven't tried, sorry!

ghost commented 3 years ago

My understanding when it comes to all of this is this:

(I have only delta updated once from 11.0.1 to 11.0 Beta 1)

mikebeaton commented 3 years ago

I'd agree 99%, but I'll point out where my current understanding is slightly different:

PS I have a separate 20GB partition set aside for making install media, I've found it's much faster then using a USB drive. 🙂

mikebeaton commented 3 years ago

OpenCore 0.6.6 includes a new setting PlatformInfo/Generic/MaxBIOSVersion which fakes a maxed-out BIOS version and so stops Big Sur updates from ever scheduling a firmware update. This fixes the black-screen 'semi-brick' issue (semi- because you can remove the battery to fix it) on multiple Mac's (including mine, I'm happy to report).

This flag was was added to OpenCore by the people working on the OpenCore Legacy Patcher, which should be pretty relevant here as, I think I've understood correctly, it is a new/separate attempt to do pretty much what this issue is suggesting.

ghost commented 3 years ago

Now that the bricking problem is over, I might make my own GUI Open Core patcher at some point. OTA updates are no longer that much of a plus due to the soon to be released update to my patcher, but the security pluses are good. I still wouldn't say it's a great option though, since if you haven't bought that many devices from Apple recently, you'll run into problem with some iCloud services.

mikebeaton commented 3 years ago

I still wouldn't say it's a great option though, since if you haven't bought that many devices from Apple recently, you'll run into problem with some iCloud services.

What problem? (You mean some iCloud problem that happens when patching with OpenCore but not when patching directly, right?)

ghost commented 3 years ago

Yes. If you are spoofing an invalid serial number, then Apple's services will only let you use them as long as you have made some recent purchases proving that you probably have a real Mac. Patching directly doesn't have this problem because you don't have to spoof a different serial number, so you'd be fine.

mikebeaton commented 3 years ago

Hi Ben. I'm not sure if this issue is the place for me to carry on this discussion - maybe I could open an issue on your own patcher project? (The reason I'm not quite sure it belongs there yet, either, is that I think it's only here that you're mentioning potentially doing an OC version?)

Anyhow, I think you've said that using OC as a patcher will potentially cause iCloud/serial problems, but that using a more traditional patcher would not? Apologies if I've misunderstood that.

But if so, that seems not quite right. I would have thought that any iCloud/serial number problems would depend on Apple vs. non-Apple hardware, not on OC vs non-OC as patcher?

To put it another way, if I boot via OC on my (not officially supported for Big Sur) Mac, then I'm still doing everything on iCloud with my original, correct serial number for the unsupported Mac, as far as I can see (from quickly double-checking on the actual machine). Whereas, of course, if I was using the OS on non-Mac hardware then who knows what the case would be - but not that! So therefore, as I'm saying, if there is an issue here then it looks like a (not that surprising!) issue of Mac vs. non-Mac hardware, but not an issue of OC vs. a more traditional patcher on genuine Mac hardware.

Ribero commented 3 years ago

@MikeBeaton I was sharing this point of view. I thought it was possible to use OC without having to spoof the serial number when running on real mac. But I may be wrong and using OC could require a different serial number that the real one from the mac mother board. Interesting to understand that for me !

ghost commented 3 years ago

@MikeBeaton We can move to a GitHub discussion on my repo (not a GitHub issue because those are annoying, and the number of issues is something I want to keep as low as I can). Plus GitHub discussions are half linear (there's main comments, each comment has a thread that goes with it that is linear like an issue), which makes sense for a discussion like this. I will make this discussion shortly.

Here's a better explanation of what I mean:

Apple logs every single serial number they make, so you can check the coverage of your Mac at any time. That also means they can check if your Mac is real. If you have a serial number of a Mac that was never made, how could the Mac exist? They must be lying to macOS about what computer they do have if the Mac shouldn't exist. Liars get punishments, and that's iCloud services not working. There also needs to be some padding on this, in case their system did mess up and didn't publish the serial number, so if you did buy some real Apple hardware recently they trust you.

What you are saying almost sounds like you aren't spoofing the serial number. If you aren't then this problem wouldn't exist for you, but it confuses me because I thought macOS wouldn't boot if you don't spoof the serial number but spoof the Mac model. Unless you aren't spoofing anything which basically means you are using Open Core for kext injection and not OTA updates.

mikebeaton commented 3 years ago

Okay - I think we're understanding each other now! Ping a link here if you want to carry on discussion elsewhere. (Yes, I think I'm spoofing the Mac model - otherwise I can't get Big Sur - but not the serial number.)

ghost commented 3 years ago

@MikeBeaton Here it is: BenSova/Patched-Sur#215. I pulled out some main comments from this thread, so anyone who wanders there understands what's going on.

mikebeaton commented 3 years ago

@BenSova We were talking at cross-purposes. jackluke's sideloader built on OC, which I have mainly been using, does not fake machine serial number or board id. I prefer this, and it shows that OC itself doesn't necessarily do that. However, OCLP which I am 99% sure you were referring to (and which I would guess most people using OC on unsupported Macs will probably be using, now; and also, which is the project it would probably make most sense to make a GUI for) does currently generate fake ids, with no option not to. Hence potential iCloud account problems!