According to this post the first GPU available using the videotoolbox (compression and decompression needed for DRM) was the R380. I assume the R9 280X is older and therefore not supported. Please check this...
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 11 Big Sur on Unsupported Macs Thread
- Thread starter dosdude1
- WikiPost WikiPost
- Start date
-
- Tags
- 10.16 macos unsupported
- Sort by reaction score
- Status
The 280 is a year older than the 380. I swapped the HDMI cable and now AppleTV+ content plays on the Mac. Before the cable swap, trailers would play then the DRM content would softly quit. The cable swap had no effect on Airplay. I didn't think it would. I have little to no use for the AppleTV app on a small 1080 screen. It was just a test to rule it out. Getting Airplay working is my main concern.
For now, I'm copying my itunes library to an old spinner, I'll put it in my workshop 3,1 and just use that machine for Airplay.
Possibly you can fine tune OpenCore to work with the other connectors, but this is a wide field and you may consult the Dortania OpenCore docs.
Has anyone figured a way to update Big Sur after a successful install on an older Mac? I successfully updated to Big Sur 11.1 on a late 2013 iMac but now I can't automatically update to the latest version. When I try I get the message that my Mac is up to date?
Thanks for the link. Following the Testing DRM on that page, I pass all three tests on HDMI. As the page says, "If everything works on these tests, you have no need to continue! Otherwise, proceed on."
For the MP 5,1 the OEM wifi does not work after upgrading to BS. I used Martin Lo's fix and the OEM wifi works. Thinking perhaps there could still be an issue with wifi, I installed a USB wifi adapter. No difference. I plan to try ethernet.
Not knowing the inner workings of Airplay, I wonder if there is a "handshake" that occurs similar to HDMI. All of my airplay devices can be pinged by the MP. Weird that I have no issues connecting to the 3rd gen Apple TV, but the 4th and 4K are no go. At this point I don't think the "unsupported" mac has as much of an impact as Big Sur.
Read page 1 of this thread; especially OpenCore Legacy Patcher. What you seek is there!
You have to download the full install image and install via USB in order to do updates.
Haven't been here for a while, reason, no easy update path without the full .x installer.
My time is too precious for dealing with opencore, as soon as I have the cash I will get a
new MX Mac instead of this ever going on update process on a 2012 Mac Mini.
I can deal with a full installer update which takes about 30 minutes.
I also do not want to brick my mac Mini firmware.
As soon as we get a Full Update Installer I will update, not this Opencore headache.
My time is too precious for dealing with opencore, as soon as I have the cash I will get a
new MX Mac instead of this ever going on update process on a 2012 Mac Mini.
I can deal with a full installer update which takes about 30 minutes.
I also do not want to brick my mac Mini firmware.
As soon as we get a Full Update Installer I will update, not this Opencore headache.
Hi there! Just installed macOS Big Sur 11.2.3 on my iMac 14,3 using OpenCore 0.0.18.
Everything seems to be working pretty normally, but I noticed some interesting things:
1. Setup from Within macOS Catalina (After Booting OpenCore)
I installed OC 0.0.18 on a 32GB USB Disk with default settings except for Enabling Verbose and Vaulting. The USB Disk booted normally and I correctly chose "EFI Boot". Before being able to choose the "Install macOS Big Sur" USB Disk, the iMac booted normally to the previously installed and normally used macOS Catalina 10.15.7. I then tried the "Install macOS Big Sur" App on the Applications Folder and it completed the installation (after ~10 reboots) perfectly. I did not need to use the Big Sur USB installer. And I am writing from Big Sur right now.
2. EFI Vaulting (USB vs Internal Disk)
Although Vaulting worked ok within the USB Disk, when I rewrote OpenCore 0.0.18 to my Internal Disk it did not. When booting from the Apple Blade SSD (EFI disk0s1) on my Fusion setup, I got a black screen and had to reboot to the "EFI Boot" on the original USB Disk. That's probably why OC 0.0.18 disables Vaulting by default. After rewriting the Internal Disk with default settings (Expect for Boot Picker) the iMac booted normally from the Internal Disk.
3. Fusion Drive / 3rd Party SSD TRIM Support
As per my signature, I have a Dual SSD Fusion Drive. I replaced the old original 1TB HGST HDD with a Samsung 860 EVO, also 1TB, when I upgrading the i5 with an i7 and "adding" 8GB of RAM. Since Mojave 10.14.6, if I recall correctly, I did not need the "trimforce" command for the SATA Disk any longer after building the Fusion Drive. MacOS enabled TRIM Support for both SSD's automatically. I could beforehand even use the "diskutil reset Fusion" command which was reserved for SSD/HDD duos in previous macOS builds. I notice however that TRIM Support was OFF for the SATA SSD after this OpenCore Big Sur setup. No big deal, just used the "trimforce" command and it rebooted alright with TRIM Support ON this time. Blackmagic Disk Test still shows ~650MB/s R/W speeds, i.e., it's correctly using the PCIe SSD.
Update: I think The TRIM OFF has nothing to do with OC, sorry! I just checked my sister's iMac 5K (18,3) in which I also upgraded the original Fusion Drive Disks, 32GB to 128GB Apple SSPhoton SSD and 1TB HDD to a Samsung 860 EVO (2TB) and it did not have its TRIM ON either after officially updating to Big Sur today. I suppose it's a Big Sur thing then. I know in Mojave (at least using "diskutil reset Fusion") I did not need to use "trimforce". Sincerely do not know about Catalina.
4. BootROM Spoofing
Not a problem but a doubt: I also noticed that in System Information - Hardware, the System Firmware Version changed to 999... I suppose UUID and UDID also changed (but not sure)... Probably those are the core procedures for OC to help me upgrade the unsupported iMac. Chances are this will be a dumb question, sorry, but is this really necessary for Late 2013 iMacs which share the BootROM Version with Big Sur supported Macs? In this case, Version 430.0.0.0.0 with iMacs 14,4/15,1, besides some other MacBookAirs (6,x), MBPros (11,x) and Macmini (7,1). Any advantage or disadvantage? As a side note and as I am on OC 0.0.18, my SMC Version is still shown as 2.17f7, as SMC-Spoofing seems to be a 0.0.19 new feature.
If anyone has any doubt or need any additional info from this particular iMac and setup, please let me know. Cheers!
Everything seems to be working pretty normally, but I noticed some interesting things:
1. Setup from Within macOS Catalina (After Booting OpenCore)
I installed OC 0.0.18 on a 32GB USB Disk with default settings except for Enabling Verbose and Vaulting. The USB Disk booted normally and I correctly chose "EFI Boot". Before being able to choose the "Install macOS Big Sur" USB Disk, the iMac booted normally to the previously installed and normally used macOS Catalina 10.15.7. I then tried the "Install macOS Big Sur" App on the Applications Folder and it completed the installation (after ~10 reboots) perfectly. I did not need to use the Big Sur USB installer. And I am writing from Big Sur right now.
2. EFI Vaulting (USB vs Internal Disk)
Although Vaulting worked ok within the USB Disk, when I rewrote OpenCore 0.0.18 to my Internal Disk it did not. When booting from the Apple Blade SSD (EFI disk0s1) on my Fusion setup, I got a black screen and had to reboot to the "EFI Boot" on the original USB Disk. That's probably why OC 0.0.18 disables Vaulting by default. After rewriting the Internal Disk with default settings (Expect for Boot Picker) the iMac booted normally from the Internal Disk.
3. Fusion Drive / 3rd Party SSD TRIM Support
As per my signature, I have a Dual SSD Fusion Drive. I replaced the old original 1TB HGST HDD with a Samsung 860 EVO, also 1TB, when I upgrading the i5 with an i7 and "adding" 8GB of RAM. Since Mojave 10.14.6, if I recall correctly, I did not need the "trimforce" command for the SATA Disk any longer after building the Fusion Drive. MacOS enabled TRIM Support for both SSD's automatically. I could beforehand even use the "diskutil reset Fusion" command which was reserved for SSD/HDD duos in previous macOS builds. I notice however that TRIM Support was OFF for the SATA SSD after this OpenCore Big Sur setup. No big deal, just used the "trimforce" command and it rebooted alright with TRIM Support ON this time. Blackmagic Disk Test still shows ~650MB/s R/W speeds, i.e., it's correctly using the PCIe SSD.
Update: I think The TRIM OFF has nothing to do with OC, sorry! I just checked my sister's iMac 5K (18,3) in which I also upgraded the original Fusion Drive Disks, 32GB to 128GB Apple SSPhoton SSD and 1TB HDD to a Samsung 860 EVO (2TB) and it did not have its TRIM ON either after officially updating to Big Sur today. I suppose it's a Big Sur thing then. I know in Mojave (at least using "diskutil reset Fusion") I did not need to use "trimforce". Sincerely do not know about Catalina.
4. BootROM Spoofing
Not a problem but a doubt: I also noticed that in System Information - Hardware, the System Firmware Version changed to 999... I suppose UUID and UDID also changed (but not sure)... Probably those are the core procedures for OC to help me upgrade the unsupported iMac. Chances are this will be a dumb question, sorry, but is this really necessary for Late 2013 iMacs which share the BootROM Version with Big Sur supported Macs? In this case, Version 430.0.0.0.0 with iMacs 14,4/15,1, besides some other MacBookAirs (6,x), MBPros (11,x) and Macmini (7,1). Any advantage or disadvantage? As a side note and as I am on OC 0.0.18, my SMC Version is still shown as 2.17f7, as SMC-Spoofing seems to be a 0.0.19 new feature.
If anyone has any doubt or need any additional info from this particular iMac and setup, please let me know. Cheers!
Last edited:
The reason we overwrite the BootROM is simply due to the updates actually not being supported on models not meant to take it. Best case, firmware update fails and you have an extra reboot. Worst case, ROM's overwritten with a BIOS that's incompatible resulting in a very fancy paper weight. (Can still be revived with an SPI flasher, however it's very much not something an average users is willing to do) We unfortunately have a decent sized thread on Github about what happens when firmware updates are applied to incorrect models.
Back with Catalina and older, this was a non-issue as Apple had more robust ROM checks than a simple model and firmware revision. Additionally
run-efi-updater:No was an extra var your could add to avoid this. Big Sur rewrote a lot of firmwareupdater and so will ignore this arg, do minimal ROM checking and result in bricked Macs. And since the updates were done in userspace during the installs/update, it was difficult to actually block them via Lilu (which at the time had basically no userspace support in Big Sur). vit9696 and I also tried RestrictEvents.kext however this result in installs completely stalling as macOS fails for a return call from the updater. So the safest solution was to set a ridiculously high BIOS version.Regarding SMC, currently Apple's implementation of
SMCFlasher is run entirely in EFI, which means it's quite simple to block and has been blocked since the patcher was initially released thanks to BlacklistAppleUpdate. The recent addition of of SMCSpoof.kext was actually due to a misinterpretation of an issue on Github where we believed SMC updates were somehow bypassing OpenCore. This was later found out to be false, however we keep it as it's a nice precaution for when macOS adds some horrid hardcoded logic again breaking our current system.Hope that clarifies a bit,
- Khronokernel
Clarifies a LOT! Thanks!
I thought in the specific case of the iMacs 14,x the BootROM would always be 100% compatible with the iMac 14,4 and also perhaps with the 15,1 one. Often better to play safe anyways. In the next eventual BootROM update it might be necessary to try finding a way to reinstall Catalina to safely update it. Cheers!
Last edited:
Use Ben Sova's Patched Sur 0.1.2. It walks you through updating to BS-11.2.3 via a USB. Choose the Release Update track.
Updated MacOS Big Sur 11.3 Beta4 via OCLP 0.0.9 (OTA Update) to 11.3 Beta5 on Mac Pro 3.1 without issues
Bonjour,
Beta 11.3 beta 5 (20E5217a) ok.
OpenCore 0.6.8 (ad4196a) ok too.
I've searched again for BCM57xx cards and tried some kexts or modifications without success, it's really complicated.😅
Bonne journée.
Beta 11.3 beta 5 (20E5217a) ok.
OpenCore 0.6.8 (ad4196a) ok too.
I've searched again for BCM57xx cards and tried some kexts or modifications without success, it's really complicated.😅
Bonne journée.
Hi! Why do you insist on using FusionDrive, since you are able to open your Mac to replace mechanical HD with a good SSD?
It is true that the speed increases a bit if the FusioDrive is assembled with two SSDs. This, however, only works well if the files and folders of System (Macintosh HD) and of Data (Macintosh HD - Data) are less than the 128GB of the Apple SSD that forms FusionDrive and this SSD is still partially empty.
Otherwise Fusion Drive performs continuous copy&paste operations between the two disks which slow down common use of macOS.
With some examples I explain better how you can notice what I say above. For example: You have a Virtual Machine with Parallels Desktop and Windows or Linux or other systems that takes up around 20GB. When you are not using the virtual machine, FusionDrive moves the 20GB and more to the second disk that makes up FusionDrive, assuming it is a big dimension mechanical HD.
This is the only reason Apple created Fusion Drive and has never used it and no longer uses it in all Macs with a capacious SSD!!!
So if you start Parallels Desktop with Windows or whatever, FusionDrive wastes time transferring the VM to the 128GB SSD first, thinking it's faster and assuming that it's on the slower drive that forms FusionDrive.
The same thing happens for very large files: FusionDrive wastes time transferring them from one drive to the other.
In my case, after disassembling the FusionDrive and replacing the mechanical HD with a good 2TB Crucial MX500 SSD, using the Recovery Utility, before installing Big Sur from USB Key and OpenCore, I called the 2TB SSD "Macintosh HD". Then I called Apple's 128GB SSD "Macintosh SD".
Tests provide read/write rates of around 600MB/sec. for the 2TB SSD.
The Apple SSD of the iMacs late 2013 is faster read (750 Mb/sec.) but slower to write (about 350 Mb sec.)
So! I use the 128GB Apple SSD for Parallels Desktop Windows virtual machine and that way Windows always starts up fast and at the same speed!!!
Likewise, I use the Apple SSD disk to store multimedia files (movies, music, etc.) or files that are very large and that I usually only have to use, but not edit.
So now macOS works consistently very well on "Macintosh HD" if it's a fast SSD and then... F.... Fusion Drive forever!!! (note: I'm jocking
)
Last edited:
Hi. I suppose this is a bit off topic, but here we go... I always liked the Fusion Drive idea and never understood (actually I understand but do not agree or like) why Apple did not allow a more flexible setup, like a 1TB NVMe and 8TB SATA HDD (or SATA SSD) from factory. Each one will have its own opinion on what to say "fuxx" to or not, even if this not very polite, IMHO.Hi! Why do you insist on using FusionDrive, since you are able to open your Mac to replace mechanical HD with a good SSD?
...
So now macOS works consistently very well on "Macintosh HD" if it's a fast SSD and then ... Fuxx Fusion Drive forever!!!
In my particular case, I had the opportunity to buy the 512GB (500GB macOS formatted) Apple/Samsung UAX PCIe 2.0 Original Blade SSD when I realized my iMac 14,3 Motherboard had the empty slot, as do all 14,2 and 14,3 machines btw. And a 1TB SATA SSD is much cheaper than the 1TB Apple Blade SSD. I don't really like spinning rusts nor do I like splitting volumes, as it seems you do (the later), but it's just an opinion, not something right or wrong. I find the use of a single volume more "seamless" if you will, as it is the original setup in every Mac bought from an Apple Store. I find it much more convenient, but again, it's just an opinion.
On my Late 2013 iMac I can always get ~650-750MB/s R/W speeds. Yes, WRITE speeds as well sir, perhaps because its a 512GB and not a 128GB PCIe SSD. So, without the need to choose in which volume to install or drag my Documents and Apps I always get the best performance possible, it's true that not by too much on this 2nd Gen. Blade SSD mind you (Even-thought I have never seen the SATA III interface actually saturating the theoretical 600MB/s limit). In my Sister's case, she got a 2TB SATA SSD way cheaper than the Apple SSD cost and with an additional 128GB NVMe Polaris (Which replaced the 32GB one from factory as we could not yet afford a 512GB or 1TB unit) she achieves ~2,500MB/s Read and ~750MB/s Write Speeds. And the same reasoning of convenience applies here, perhaps even more for someone who is not tech savvy.
As every life choice, there are positives and negatives outcomes. The SSD Endurance problem which I assume you are referring to, I hope is not a practical problem in the coming decades. We are talking about MLC Apple Blades here with HUGE endurances and Samsung SATA TLC SSDs with ESTIMATED Write Endurances of 600-1200TB, not a real problem for us. And I never noticed the iMacs hanging for the FD's background work, earnestly. I suppose the copy & past is continuous only when one is constantly changing Apps and working with huge Files. Not my case generally. Sometimes I use HandBrake to encode H.264 and that's it.
I use VMWare Fusion Player now as I decided that keep paying $50/year to Parallels was not worth it. And as I use my ~50GB Windows 7 VM every other week I assume its always on my 500GB PCIe SSD. If I stop using it for longer, I hope that macOS do whatever the Apple/Hystor Engineers who created the algorithms have designed it to do. I see no problem with that. And differently from what you described, I suppose the copy & paste only needs to be done when you start using a lot of new Apps and large Files more constantly than the last ones. I suppose that if you just have a more or less similar and average use case during days, weeks or months, the files will probably be kept on the same place. For instance, I think music files never come to the PCIe side (unless you are a music producer/editor/etc.). But I might be wrong.
You see, people think in different ways, that's the beauty of choice. Cheers!
Last edited:
Hi Neo_Hunt. First of all, I really want to point out that I was saying "F... FusionDrive" in a joking tone
and that I didn't consider my post too OT as many don't know that Apple's decision not to support our awesome iMac late2013 is based precisely on the presence of FusionDrive which (according to Apple) due to the mechanisms I have tried to describe also based on my experience (as long as I had FusionDrive with a mechanical disk) would slow down Big Sur.Unjustified choice and unjust for me! ... They could have inserted a simple routine during the Installation that recognized iMac with FusionDrive and with SSD and, in this case, allow the installation. If Apple really wanted to speculate on planned obsolescence... he could have invented a paid upgrade at the Genius bars ...
With this in mind... you will better understand my nice outburst "F ... to FusionDrive" that has put us in this unjustified suffering. Although people like you and me appreciate the self-optimization
.As you can see, the topic remains interesting for those who have an iMac 27 Late 2013 and face the "unsupported" issue for the first time.
Also about what you say about not splitting discs, I fully agree with you! We think the same way. In fact, I have not divided the 2TB SSD disk that I put in my iMac after removing the mechanical HD of the FusionDrive, but I have "divided" the FusionDrive in the sense that after having replaced the internal 1TB HD with the 2TB SSD I have found, as an additional internal unit, the 128GB Apple SSD that was part of the Fusion Drive.
So, your initial post is a well of informations that elicited a fantastic response from Khronokernel and made me understand a lot of things.
So thank you very much! You are an intelligent and open person!
Last edited:
Thank you OKonnel for your kind words... And no harm given nor taken.
I already wrote more about this on the appropriate thread on Unsupported Late 2013 21.5" iMacs.
People who certainly know far more about Macs than me firmly believe the Fusion Drives could have been the main reason for this unusual cut. I humbly don't agree (or understand) for a simple reason: Why Apple would still support an unpopular iMac, the Mid 2014 21.5" (14,4) with the exact same specs, if it were for it to pose the same eventual problems? And I say same specs regarding the PCIe Blade SSD, 2.5" 5400rpm HDD and Haswell Architecture.
Maybe Apple did not sell too many of those Mid 2014 21.5" iMacs configured with FDs, that I believe. But then, how come they "throw" Big Sur to their's next very similar iMac, the first 5K one with the same Architecture? The Mid 2014 / Late 2015 5K iMac (15,1) have the same PCIe Blade SSD, same Haswell Architecture and very very similar SATA HDD, only 3.5" and 7200rpm, both CMR though. Even without hard sale numbers on hands, I'd bet the vast majority of those 5K iMacs were with Fusion Drives and not SSDs only. The Late 2014 did not have HDD only options, just the Mid 2015 version did. And I think all those Fusion Drives were with 128GB PCIe SSDs (AHCI), unlike the 24/32GB starting Late 2015. In the later case NVMe though.
And just to be clear, I am not saying there is no FD problem. I just don't think it was the (sole) reason for the cut.
I already wrote more about this on the appropriate thread on Unsupported Late 2013 21.5" iMacs.
People who certainly know far more about Macs than me firmly believe the Fusion Drives could have been the main reason for this unusual cut. I humbly don't agree (or understand) for a simple reason: Why Apple would still support an unpopular iMac, the Mid 2014 21.5" (14,4) with the exact same specs, if it were for it to pose the same eventual problems? And I say same specs regarding the PCIe Blade SSD, 2.5" 5400rpm HDD and Haswell Architecture.
Maybe Apple did not sell too many of those Mid 2014 21.5" iMacs configured with FDs, that I believe. But then, how come they "throw" Big Sur to their's next very similar iMac, the first 5K one with the same Architecture? The Mid 2014 / Late 2015 5K iMac (15,1) have the same PCIe Blade SSD, same Haswell Architecture and very very similar SATA HDD, only 3.5" and 7200rpm, both CMR though. Even without hard sale numbers on hands, I'd bet the vast majority of those 5K iMacs were with Fusion Drives and not SSDs only. The Late 2014 did not have HDD only options, just the Mid 2015 version did. And I think all those Fusion Drives were with 128GB PCIe SSDs (AHCI), unlike the 24/32GB starting Late 2015. In the later case NVMe though.
And just to be clear, I am not saying there is no FD problem. I just don't think it was the (sole) reason for the cut.
Last edited:
Just noticed I now have 1440p and 4K as YouTube options on my 1080p Late 2013 iMac running Big Sur with OpenCore. Up to Catalina it went up to, you guess it, 1080p. Interestingly no frames dropped, and no quality increase, at least that I could've quickly noticed. I know Big Sur's Safari is first revision with 4K YT playback, but is it normal for all Big Sur Macs, including 1080p, 1440p, 1600p and others? Or is it a side effect of the OpenCore 0.0.18 Spoofing as an iMac 5K (15,1)?
Unfortunately I did not test 4K/8K YouTube using Google Chrome on Mojave nor Catalina, sorry. But on the 1080p Late 2013 iMac, 5K 2017 iMac and 1440p 2015 and 2016 12" MacBooks that I readily have access to, I could test (C)hrome and (S)afari for theirs maximum resolutions on Big Sur and with the YT Peru 8K clip. The results:
1080p 2013 iMac OpenCore: C.4K S.4K - 2880p iMac: C.8K S.4K - 1440p MacBooks: C.4K S.1080p
The Retina MacBooks don't even go up to their native resolution of 1440p on Safari.
Unfortunately I did not test 4K/8K YouTube using Google Chrome on Mojave nor Catalina, sorry. But on the 1080p Late 2013 iMac, 5K 2017 iMac and 1440p 2015 and 2016 12" MacBooks that I readily have access to, I could test (C)hrome and (S)afari for theirs maximum resolutions on Big Sur and with the YT Peru 8K clip. The results:
1080p 2013 iMac OpenCore: C.4K S.4K - 2880p iMac: C.8K S.4K - 1440p MacBooks: C.4K S.1080p
The Retina MacBooks don't even go up to their native resolution of 1440p on Safari.
Last edited:
Here is the link for Big Sur 11.3 beta 5 InstallAssistant.pkg @ 12.23GB; build 20E4217a:
http://swcdn.apple.com/content/down...bjtqy5i8cpf7qf6a0wzo6fo9/InstallAssistant.pkg
1. macOS Big Sur Beta 11.3 (20E5217a) - 071-20116 - Added 2021-03-24 18:03:25
Once again, please inform us on successful install using BarryKN's micropatcher 0.5.1 or its derivatives. Thanks.
Last edited:
Fixed version of the installer compatibility check bypass for 11.3 DP5. Probably useful for BenSova, @moosethegoose2213 and anyone else who uses it in their patchers.
(Same as posted to Discord)
(Same as posted to Discord)