macOS 11 Big Sur on Unsupported Macs Thread

[mac_4eva]

I found a really easy way to mount the root volume as writable.

Check this guys twitter feed: @EBADTWEET

Its the same approach discussed on this thread and what I wrote here https://egpu.io/forums/mac-setup/macos-up-to-11/ except executed slightly differently. apfs_systemsnapshot is better to use and Apple-recommended way (per WWDC article).

Anyway, the great thing is that we can at least work with this to modify the root volume so glad that it works.

 

[jhowarth]

From macOS Big Sur 11 Beta Release Notes API Changes, this bit looks ominous...

• Kernel extensions using certain deprecated KPIs no longer load. Refer to the support page. While macOS Big Sur remains in development, you can temporarily disable System Integrity Protection to allow these deprecated extensions to load. (55068348)

Sounds like once Big Sur hits GM, all the legacy kernel extension support will go poof (irrespective of whether SIP is disabled).

 

[libneko]

Looking up if it can be used for installing wifi kext, it looks like a MUCH SIMPLIER method

 

[bhast2]

I get this after installing. What did I do wrong?? And how can I fix it

 

[Azkylinegtr]

I followed the steps on my late 2012 iMac and installed to a separate volume. When trying to boot I get the do not enter sign. I can boot back to Catalina but can’t delete the Big Sur volume not the update volume it created. What do I do now?

 

[athlonmusic]

Is anyone having luck running Big Sur on a 2010 Unibody MacBook?

 

[Kriter]

Its the same approach discussed on this thread and what I wrote here https://egpu.io/forums/mac-setup/macos-up-to-11/ except executed slightly differently. apfs_systemsnapshot is better to use and Apple-recommended way (per WWDC article).

Anyway, the great thing is that we can at least work with this to modify the root volume so glad that it works.

Well it's not, I'll paste @EBADTWEET's guide.

1. The root volume is now a cryptographically sealed apfs snapshot. Every single bit of the fsroot tree and file contents are verified when they are read from disk.
   
   
2. It is no longer possible to boot a "live" filesystem, that is, one which can be written to.
   
   
3. You can instead disable authentication of the root volume by booting to recovery and running `csrutil authenticated-root disable` in Terminal.
   
   
4. Once you've done that, you can mount the live version of the root filesystem, make modifications to that, and then make a new snapshot. You can then boot from that snapshot.
   
   
5. Synthetic symlinks and directories still work just fine in a Signed System Volume.
   
   
6. Mounting the live filesystem after disabling root authentication can be done via $ sudo mount -o nobrowse -t apfs /dev/diskNsM /path/to/mntpoint
   
   
7. diskNsM can be obtained by running `mount`, looking for the root mount's device, and chopping off the last s, e.g. if your root is /dev/disk1s2s3, you'll mount /dev/disk1s2
   
   
8. The mount point is anything you choose. Once you've got the live mount at /path/to/mntpoint, you can modify stuff. After your modifications are complete, run $ sudo bless --folder /path/to/mntpoint/System/Library/CoreServices --bootefi --create-snapshot
   
   
9. Then reboot, and you'll be booted from the new snapshot you created, with your modifications honored. Authentication is disabled. Note that this leaves you open to evil maid attacks, so exercise care when using this workflow.

 

[quaccOS]

I made a separate 90 GB Catalina partition to my main one.
I downloaded the InstallAssistant.pkg (http://swcdn.apple.com/content/down...kxzj3zjshu1srsh4n74a41n4/InstallAssistant.pkg)
Then downloaded the really simple installer hack containing Hax.dylib & InstallHax.m

But then, I seen this https://lynx.pink/big-sur-unsupported-macs-tldr/ and I cloned this Big Sur Please script from GitHub.
I ran this convenient script instead: https://github.com/4ndv/big-sur-plz; opened InstallAssistant.pkg; installed it to /Applications; opened the macOS Beta app; then let the computer complete the upgrade.

After about 10 minutes waiting in Catalina, the usual loading bar shows. The grey apple logo strangely changes to pure white and shows 30 minutes remaining. After about 40 minutes (& 2 restarts) – it goes in a reboot loop saying
"Your computer shutdown because of problem press any key blah…". I proceeded to boot my main Catalina partition to check what was wrong.

I called the original 10.15 APFS partition, "Big Sur".
In Container disk2, I now have:

1. Big Sur – Data,
2. disk2s5,
3. Update

 

[ASentientBot]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not Edit: posted the new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -r ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

 

[TimothyR734]

I get this after installing. What did I do wrong?? And how can I fix it

View attachment 927338

Is your SIP disabled
[automerge]1593044055[/automerge]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -s ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

maybe this could help it was post in the previous page

https://twitter.com/i/web/status/1275454103900971012

 

[libneko]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -s ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

I may have found another way using bless, but destroyed my OS in progress, after reinstall will try mine too. Nice work!

 

[Earl Urley]

Is Beta 2 out yet? I thought I saw someone mention that they just upgraded to Beta 2, but the python script is only showing Beta 1..

 

[libneko]

Also, should be able to just mount -uw /Library/System\ Disk\ Name in installer/BS recovery

 

[mac_4eva]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -s ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

Awesome job finding this!

 

[quaccOS]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -s ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

But apfs_systemsnapshot isn't a command in the zsh shell?
I'm very lost…I'm still at boot loops & strange partitions – and people are already at "Just tryna fix the WiFi. All done".

 

[ASentientBot]

But apfs_systemsnapshot isn't a command in the zsh shell?
I'm very lost…I'm still at boot loops & strange partitions – and people are already at "Just tryna fix the WiFi. All done".

It's at /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot in BS. Does not exist in Cat or earlier.

 

[bhast2]

all I have is internet recovery what are my options???
I disabled Sid before I installed in recovery but after install it won't boot

 

[quaccOS]

I made a separate 90 GB Catalina partition to my main one.
I downloaded the InstallAssistant.pkg (http://swcdn.apple.com/content/down...kxzj3zjshu1srsh4n74a41n4/InstallAssistant.pkg)
Then downloaded the really simple installer hack containing Hax.dylib & InstallHax.m

But then, I seen this https://lynx.pink/big-sur-unsupported-macs-tldr/ and I cloned this Big Sur Please script from GitHub.
I ran this convenient script instead: https://github.com/4ndv/big-sur-plz; opened InstallAssistant.pkg; installed it to /Applications; opened the macOS Beta app; then let the computer complete the upgrade.

After about 10 minutes waiting in Catalina, the usual loading bar shows. The grey apple logo strangely changes to pure white and shows 30 minutes remaining. After about 40 minutes (& 2 restarts) – it goes in a reboot loop saying
"Your computer shutdown because of problem press any key blah…". I proceeded to boot my main Catalina partition to check what was wrong.
View attachment 927345
I called the original 10.15 APFS partition, "Big Sur".
In Container disk2, I now have:

1. Big Sur – Data,
2. disk2s5,
3. Update

Anyone else's machine stuck in a boot loop after BS installation? Data & Update partitions are showing in Disk Utility on the main Cat partition. I made a 2nd Cat partition just for Big Sur testing, but booting seems bleak…

 

[mac_4eva]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -s ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

Hmm I tried it but get an unbootable system. In your long version, you use the -s option. Did you mean -r? I presume you do per tldr. Executing with -r “” on my live volume, I’m unable to boot. Anyway, these snapshots make it rather easy to return back to a bootable system.

 

[ASentientBot]

Hmm I tried it but get an unbootable system. In your long version, you use the -s option. Did you mean -r? I presume you do per tldr. Executing with -r “” on my live volume, I’m unable to boot. Anyway, these snapshots make it rather easy to return back to a bootable system.

Yes, I meant -r. Yikes, sorry about that. Will correct my post.

 

[nandor690]

big-sur-plz

Thank you. This fixed that particular problem. I’m seeing now how the rest of the install goes

 

[bhast2]

ok im installing Big Sur to an external HD from a supported Mac!!! once I get that done how do I disable SID on my non supported MacBook Pro. I'm going to boot into recovery from the external HD, so from the external recovery how do I disable SID on my internal HD. hope that makes since

 

[Minh_Ton]

After some minimal debugging I guess can give some hints on how to include the parrotgeek1 LegacyUSBInjector.kext that is required on "unsupported HighSierra Mac" to have IOUSB input and output devices responsive as for example: bluetooth mouse and keyboard, internal trackpad and keyboard, external usb mouse and keyboard, external usb hard disk and so on.

The USB BigSur Installer use this to load its recovery environment (or macOS Ramdisk):

/Volumes/USBLabel/BaseSystem/BaseSystem.dmg
/Volumes/USBLabel/Library/Preferences/SystemConfiguration/com.apple.boot.plist
/Volumes/USBLabel/System/Library/CoreServices/boot.efi (and PlatformSupport.plist)
/Volumes/USBLabel/System/Library/KernelCollections/BootKernelExtensions.kc

"PrelinkedKernels" folder is no more used, now seems apple use only BootKernelExtensions.kc
and for third party kext this other path /Library/KernelCollections/AuxiliaryKernelExtensions.kc

using kmutil can easily build (targeting the BigSur volume) a new BootKernelExtensions.kc

If instead the BootKernelExtensions.kc used is the one inside BaseSystem.dmg
then the path is "BaseSystem mounted"/System/Library/KernelCollections/BootKernelExtensions.kc
(I'd exclude that also BaseSystemKernelExtensions.kc is used for booting)

Then to make a new Patcher surely a modified BaseSystem.dmg should be made with something as:

make temporary "writeable" the BaseSystem.dmg

hdiutil attach -owners on BaseSystem.dmg -shadow

copying the patches or modified file to the BigSur BaseSystem and make read-only again

hdiutil convert -format UDZO BaseSystem.dmg -shadow

This maybe still won't let to install BigSur on "unsupported HighSierra Mac", but at least they can use the BigSur recovery environment, otherwise they should clone a BigSur installation from an "HighSierra supported Mac" or "Catalina supported Mac", but anyway they require a pre-build BootKernelExtensions.kc with USBLegacyInjector.kext embedded.

That method won’t work, and results in a signature error when booting off the USB installer.

 

[Jose C. Salazar]

Dumb question, already installed BS on mu MBP mid 2012, flawless, with no wifi, all solutions read are bit too difficult too me so I will wait for an easier way, in the meantime I would like to use a wifi stick archer t2u nano, but when installing the driver it says "wrong version" (obvious), im new on macOS, is there something im doing wrong? or another way?

 

[chris1111]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -r ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

I sse something similar here

macOS 11 Big Sur

At WWDC 2020, Apple finally announced a major advancement to the Mac - the migration to Apple silicon with backwards-compatible support for Intel via ...

egpu.io