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....
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.
Nope. It was meThe 1,000th post
I made the 1,000th post on this thread!
unknown special file or file system /Volumes/BigSur.Are you getting "Failed with 66" Error?
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:
Code: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
Code: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.
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.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:
Code:<?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.
UUID-BigSur
folder in the Preboot Volume...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./usr/libexec/ramrod/plugins/ramrod-macos-patchd-plugin.ramrod
(a plugin that's loaded by /usr/libexec/ramrod/ramrod
) on the ramdisk.-[LPAPFSVolume createSnapshot:error:]
-[LPAPFSVolume rootToSnapshot:error:]
mov rax,0x1
ret
auth-root-dmg
and root-dmg
exactly the same -- see imageboot.c)./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.CSR_ALLOW_ANY_RECOVERY_OS
, either with csrutil
or (my personal favorite) the horrifying 0xffffffff boot.efi
patch.RunI can't findUUID-BigSur
folder in the Preboot Volume...
(MBP 15, mid 2010 from macOs Catalina)
diskutil list
and find the Preboot volume that Big Sur uses.diskutil mount diskXsY (disk2s2 for me)
cd /Volumes/Preboot; open . ;ls
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.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 themThey aren't different from other Macs. Look here, #308 sums it up nicely.What are the exact steps to install the beta on a 5,1? Can you give me instructions?
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…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:
In step #3, the snapshot creation and tagging as boot volume is done by
- 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.- 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.
- The ramdisk creates firmlinks and recovery partition, among other things. It snapshots the system volume, seals it, and tags the snapshot for boot.
/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:
And they are both just replaced by "return true":Code:-[LPAPFSVolume createSnapshot:error:] -[LPAPFSVolume rootToSnapshot:error:]
Code: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 treatsauth-root-dmg
androot-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 settingCSR_ALLOW_ANY_RECOVERY_OS
, either withcsrutil
or (my personal favorite) the horrifying 0xffffffffboot.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!
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.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…
I'd expect it to work by simply setting@ASentientBot
it is possible to modify the Recovery partition to work in Big Sur using the keys cmd + R?
-no_compat_check
. If not, it'll be fixable. But not really a priority in my opinion.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…)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
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, PayneLate 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
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 untilkextcache -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.
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
sudo kextcache -i /
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
Do you also have a 2013 imac?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.
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.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
Do you also have a 2013 imac?
Sounds good.Nope, 2012 Mac Mini.