macOS 11 Big Sur on Unsupported Macs Thread

[guerrabadboy]

Hi, thanks for your reply. I solved this issue, which apparently depended on Kaspersky Internet Security (as soon as I uninstalled it, I was able to connect to the Internet again). I am now facing a new problem: when I reboot into the Big Sur installer in order to fix the wifi (step 9 of the procedure), the installer doesn't accept my password and I have to quit. I'm 100% sure that the password is correct (when I reboot into the system I can login with no issue)... any hints?

I have the same problem as you, I can't fix the wifi because of that. Please help

 

[nandor690]

I managed to install beta 3 on my macpro 5,1 (flashed 4,1 mid 2009) using parrot geeks method. Didn’t have to use any terminal commands and just let the installer do it’s own thing. Worked a dream. Everything works as it should.

Does handoff and continuity work for you?

 

[macsba]

Wow! We're up to 100 pages in this thread. Congrats all!

 

[Barry K. Nathan]

Hi, thanks for your reply. I solved this issue, which apparently depended on Kaspersky Internet Security (as soon as I uninstalled it, I was able to connect to the Internet again). I am now facing a new problem: when I reboot into the Big Sur installer in order to fix the wifi (step 9 of the procedure), the installer doesn't accept my password and I have to quit. I'm 100% sure that the password is correct (when I reboot into the system I can login with no issue)... any hints?

After I wrote the rest of this post, I remembered that an upcoming version of my patcher (probably v0.0.18, so probably not the next release but the one after, hopefully later this week) is going to change step 9 so you don't have to boot from the installer USB again. That might end up solving your problem. However, I'll still leave the rest of the post here, because I'm still curious about what's going wrong.


I think I need some more information: Are you using FileVault by any chance? If so, on your Big Sur installation or on another macOS installation? (Or both?) Looking at your previous posts, it appears that Big Sur beta 3 was upgraded from beta 2. Was beta 2 a fresh installation or was it an upgrade from an earlier version of macOS?

Without FileVault, I haven't seen the installer ask for a password.

I just realized, if you're using a different password on a previous (pre-Big Sur) installation of macOS, that might be the password that's needed.

A photo of the password prompt might give me a better idea of what's going on -- but if it might reveal anything private, then don't bother.

 

[Barry K. Nathan]

I wonder if the problem with LegacyUSB isn't just the signing issue. Are we sure that Apple allows third-party kext to reside in S/L/E and hasn't banished them to L/E without Apple's own signature applied? The following suggests that might be the case...

Installing a Custom Kernel Extension | Apple Developer Documentation

Install kernel extensions using a custom installer package, and help users understand the installation process.

developer.apple.com

If so, that would mean that

1) LegacyUSBInjector.kext would have to go into L/E and thus be put in the auxilary kc rather than BootKernelExtensions.kc. I could imagine that would foul up getting the changes applied to IOUSBFamily.kext since those two kc's load at different times.

2) If the signatures are being required, it might also explain why patching the Info.plist files in IOUSBFamily.kext doesn't provide usable legacy usb as that would spoil the current signature on IOUSBFamily.kext.

ps Have you tried booting your kc with broken LegacyUSB in 'Cmd-S; exit'? Does that bring the legacy usb support back?

The signing requirement is at least partially bypassed by disabling SIP. (To take an example that's unrelated to running new macOS releases on old Macs, that's why you disable SIP when compiling VirtualBox from source code -- so the unsigned Kexts will load.)

If the signing issue (by itself) was the problem, then ASentientBot's patched NVDAResmanTesla.kext shouldn't work -- but it does, as shown in the screenshot below. (Note that the machine is called "Barry's MacBook Pro" because I installed Big Sur beta 3 onto a USB SSD using my MacBookPro8,1 before I applied the patches and brought the USB SSD over to my MacBook6,1. Also note that even though there's a signing error and it says "Loadable: No", it also says "Loaded: Yes" because disabling SIP bypasses the signature check.)

 

[jackluke]

Just an update on Big Sur Beta 3 installation on MacBook Pro 5,2 (Penryn C2D). Most of the "fixes" used to install Big Sur beta3 were courtesy of jackluke and Asentientbot, but there are many other individuals involved in this endeavor.

Reinstalled Big Sur beta 3 on the internal drive of my machine (from separate partition on same internal drive). I applied all the necessary modification, as noted in this thread, with near-total success.

WiFi is fully functional
Sound and microphone are functional.
Frame buffer appears to be active.
"light" mode works; all icons on right side of menu-bar are visible.

However, the modified NVDA drivers do not appear to load; there is no brightness control, nor do function keys allow for change in light intensity. The display control panel has a generic "look" and no visible controls.

I tried to manually to insert a modified NVDAResmanTesla.kext directly into extension folder, using jackluke's method, as described in post 1781 (page 72), but on reboot a kernel panic occurred; trace back showed the NVDAResmanTesla to be the part of the problem. I had to reinstall the Big Sur 3.

For non-Metal Nvidia Tesla on BigSur you should replace this package of kext, not only the patched ASentientBot NVDAResmanTesla, in the package is also included the patched ASentientBot GeForceTesla, but it is not included the GLDriver because too big to upload, anyway "brightness control" should work without it, only framebuffer video is required.
[automerge]1595919355[/automerge]

I decided to give Hax3 a try. I went into the Source subdirectory, opened HaxWrapper.applescript in the Script Editor to have the line that launches the bundle as...

set libName to "HaxLib.dylib"
set targetBundle to "Install macOS Big Sur Beta.app"

to crash(message)
    display dialog message with icon stop with title "Error" buttons {"Stop"} default button 1 cancel button 1
end crash
to warn(message)
    display dialog message with icon caution with title "Warning" buttons {"Stop", "Continue"} default button 1 cancel button 1
end warn

do shell script "csrutil status"
if result does not contain "disabled" then
    warn("SIP seems to be enabled.")
end if

set bootArgs to (do shell script "nvram boot-args")
if bootArgs does not contain "-no_compat_check" then
    warn("-no_compat_check doesn't seem to be set.")
end if

if bootArgs does not contains "amfi_get_out_of_my_way" then
    warn("amfi_get_out_of_my_way doesn't seem to be set.")
end if

try
    do shell script "open -b " & targetBundle
on error
    crash("Can't open the installer app.")

However, when I execute Build.tool and copy the resulting Hax3.app into the Applications directory along side the full installer for Beta 3 named "Install macOS Big Sur Beta", clicking on the Hex3 app produces an error "Can't open the installer app.". What am I missing here?

Update: It appears that using...

set targetBundle to "Install\\ macOS\\ Big\\ Sur\\ Beta.app"

and

do shell script "open -a " & targetBundle

works. Still waiting for the install to complete to confirm the resulting volume is unsealed.

Having an unsealed system volume doesn't imply that you also won't have a snapshot booting (so after installation you still can't use "sudo mount -uw /"), but after using ASentientBot Hax3.app (or HaxLib.dylib) this should work: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28701959

 

[ggyenyen]

Does handoff and continuity work for you?

Yes handoff works perfectly too. I forgot to mention I took out my nvme drive (which has my catalina OS on, my main OS) formatted an ssd and put that in one of the drive bays just to test to see if BS would work. First I tried the Hax.dylib method. BS booted up but with a few glitches and very unstable. So I thought I would try the parrotgeek way. Once again BS booted up with the same glitches. Then I realised it was BS screwing up it was my AVG antivirus that was screwing things up. Once I removed that BS started working as it should. No crashes, slowdowns or anything else. I am going to see if I can just update is form software update when beta 4 is released before I commit to upgrading it to my nvme drive. Will keep you posted.

 

[Vyzantion]

One quick question. It was hard for me to follow 100% this thread since inception, but I have tried at least to browse it regularly. I remeber that someone managed to get Big Sur running on a Core 2 Duo CPU. Is this true? I have a Core 2 Duo CPU on this machine and this makes the difference, if I try to use to get Big Sur going on this or I get an uppgrade or I give up on macOS for Linux for good.

 

[GSXB]

No just run it in terminal if you made the usb using the parrot geek method

Will try later and post the results

 

[jackluke]

It's that thing again where all the frameworks are lumped into a single dyld cache. (Even for people who have seen this blog post already, there have been some links added to it, including one earlier today, so it may be worth looking at again.)

https://mjtsai.com/blog/2020/06/26/reverse-engineering-macos-11-0/

and @ASentientBot this (even if compiled for HighSierra) could work for BigBigSur 2,23 GB /Volumes/BigSurSystemLabel/System/Library/dyld/dyld_shared_cache_x86_64 :

https://github.com/macmade/dyld_cache_extract

I just compared it with /Volumes/Mojave/private/var/db/dyld/dyld_shared_cache_x86_64 size is 1,45 GB

with Catalina the path /Volumes/Catalina Data/private/var/db/dyld/dyld_shared_cache_x86_64 size is 2,11 GB

so if I understood, apple macOS embedded anyway the frameworks and privateframeworks exec in its dyld_shared_cache_x86_64

so I guess if replace the BigSur frameworks (and privateframeworks) aliases with some binary exec (for example SiriUI and CoreBrightness), using update_dyld_shared_cache -debug -force -root / from single user mode, this could add the patched frameworks exec.

 

[pfandung]

After I wrote the rest of this post, I remembered that an upcoming version of my patcher (probably v0.0.18, so probably not the next release but the one after, hopefully later this week) is going to change step 9 so you don't have to boot from the installer USB again. That might end up solving your problem. However, I'll still leave the rest of the post here, because I'm still curious about what's going wrong.


I think I need some more information: Are you using FileVault by any chance? If so, on your Big Sur installation or on another macOS installation? (Or both?) Looking at your previous posts, it appears that Big Sur beta 3 was upgraded from beta 2. Was beta 2 a fresh installation or was it an upgrade from an earlier version of macOS?

Without FileVault, I haven't seen the installer ask for a password.

I just realized, if you're using a different password on a previous (pre-Big Sur) installation of macOS, that might be the password that's needed.

A photo of the password prompt might give me a better idea of what's going on -- but if it might reveal anything private, then don't bother.

Hi, yes, my disk is encrypted with FileVault. However, it was encrypted when I (a) installed Big Sur Beta 1 on top of Catalina; (b) upgraded from Beta 1 to Beta 2, and from Beta 2 to Beta 3 (which I am currently using): in those cases, I had no issue at all when I was requested to enter my password (BTW, I used my login password). The problem has shown up only three days ago, when after a successful upgrade to Beta 3 I rebooted into the installer to perform step 9 in order to fix the WiFi. It's really strange. Attached are two photos of my Retina MBP with password request. Thanks! P.S.: I know, my MBP has the StainGate!

 

[ggyenyen]

Hi, yes, my disk is encrypted with FileVault. However, it was encrypted when I (a) installed Big Sur Beta 1 on top of Catalina; (b) upgraded from Beta 1 to Beta 2, and from Beta 2 to Beta 3 (which I am currently using): in those cases, I had to issue at all when I was requested to enter my password (BTW, I used my login password). The problem has shown up only three days ago, when after a successful upgrade to Beta 3 I rebooted into the installer to perform step 9 in order to fix the WiFi. It's really strange. Attached are two photos of my Retina MBP with password request. Thanks! P.S.: I know, my MBP has the StainGate!

Hi did you install the updates through the "about this mac" software update? or did you have to do a fresh install for every beta?

 

[pfandung]

Hi did you install the updates through the "about this mac" software update? or did you have to do a fresh install for every beta?

No, I didn't make neither a fresh install, nor an update via "Software Update". I upgraded from Catalina to Beta 1 - and then from Beta 1 to Beta 2 - following Parrot Geek's procedure. Finally I upgraded from Beta 2 to Beta 3 following Barry K. Nathan's method.

 

[karesake]

Hey @dosdude1
Will you also release a patcher?

 

[jackluke]

and @ASentientBot this (even if compiled for HighSierra) could work for BigBigSur 2,23 GB /Volumes/BigSurSystemLabel/System/Library/dyld/dyld_shared_cache_x86_64 :

https://github.com/macmade/dyld_cache_extract

I just compared it with /Volumes/Mojave/private/var/db/dyld/dyld_shared_cache_x86_64 size is 1,45 GB

with Catalina the path /Volumes/Catalina Data/private/var/db/dyld/dyld_shared_cache_x86_64 size is 2,11 GB

so if I understood, apple macOS embedded anyway the frameworks and privateframeworks exec in its dyld_shared_cache_x86_64

so I guess if replace the BigSur frameworks (and privateframeworks) aliases with some binary exec (for example SiriUI and CoreBrightness), using update_dyld_shared_cache -debug -force -root / from single user mode, this could add the patched frameworks exec.

It worked, keeping the stock BigSur "dyld_shared_cache_x86_64", I simply replaced the BigSur Privateframeworks CoreBrightness.framework (that essentially is only an alias) with the one from Catalina 10.15.6 and now Night Shift is working on an unsupported MacBook7,1 (@ASentientBot you could test this attached it should work).

Note: the non-metal videoframebuffer drivers are required, and to use any patched framework you need a disabled library validation, you could use nvram boot-args="-no_compat_check amfi_get_out_of_my_way=1"
(this is already included in my prelinkedkernel fix and USBopencore so there is no need to add it on nvram)

otherwise if you use the stock BootKernelExtensions.kc you can use this ASentientBot method (before replace the framework):

sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true

while "sudo mount -uw /" is easier but not necessary, is possible to replace the patched framework from another macOS and then make a new snapshot with the replaced framework.

(@hvds you could test it should work also on your MacBookPro5,2 , just replace the framework in ~/Snapshot/System/Library/PrivateFrameworks/ with the same method you used for replacing AppleHDA.kext)

I attach two proof pictures and the CoreBrightness that I patched with pikeralpha method.

This attached should allow Night Shift on any BigSur unsupported mac, use it from BigSur beta 3 or later (because apple from this version changed the IOKit from 10.16 to 11.0 ).

 

[Barry K. Nathan]

I've now released v0.0.17 of my patcher. Quoting the release notes:

The highlight of this release: If Big Sur developer beta 3 made Ethernet stop working on your Mac, then patch your USB stick with this version of the patcher, repeat step 9, and Ethernet should work again.
Changes in more detail:

• Many typos and errors in the README have been corrected. The biggest corrections are to instructions for installing and patching for 2009-2010 Macs (such as Late 2009/Mid 2010 white MacBooks). For these Macs, you still have to install on a newer Mac then move the (internal or external) hard drive/SSD to the older Mac, but now the instructions are sufficiently complete that they should actually work.
• Many 2011 and older Macs with Big Sur developer beta 3 have nonfunctioning Ethernet, so on these machines, AppleBCM5701Ethernet.kext will now be replaced with the version from macOS Catalina 10.15.6. (If you forget to use the --2011 option to patch-kexts.sh on 2011 Macs, this fix will not work.) This fixed the Ethernet problems on my MacBookPro8,1, so I think it should fix the problems on other unsupported Macs. I'm not yet sure if this is a temporary bug or a compatibility break that will require patching over the long term, so right now the patch is only applied to Big Sur developer beta 3. If you have a Mac that lost Ethernet after upgrading to Big Sur developer beta 3, and this version of the patcher does not fix it for you, please let me know.
• The --all option in patch-kexts.sh now installs the GeForce 9400M/320M driver kexts. This should fix sleep and display brightness control on the 2009 13" MacBook Pro (APFS ROM patch required), 2010 13" MacBook Pro, and Late 2009/Mid 2010 white MacBooks (tested on a Late 2009 white MacBook). Thanks to ASentientBot for the NVDAResmanTesla.kext patch which makes this possible.

As the release notes say, if you have a Mac where Ethernet stopped working with Big Sur beta 3, then patch your installer USB with this version of the patcher, redo step 9, and Ethernet should work again. (If it doesn't fix Ethernet for you, let me know!)

GitHub - barrykn/big-sur-micropatcher: A primitive USB patcher for installing macOS Big Sur on unsupported Macs

A primitive USB patcher for installing macOS Big Sur on unsupported Macs - barrykn/big-sur-micropatcher

github.com

 

[jhowarth]

The signing requirement is at least partially bypassed by disabling SIP. (To take an example that's unrelated to running new macOS releases on old Macs, that's why you disable SIP when compiling VirtualBox from source code -- so the unsigned Kexts will load.)

If the signing issue (by itself) was the problem, then ASentientBot's patched NVDAResmanTesla.kext shouldn't work -- but it does, as shown in the screenshot below. (Note that the machine is called "Barry's MacBook Pro" because I installed Big Sur beta 3 onto a USB SSD using my MacBookPro8,1 before I applied the patches and brought the USB SSD over to my MacBook6,1. Also note that even though there's a signing error and it says "Loadable: No", it also says "Loaded: Yes" because disabling SIP bypasses the signature check.)

View attachment 938140

If we are talking about how kext are handled by kc's, I still wonder if the auxilary kc has a looser requirement than the boot and system ones. If Apple were trying to maintain tighter control on their own system kext, it would make sense to have that extra layer of strictness for those and force all the third party kext over into L/E.

 

[Barry K. Nathan]

Hi, yes, my disk is encrypted with FileVault. However, it was encrypted when I (a) installed Big Sur Beta 1 on top of Catalina; (b) upgraded from Beta 1 to Beta 2, and from Beta 2 to Beta 3 (which I am currently using): in those cases, I had to issue at all when I was requested to enter my password (BTW, I used my login password). The problem has shown up only three days ago, when after a successful upgrade to Beta 3 I rebooted into the installer to perform step 9 in order to fix the WiFi. It's really strange. Attached are two photos of my Retina MBP with password request. Thanks! P.S.: I know, my MBP has the StainGate!

Thanks! This information is helpful. Now I can try to reproduce the problem, although I expect it will take me a while.

My best guess is that this is a bug in Big Sur, so it's possible that beta 4 will fix it. (I'll still try to reproduce the problem when I get a chance, however.)

 

[jhowarth]

Finally tried Hax3. Weirdly, while the seal wasn't applied, I did end up with a snapshot for the root partition which blocks using 'mount -uw /' with the 66 error. I can delete the existing update snapshot but that still leaves the root partition assigned to diskXsYs1. Any idea why Hax3 doesn't inhibit the call to apfs_systemsnapshot during stage 3 of the installation as well as the call to apfs_sealvolume? Also, is there some trick that allows an unsealed root volume to be reassigned from diskXsYs1 to diskXsY like Catalina would use for the root partition? I am assuming the use of the snapshot is blocking 'mount -uw /' (which surprises me as I thought sealing was the blocker).

 

[Barry K. Nathan]

If we are talking about how kext are handled by kc's, I still wonder if the auxilary kc has a looser requirement than the boot and system ones. If Apple were trying to maintain tighter control on their own system kext, it would make sense to have that extra layer of strictness for those and force all the third party kext over into L/E.

I imagine that's Apple's goal when SIP is enabled.

SIP disabled is a different ballgame (for which we are all in the dark and still trying to figure out the rules, I guess).

 

[Alex-Microsmeta]

Finally tried Hax3. Weirdly, while the seal wasn't applied, I did end up with a snapshot for the root partition which blocks using 'mount -uw /' with the 66 error. I can delete the existing update snapshot but that still leaves the root partition assigned to diskXsYs1. Any idea why Hax3 doesn't inhibit the call to apfs_systemsnapshot during stage 3 of the installation as well as the call to apfs_sealvolume? Also, is there some trick that allows an unsealed root volume to be reassigned from diskXsYs1 to diskXsY like Catalina would use for the root partition? I am assuming the use of the snapshot is blocking 'mount -uw /' (which surprises me as I thought sealing was the blocker).

For beta 4, we should write a general working flow with the various tipologies of mac unsupported hardware, using all patches availables from varoious authors, to skip error 66 and install graphic acceleration (where possible) , Wifi, USB, internal audio & ethernet. I'm available as tester and tutorial revisor for Core 2 Duo Nvidia Geforce 320M models.

 

[GSXB]

No just run it in terminal if you made the usb using the parrot geek method

It will not run,
It’s asking for a volume

 

[Barry K. Nathan]

Finally tried Hax3. Weirdly, while the seal wasn't applied, I did end up with a snapshot for the root partition which blocks using 'mount -uw /' with the 66 error. I can delete the existing update snapshot but that still leaves the root partition assigned to diskXsYs1. Any idea why Hax3 doesn't inhibit the call to apfs_systemsnapshot during stage 3 of the installation as well as the call to apfs_sealvolume? Also, is there some trick that allows an unsealed root volume to be reassigned from diskXsYs1 to diskXsY like Catalina would use for the root partition? I am assuming the use of the snapshot is blocking 'mount -uw /' (which surprises me as I thought sealing was the blocker).

To (try to) answer your question about why Hax3 behaves the way that it does, let's take a quick look at the Hax3 code in question:

-(BOOL)fakeDoNotSealSystem
{
        trace(@"force disable seal");
        return true;
}

        swizzle(NSClassFromString(@"OSISCustomizationController"),FakeFunctions.class,@selector(doNotSealSystem),@selector(fakeDoNotSealSystem),true);

The installer function in question is called doNotSealSystem. It's not called doNotBootFromSnapshot.

(Also, yes, I'd say it's the snapshot that's the blocker for 'mount -uw /'. Booting from a snapshot causes 'mount -uw /' to fail, because / is mounted from an APFS snapshot and the APFS filesystem does not ever allow snapshots to be mounted read-write. Configuring the system to boot from a snapshot is a prerequisite for sealing (if I understand correctly), but booting from a snapshot is all it takes to break 'mount -uw /', regardless of whether or not there is sealing.)

 

[jhowarth]

To (try to) answer your question about why Hax3 behaves the way that it does, let's take a quick look at the Hax3 code in question:

-(BOOL)fakeDoNotSealSystem
{
        trace(@"force disable seal");
        return true;
}

        swizzle(NSClassFromString(@"OSISCustomizationController"),FakeFunctions.class,@selector(doNotSealSystem),@selector(fakeDoNotSealSystem),true);

The installer function in question is called doNotSealSystem. It's not called doNotBootFromSnapshot.

(Also, yes, I'd say it's the snapshot that's the blocker for 'mount -uw /'. Booting from a snapshot causes 'mount -uw /' to fail, because / is mounted from an APFS snapshot and the APFS filesystem does not ever allow snapshots to be mounted read-write. Configuring the system to boot from a snapshot is a prerequisite for sealing (if I understand correctly), but booting from a snapshot is all it takes to break 'mount -uw /', regardless of whether or not there is sealing.)

So I'm confused now. How are people getting 'sudo mount -uw' to work at all? Is the only viable mechanism to do that interrupting the phase 3 installation step?
[automerge]1595937414[/automerge]

I imagine that's Apple's goal when SIP is enabled.

SIP disabled is a different ballgame (for which we are all in the dark and still trying to figure out the rules, I guess).

Which is why I am trying to get 'sudo mount -uw /' working. I can understand why the legacy usb injector has problems with kc's because of an additional signing restriction but I can't understand why using a chroot'd kextcache can't build a usable prelinked kernel. So I want to confirm that I can at least build the prelinked kernel with legacy usb support in the absence of a snapshot.

 

[jhowarth]

I think @testheit also was able to boot with a modified BaseSystem.dmg (post #1760), but my attempts with beta 2 failed. Maybe I copied ASentientBot's 0xffffffff patched boot.efi to the wrong place or some similar mistake, but I was never able to disable root DMG authentication. Even converting BaseSystem.dmg to read-write then back to compressed is enough to make the authentication fail.

I'll try again soon, but I'm not sure if that will be later this week or if it'll be next week. I first want to finish and release v0.0.17 of my patcher (with a fix for the beta 3 Ethernet problems), and after that, I might work on fixing various issues with my patcher (for another release later in the week) before returning to the issue of disabling root DMG authentication.

For disabling authenticated-root on an unsupported machine, what worked for me was booting from a patched Catalina installer, launching the Terminal application and running a copy of csrutil from Big Sur placed at the root level of the patched Catalina installer usb as csrutil2.

csrutil2 method