OpenCore Legacy Patcher позволяет устанавливать macOS Sequoia на старые Intel-машины

How to teach an old Intel Mac new tricks with OpenCore Legacy Patcher Why to do it, and what to watch out for Liam ProvenLiamProvenLINUX AND OPEN SOURCE REPORTER Published HANDS-ON Dortania's OpenCore Legacy Patcher lets you run newer versions of macOS on unsupported Intel Macs. It's handy, but there are a few things to beware of – including macOS Tahoe. OpenCore Legacy Patcher brings Hackintosh techniques to genuine Mac hardware. It's an inspired hack that helps you to install newer versions of Apple macOS on older Macs for which Apple has dropped support in recent versions of macOS. Its co-author, Mykola Grymalyuk, has a fascinating retrospective on its development. We introduced OCLP a few years ago when it was still quite new. Our screenshot then showed version 1.01, but as the project's GitHub page shows, it's now up to version 2.4.1. It does still have one big drawback, though. At present, the newest macOS it can help with is version 15 "Sequoia," whose release we covered back in 2024. In 2025, The Register warned that the forthcoming macOS 26 "Tahoe" would be the last version to have any support for x86 Macs. As we confirmed in September, it supports a mere four x86 Macs. This limited Intel support makes it a significant challenge for the OCLP development team, and nearly a year later, the latest OCLP still does not support Tahoe. REG AD As we've mentioned a few times, the main desktop computer at the Irish Sea wing of Vulture Towers is a 27-inch Retina 5K iMac (late 2015). A couple of years ago, we maxed out this machine with a quad-core i7, 32 GB of RAM, a 1 TB NVMe SSD, and an 8 TB hard disk. It also drives a 27-inch Apple Thunderbolt Display. It's a capable box, but the last supported OS was 2021's macOS 12 "Monterey." As we mentioned last month, this is now too old for the latest Raspberry Pi Imager. It was time. REG AD Getting started with OCLP Alongside OCLP's own documentation, there are several how-to guides out there, such as the iFixit Guide and Greg Gant's 10-step guide. We are not setting out to recreate them, just to point out the stumbling blocks we encountered. Ever since OS X 10.9 "Mavericks" in 2013, macOS has been a free download. You can get it from Apple's App Store, and the company even has a downloads page to help you find older versions. When you download a version of macOS, what you get is a macOS application, called "Install macOS [Codename]." Buried inside this is a little command-line app to create a bootable USB key to reinstall a completely blank machine – for instance, if you fit a new empty SSD. You'll need a fairly big, and ideally fast, key. The recommended minimum is 32 GB. Then you boot off the key and install or upgrade macOS. However, OCLP can also patch a system disk to make it bootable on an unsupported Mac. It will even download various releases of macOS and create the installation USB key for you. The basic way that OCLP works is by creating a standard macOS installer and adding a model-specific OpenCore configuration that bypasses Apple's firmware checks. It may also apply post-install root patches for unsupported hardware. Intel Macs use EFI firmware, which means a small hidden partition containing the EFI bootloader, called the EFI System Partition, or ESP for short. OCLP adds a new entry to this, which shows a special "EFI Boot" entry, as shown in the manual. You must use this to start your newly created key. OCLP does not build a generic modified macOS – it creates a model-specific OpenCore configuration for the Mac on which you run it. There is an option to bypass that and create a custom USB key for a different Mac, but watch out: by default, it creates one for the machine you run it on. For an easier life, you might want to keep a small partition with the last officially supported macOS for your machine – and if you're installing on a blank disk, do that first, before continuing with the process. Even after it's created a custom USB, you can't boot this the normal way. You must use the custom "EFI Boot" entry it creates. You will probably do a lot of rebooting. Don't do this process with a wireless keyboard or mouse, even if they're official Apple ones. Plug in plain old wired USB ones. If it's a PC keyboard, make sure that you know which keys are which in Mac terms. If the instructions say "hold down the Option key," that means Alt; if they say "press Cmd plus [some other key]," that means the Windows key. Our normal Das Keyboard is a USB 3 device, which might be why it doesn't always register when the machine boots, so we needed to use an additional USB 2 as well. REG AD To pick custom boot options, press the Option key (Alt) immediately after the power-on chime, and hold it down. Wait for all the options to appear, and pick EFI Boot, then in the following boot-device picker, choose the installer for your new version. Don't worry: after it's all installed, you don't need to do this every time – only if you change the Startup Disk to an unpatched, supported version, then need to switch back again. Once you've booted your new, customized macOS installer key, you can either do a clean install or upgrade an existing copy of macOS, just like normal. As a fallback measure, we used Bombich's Carbon Copy Cloner to make a backup copy of our Monterey partition on another drive, just in case. This has been an essential Mac utility for decades, and it has a handy trick up its sleeve. Since 10.14 Mojave, macOS has defaulted to Apple's proprietary APFS, and since 10.15 Catalina, it uses a system of container volumes to keep the core OS semi-immutable and safe. For an example, the Eclectic Light Company explains the Sequoia config. This limits how much a macOS volume can be shrunk, but Carbon Copy Cloner can image a volume onto any destination big enough to hold the data, which is very handy. Post-install gotchas Of all our apps, only one didn't work. A couple of years ago, Broadcom made VMware Fusion freeware, but we couldn't update past Fusion 13. With Sequoia, we could update to Fusion 26 – but it didn't work. All VMs had a blank black display. No biggie: we have VirtualBox and the very capable UTM, and both work fine. Our iMac came with a "Fusion drive" – a tiered storage volume combining a tiny 24 GB SSD and a 1 TB HDD. When we upgraded the drives, to keep life simple, we didn't recombine them: it boots from the SSD, and we have a big HFS+ data volume on the hard disk that holds our home directory. Sequoia seems not to expect home directories on HFS+, and various settings would not save. It asked some of the same first-run questions every boot. To get around this, we had to move it back. You can't move the home directory of a logged-in account, so we were glad of the standby "Administrator" user account we created years ago for emergencies. Logging in as "Administrator," we moved all the big data folders out of our home directory (Documents, Downloads, Pictures, Music, Videos, and so on) elsewhere on the hard disk. Then we moved the home directory into its normal location in the boot volume on the SSD. Apple's Library folder is huge, and this process took a long time – about five hours. We didn't really expect it to work, but we created aliases to the data folders in our newly relocated home directory. (Aliases are the macOS equivalent of symbolic links, and to make them by drag-and-drop, hold down Cmd and Opt – the mouse pointer gains a curved arrow emblem, much like Windows shortcut icons.) This worked perfectly, and all of our apps find the folders in their new location. With the whole home directory on SSD, the Mac runs much faster and apps load much quicker too. (The folders don't have their usual icons, which is just cosmetic; also, Apple Music isn't very happy – but we never use it: Foobar 2000 does all we want.) Another snag is that once Sequoia was running smoothly, it started nagging us to upgrade to Tahoe. Don't do this: OCLP doesn't support macOS 26 yet, and while it might boot, USB doesn't work – and no Mac is very useful without a keyboard and mouse. If you do this, just say no to Tahoe. REG AD (If you only need some specific app then an older version of macOS may be all you need. Last year, we Hackintoshed a Dell Latitude to recover some data from a network Time Machine backup, and we found that macOS 11 Big Sur was much quicker than macOS 12 Monterey on that hardware. If an older version will do what you need, it may be easier or lighter-weight, but we decided to just go direct to the latest version on offer.) Back in March, we looked at "Stop Tahoe Upgrade," a tiny macOS policy file that you can install to make the nags go away. This worked perfectly on our M1 MacBook Air, but it didn't on our iMac. Doing some further investigation, we found some additional steps that got it working. You need to manually create two UUIDs and add them to the scripts, then the profile worked on our Intel box. The comments on that article offer an alternative method, by opting into beta updates, but that resulted in us being offered a beta of the update to 15.7.8, which isn't ideal. Why not Linux, or even Windows? We have considered using Boot Camp Assistant to see if we can crowbar Windows 10 LTSC onto this machine, but to be honest, we didn't buy a Mac to run Windows on it. This vulture adopted Windows with 2.01 in 1988. We've done our time, served our sentence, and we don't want to go back. So why not Linux? This is, after all, The Reg FOSS desk. Well, we tried it. The main problem is the iMac's dual displays. Its built-in screen is a massive 5,120 2,880, but the Thunderbolt display is a quarter of the resolution at just 2,560 x 1,440. Running two different dot-pitches currently means using Wayland, and that massively reduces the choice of desktops. First, we tried Pop!_OS 24.04 – we quite like its COSMIC desktop. This normally snappy distro took tens of minutes to boot and was almost totally unresponsive. After some research, we disconnected the Thunderbolt display, and then it ran fine, but we couldn't install it. As we reported back in 2021, the Pop!_OS installer expects an ESP of at least a gigabyte for its systemd-boot setup, while Apple, like Microsoft, typically creates one only a couple of hundred megabytes in size. Next, as a control, we tried Ubuntu 26.04. With the second screen disconnected, Ubuntu worked fine: HiDPI screen, Wi-Fi, power management, everything. We installed it and updated it, and it ran very quickly indeed… until we connected the Thunderbolt screen, when it instantly fell over. It seems that Linux's Thunderbolt support is distinctly lacking. Back in 2022, we reported on the difficulties connecting this display via a USB-C to Thunderbolt adapter. The adapter won't work at all on our company Dell Latitude 5420. Apparently, tenth-generation and later Intel processors can't talk to Thunderbolt 1 anymore. We had more luck on an older Dell, the 2025 FOSS desk testbed XPS 13. That can drive the display through an adapter, but only as a display. The 27-inch Thunderbolt display is also a docking station: it has Firewire, Ethernet, three USB-B 2 ports, a webcam, microphone, and stereo speakers, and can power an Apple laptop over MagSafe too. None of these ports work in Linux. It becomes just a big, hot, external screen. For now, Linux's hardware support just isn't up to making the most of some Apple hardware, even an 11-year-old iMac. After we moved the home directory onto the APFS boot drive, Sequoia runs very well on this machine. Thanks to having the home directory on SSD, it's faster than ever. For a couple of days, it ran hot and slow while Spotlight re-indexed some three terabytes of files, but once that was done, it happily purrs along at 63ºC, the same as before. If you have an older but well-specified Mac, OCLP can give it the gift of life. It doesn't support all models, but it supports most from the last decade and a half. So long as current browsers are available, running a dated version of macOS is no big problem. It's not trivial to install; you want as many backups as you can make, and once running, you must make very sure that it doesn't try to update itself to macOS 26. We hope that the OCLP developers add support for that final x86 release soon. ®