macOS 11 Big Sur on Unsupported Macs Thread

[brandonsierra]

Well its not anymore

 

[Tony.Skid]

Ok, did it! Following the YouTube guide by @GameRoof , on MacBook Pro 9.1 it works well. I've installed on an external M2 SSD connected to USB3, where I had installed also Catalina; I create another partition/volume, then installed; only, I needed to "nvram boot-args="-no_compat_check"" after the first reboot, and after every reboot during installation, I had to choose the Big Sur partition manually. But everything went well, next step, try to make wifi works. Meanwhile, thanks to all of you

BTW, as I wrote earlier, I've installed on an external ssd, via usb, and it's very fast, I really can't understand why (a bit rhetorical question here..) Apple won't let us install it on these Macs....

 

[Macbookprodude]

So, I have the 2012 MacBook Pro 15 inch non-retina - from what I read everything works, even acceleration, can the WiFi kext from Catalina work ?
[automerge]1593289642[/automerge]

Ok, did it! Following the YouTube guide by @GameRoof , on MacBook Pro 9.1 it works well. I've installed on an external M2 SSD connected to USB3, where I had installed also Catalina; I create another partition/volume, then installed; only, I needed to "nvram boot-args="-no_compat_check"" after the first reboot, and after every reboot during installation, I had to choose the Big Sur partition manually. But everything went well, next step, try to make wifi works. Meanwhile, thanks to all of you
View attachment 928469
BTW, as I wrote earlier, I've installed on an external ssd, via usb, and it's very fast, I really can't understand why (a bit rhetorical question here..) Apple won't let us install it on these Macs....

great to see acceleration work. I have the same Mac, however Did you try from Catalina WiFi kext ?So, everything works with the 2012 except WiFi ?

as for 2011 MacBook Pro - I don’t recommend it.

 

[Tony.Skid]

So, I have the 2012 MacBook Pro 15 inch non-retina - from what I read everything works, even acceleration, can the WiFi kext from Catalina work ?
[automerge]1593289642[/automerge]


great to see acceleration work. I have the same Mac, however Did you try from Catalina WiFi kext ?So, everything works with the 2012 except WiFi ?

as for 2011 MacBook Pro - I don’t recommend it.

Yes, everything works "out of the box" except WiFi. But it's possible to make it works, just in a little tricky way. I'm trying right now

 

[Reszej]

The 1,000th post

I made the 1,000th post on this thread!

Nope. It was me

If someone will successfully install Big Sur on MacBookPro 5.4 pm me Please. Im thinking to try install Big Sur with Catalina patcher on new partition

 

[Luki1979]

Are you getting "Failed with 66" Error?

unknown special file or file system /Volumes/BigSur.

 

[quaccOS]

To enable BigSur Wifi use this: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28595200

To enable BigSur speakers and mic use the file attached (stock from my HighSierra installation).

To install both properly follow these steps:

(possibly booting using usbopencoreapfsloader3 and the prelinkedkernel)

open a BigSur terminal and type:

sudo mount -uw / ; killall Finder

open /System/Library/Extensions/

replace from Finder in that path the IO80211Family.kext and AppleHDA.kext

return to terminal continue typing

sudo -s

chmod -R 755 /System/Library/Extensions/

chown -R 0:0 /System/Library/Extensions/

kextcache -i /

(this is required to update the prelinkedkernel)

kmutil install --update-all

(this is required to update the BootKernelExtensions.kc)

kcditto

(this is required to copy both the "kextcache" to the APFS Preboot)

at next reboot both should work on unsupported BigSur Mac.

I prefer the OpenCore Boot Menu much more than Apple's default boot picker. My OpenCoreAPFSloader3 USB is the only way I can boot Big Sur…it blocks that sneaky Telemetry plugin from loading. It would be nice to have personalised drive icons and a dark boot screen by default…but enough about my perfect GUI obsession!

Big Sur system volume would not mount as writable. Failed with error 66 or Unknown special file or file system.



I replaced the kexts in BS Recovery Terminal instead…but still no Wi-Fi, speakers/mic, graphics accel.
Commands executed successfully until kextcache -i / ; kmutil install --update-all; kcditto. I think there were some errors copying the kexts to Preboot. Maybe should've specified kextcache -i /Volumes/Big\ Sur/ instead.

There's nearly 50 lines of output. I just showed it in case the errors are important; could be irrelevant.

 

[niccoloboano]

Breaking news: I discovered a way to boot BigSur without Opencore using the legacy prelinkedkernel instead of the new BootKernelExtensions.kc , here are the steps:

diskutil apfs list to identify your UUID-BigSur unique Preboot Volume string.

diskutil mount Preboot

or mount your BigSur Preboot Volume (it works also from HighSierra, Mojave, Catalina or directly from BigSur)

open /Volumes/Preboot/

check that in your UUID-BigSur folder is present this: /System/Library/PrelinkedKernels/prelinkedkernel

current BigSur beta 1 prelinkedkernel size: 25,7 MB

locate this path : /Volumes/Preboot/UUID-BigSur/System/Library/CoreServices/com.apple.Boot.plist

if you don't have the file then consider to replace it also in this path:

/Volumes/Preboot/UUID-BigSur/Library/Preferences/SystemConfiguration/com.apple.Boot.plist

edit the file exactly this way:

<?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 Cache</key>
    <string>System\Library\PrelinkedKernels\prelinkedkernel</string>
    <key>Kernel Flags</key>
    <string>-no_compat_check amfi_get_out_of_my_way=1</string>
</dict>
</plist>

At next reboot your BigSur installation will use the prelinkedkernel

@ASentientBot and @dosdude1 might find this useful for their BigSur patches.

edit:
The same method could be applied also to USB BigSur Installer, because it is still present also there on

/Volumes/USBInstallerBigSur/System/Library/PrelinkedKernels/prelinkedkernel

so redirecting the /Volumes/USBInstallerBigSur/Library/Preferences/SystemConfiguration/com.apple.Boot.plist

adding to it <key>Kernel Cache</key> with <string>System\Library\PrelinkedKernels\prelinkedkernel</string> should override the default BaseSystem.dmg (ramdisk) BootKernelExtensions.kc but this require more testing, probably the /System/Library/Extensions/ folder should be added also to the USB BigSur Installer for kext matching or BaseSystem.dmg (740 MB) restored to a volume and from there attempt to make a BigSur Patcher.

I can't find UUID-BigSur folder in the Preboot Volume...

(MBP 15, mid 2010 from macOs Catalina)

 

[ASentientBot]

I found a way to disable snapshots at install time. It's kind of impractical, but I'm guessing that this method may eventually be used in automated patchers.

First, a quick high-level recap of the install process:

1. The Install macOS Beta.app extracts its payload (including the installer BaseSystem, ramdisk, OS payload, boot files, and signature stuff) onto the target disk and makes it bootable.
2. The system reboots from that BaseSystem image, which extracts the main OS payload onto the system volume. It also copies the ramdisk to the data volume. It sets the ramdisk as the next boot target.
3. The ramdisk creates firmlinks and recovery partition, among other things. It snapshots the system volume, seals it, and tags the snapshot for boot.

In step #3, the snapshot creation and tagging as boot volume is done by /usr/libexec/ramrod/plugins/ramrod-macos-patchd-plugin.ramrod (a plugin that's loaded by /usr/libexec/ramrod/ramrod) on the ramdisk.

What I've done is patch this plugin to disable snapshot creation/tagging (sealing can already be disabled by a plist key or my Hax2 thingy). The two specific functions I targeted are:

-[LPAPFSVolume createSnapshot:error:]
-[LPAPFSVolume rootToSnapshot:error:]

And they are both just replaced by "return true":

mov rax,0x1
ret

The issue with modifying the ramdisk is that it's verified (based on checksums in a BOM file) by the BaseSystem, prior to copying it in step #2 above. It's verified again by the kernel (side note, this now treats auth-root-dmg and root-dmg exactly the same -- see imageboot.c).

I currently work around the first issue by holding down the alt key after step #2 completes, booting back into another OS, and then replacing the plugin in the ramdisk (/Volumes/* - Data/boot/x86_64SURamDisk.dmg) at this time, after the BaseSystem installer verifies it and right before it is booted. An automated patcher will probably have to tamper with BaseSystem to avoid this.

The second issue can be worked around by setting CSR_ALLOW_ANY_RECOVERY_OS, either with csrutil or (my personal favorite) the horrifying 0xffffffff boot.efi patch.

I know this is all very complex and not fun to do by hand. But personally, it beats having to struggle with unreliable commands to disable/delete snapshots afterwards. It might just be me, but I've still never gotten consistent results. And it's nice to not have to worry about "error 66" at all.

Patcher developers @dosdude1 @parrotgeek1 may find this useful. Or maybe not!

 

[quaccOS]

I can't find UUID-BigSur folder in the Preboot Volume...

(MBP 15, mid 2010 from macOs Catalina)

Run diskutil list and find the Preboot volume that Big Sur uses.
diskutil mount diskXsY (disk2s2 for me) cd /Volumes/Preboot; open . ;ls
It will show a single folder within the Preboot volume that has Big Sur's UUID (universally unique identifier) as its name.
If you run diskutil apfs list, you will see the UUID corresponds to Big Sur's data volume rather than the system one – I think @jackluke pointed that out.

The UUID itself is not that important…you just need to access the folder to edit the Boot plists.
Finder > View > Show Path Bar makes navigating easier. You can then conveniently drag the path name over to Terminal. Any hidden folders, just hit Shift+Command+Dot to show or hide them

 

[webg3]

@ASentientBot

it is possible to modify the Recovery partition to work in Big Sur using the keys cmd + R?

 

[Fangio]

What are the exact steps to install the beta on a 5,1? Can you give me instructions?

They aren't different from other Macs. Look here, #308 sums it up nicely.

 

[quaccOS]

I found a way to disable snapshots at install time. It's kind of impractical, but I'm guessing that this method may eventually be used in automated patchers.

First, a quick high-level recap of the install process:

1. The Install macOS Beta.app extracts its payload (including the installer BaseSystem, ramdisk, OS payload, boot files, and signature stuff) onto the target disk and makes it bootable.
2. The system reboots from that BaseSystem image, which extracts the main OS payload onto the system volume. It also copies the ramdisk to the data volume. It sets the ramdisk as the next boot target.
3. The ramdisk creates firmlinks and recovery partition, among other things. It snapshots the system volume, seals it, and tags the snapshot for boot.

In step #3, the snapshot creation and tagging as boot volume is done by /usr/libexec/ramrod/plugins/ramrod-macos-patchd-plugin.ramrod (a plugin that's loaded by /usr/libexec/ramrod/ramrod) on the ramdisk.

What I've done is patch this plugin to disable snapshot creation/tagging (sealing can already be disabled by a plist key or my Hax2 thingy). The two specific functions I targeted are:

-[LPAPFSVolume createSnapshot:error:]
-[LPAPFSVolume rootToSnapshot:error:]

And they are both just replaced by "return true":

mov rax,0x1
ret

The issue with modifying the ramdisk is that it's verified (based on checksums in a BOM file) by the BaseSystem, prior to copying it in step #2 above. It's verified again by the kernel (side note, this now treats auth-root-dmg and root-dmg exactly the same -- see imageboot.c).

I currently work around the first issue by holding down the alt key after step #2 completes, booting back into another OS, and then replacing the plugin in the ramdisk (/Volumes/* - Data/boot/x86_64SURamDisk.dmg) at this time, after the BaseSystem installer verifies it and right before it is booted. An automated patcher will probably have to tamper with BaseSystem to avoid this.

The second issue can be worked around by setting CSR_ALLOW_ANY_RECOVERY_OS, either with csrutil or (my personal favorite) the horrifying 0xffffffff boot.efi patch.

I know this is all very complex and not fun to do by hand. But personally, it beats having to struggle with unreliable commands to disable/delete snapshots afterwards. It might just be me, but I've still never gotten consistent results. And it's nice to not have to worry about "error 66" at all.

Patcher developers @dosdude1 @parrotgeek1 may find this useful. Or maybe not!

I've been seeing the word ramdisk a lot, and I'm just going to assume they mean the NVRAM/PRAM – like a block of RAM that acts as if it were secondary storage rather than being Random Access Memory…

 

[ASentientBot]

I've been seeing the word ramdisk a lot, and I'm just going to assume they mean the NVRAM/PRAM – like a block of RAM that acts as if it were secondary storage rather than being Random Access Memory…

Incorrect. Ramdisk refers to a disk image that's loaded into memory and then mounted and used (in this case, booted from) as if it's regular storage.

And if you read my comment, it's clear I wasn't talking about NVRAM
[automerge]1593292107[/automerge]

@ASentientBot

it is possible to modify the Recovery partition to work in Big Sur using the keys cmd + R?

I'd expect it to work by simply setting -no_compat_check. If not, it'll be fixable. But not really a priority in my opinion.

 

[quaccOS]

Incorrect. Ramdisk refers to a disk image that's loaded into memory and then mounted and used (in this case, booted from) as if it's regular storage.

And if you read my comment, it's clear I wasn't talking about NVRAM

If you google "ramdisk", you'll see the word is quite ambiguous. I understood it as any block of RAM that acts like secondary storage rather than primary, e.g. to store certain preferences to access them quickly (NVRAM stores time zone, chosen startup disk, kernel panic info etc…)

Now, I'm understanding that it's a DMG…but it can't be all loaded into memory. I've mounted disk images bigger than my 8 GB of RAM installed. Maybe it uses virtual memory (VM) then – kinda like Linux swap space?
If you can't tell, I'm still learning – and definitely learning at home for now.
Looks like my 1st year of college CS will be on Zoom. Lol

 

[Payne Mononymous Bachman]

Late 2013 21" iMac.
Everything works... WiFi, my third party SSD (Samsung Evo 860) and no issues with HW acceleration for the graphics.

View attachment 928187

Is there anyway when you get a chance if you can explain or post the links of the steps that you used to get this working. Thanks, Payne

 

[jackluke]

It would be nice to have personalised drive icons and a dark boot screen by default

Big Sur system volume would not mount as writable.

Commands executed successfully until kextcache -i / ; kmutil install --update-all; kcditto. I think there were some errors copying the kexts to Preboot.

There's nearly 50 lines of output. I just showed it in case the errors are important; could be irrelevant.

I already included in my usbopencore setup a similar apple startup gui (but I prefer to use a text menu to differentiate), to enable it, from Catalina (or BigSur) open terminal and type:

diskutil list

locate your USB external EFI on diskX (where you installed usbopencore)

sudo -s
diskutil mount diskXsY

cd /Volumes/EFI/EFI/OC/Drivers/
mv OpenCanopy.efi OpenCanopy2.efi

diskutil unmount EFI

About the Wifi and Sound kext, those kmutil output are normal but they are valid for BootKernelExtensions.kc, instead for usbopencore you need to rebuild the "kextcache" for prelinkedkernel, this currently can only been done from BigSur normal booting, but after you replaced those kext from USB BigSur recovery, you could try to boot from BigSur (normal booting) terminal: sudo kextcache -i /

 

[Payne Mononymous Bachman]

Any Updates on getting WiFi cards to work with Big Sur? I would also like to take a moment to thank everyone one for working hard to get a fully working and stable Big Sur Patcher.

 

[justperry]

Is there anyway when you get a chance if you can explain or post the links of the steps that you used to get this working. Thanks, Payne

Second that, I want my wifi back again, not going to read/search 41 pages, if someone figured it out then take the time to update Post number one, it's A Wikipost, anyone with the right permissions can edit the post.

Edit (a minute later) I forgot to say...please AND Thank you.

 

[Payne Mononymous Bachman]

Second that, I want my wifi back again, not going to read/search 41 pages, if someone figured it out then take the time to update Post number one, it's A Wikipost, anyone with the right permissions can edit the post.

Do you also have a 2013 imac?

 

[ASentientBot]

If you google "ramdisk", you'll see the word is quite ambiguous. I understood it as any block of RAM that acts like secondary storage rather than primary, e.g. to store certain preferences to access them quickly (NVRAM stores time zone, chosen startup disk, kernel panic info etc…)

Now, I'm understanding that it's a DMG…but it can't be all loaded into memory. I've mounted disk images bigger than my 8 GB of RAM installed. Maybe it uses virtual memory (VM) then – kinda like Linux swap space?
If you can't tell, I'm still learning – and definitely learning at home for now.
Looks like my 1st year of college CS will be on Zoom. Lol

You're right, it is used for a wider range of things than I realized. I still don't think NVRAM usually counts since it's nonvolatile and not really a "disk", but I see how you could've interpreted it to refer to that.

The ramdisk used for the OS install is only about 200 MB, and as far as I know, it's entirely loaded into memory. But you're right, just mounting a DMG won't load the whole thing into RAM. It'll just seek for data within the file as it's needed.

Good luck with your first year! I just finished mine. Not looking forward to the fully-online setup either, but we'll survive. Maybe second semester will be in person at least? ?

 

[Payne Mononymous Bachman]

@ ASentientBot are you guys in high school or college? I know it may be a weird question. Just wondering because I just graduated from college.

 

[brandonsierra]

Hi!

 

[justperry]

Do you also have a 2013 imac?

Nope, 2012 Mac Mini.

 

[Payne Mononymous Bachman]

Nope, 2012 Mac Mini.

Sounds good.
[automerge]1593297233[/automerge]
I wonder since Apple is switching to their own processors if they will be starting to ditch AMD Graphics in their desktops and iMacs?