macOS 11 Big Sur on Unsupported Macs Thread

[borp99]

-- Replacing System Folder Icons --

Hi, I don't think this has been covered elsewhere in the thread. I've installed BS beta 2 on my Mac Pro 2010 on a separate internal SSD drive partition using the method of shutting down the usb installer half way through the final auto restart, in order to finish up with an unsealed OS, plus deleting the one created snapshot from recovery. This also means that the BS System disk is mounted on the Mojave and Catalina desktops, so avoid the 'unknown disk' notice. SIP/auth-root/compat-check all remain disabled across reboots. BTW, I'm finding BS faster/more responsive on my 5,1 than Catalina is. My daily OS is still 10.14 for now.

Apart from fixing Wifi for the existing 802.11n card, my main reason is to test out replacing the bright blue system folder icons in S/L/CoreServices/CoreTypes.bundle with those from 10.9. I've done this successfully in 10.14 and 10.15.

However, once replaced with the older folder icons and confirming they're still root:wheel, no matter how many times I try to clear the various icon caches, I'm still left with the original bright neon system folder icons I really dislike, even though they technically no longer exist. I can't see any unmodified CoreTypes.bundle file on the Preboot volume, although there's one in the BaseSystem.dmg on the Recovery volume. What is intercepting or overriding the older icons? As I appear not to be stuck booting into any snapshot, I'm pretty well stumped at the moment.

Any ideas?

I’ve been trying, in vain, to replace the bright blue BS System Folder Icons. Unsealing, no snapshots, custom BaseSystem.dmg, all failed.

I contacted the developers of LiteIcon 4.1, the app which has successfully allowed customisation of virtually all icons up to/including Catalina. While I did manage to get this to launch on BS by altering the string in SystemVersionCompat.plist from 10.16 to 10.15 - and this ‘does’ let you still customise Dock, Others, Applications and Volume icons using the app, the Folders category changes have no effect.

The LiteIcon people kindly looked into the Folders problem carefully and replied to me today:

“They [System Folder icons] look similar [I’d replaced them with ones from 10.9] but they are now dynamically generated from a base template icon and a glyph from SF Symbol font.
In other words they can no longer be replaced...”

You can, of course, still manually copy and paste icons one at a time onto folders (which adds a hidden ‘Icon?‘ file inside that folder). Maybe I’ll find a script (drag and drop?) to automate this tedious process. That’s a matter for another forum?!

 

[ricoc90]

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?

So far it's my experience that

a) I can not disable snapshot booting when the volume is not sealed (operation not permitted - both SIP and ARV disabled) and so I can't mount -uw (error 66). However, this way I am able to mount the Big Sur volume with write access through a USB installer and install kexts (in my case WiFi) quite easily. Haven't tested this process through Recovery though.

b) When leaving the volume sealed, it does allow me to disable snapshot booting and delete them which in turn will allow me to mount -uw

 

[Barry K. Nathan]

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

No no no, disabling root DMG authentication. This is different from the regular csrutil authenticated-root disable. The latter disables authentication of APFS snapshot volumes (on the installed system). The former disables authentication of BaseSystem.dmg. The latter is rock-solid reliable for me. The former is something I have completely failed at.

I can't yet be sure that I just didn't do something dumb. It's something I need to revisit when I get a chance, which probably won't be for a few days and might not be until next week.

 

[jhowarth]

So far it's my experience that

a) I can not disable snapshot booting when the volume is not sealed (operation not permitted - both SIP and ARV disabled) and so I can't mount -uw (error 66). However, this way I am able to mount the Big Sur volume with write access through a USB installer and install kexts (in my case WiFi) quite easily. Haven't tested this process through Recovery though.

b) When leaving the volume sealed, it does allow me to disable snapshot booting and delete them which in turn will allow me to mount -uw

So how are you leaving the seal in place yet disabling snapshot booting to allow a successful 'mount -uw /'? Are you saying that you have a set of steps that will switch the root from diskXsYs1 to diskXsY? When the seal is left in place, the only way that I could achieve 'mount -uw /' was on a mounted snapshot and using chroot'.

 

[GSXB]

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.

i get to 12 minutes left on the initial loading screen then constantly reboots ????

 

[ricoc90]

So how are you leaving the seal in place yet disabling snapshot booting to allow a successful 'mount -uw /'? Are you saying that you have a set of steps that will switch the root from diskXsYs1 to diskXsY? When the seal is left in place, the only way that I could achieve 'mount -uw /' was on a mounted snapshot and using chroot'.

Making sure that the seal actually is in place

diskutil info / | grep Seal

I boot into the USB installer (or Recovery for that matter) and fire up terminal.

I mount my Big Sur volume with write access:

diskutil mountDisk /dev/diskxsx
mount -uw /Volumes/volume_name

/S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -r ""

To list the snapshots:

diskutil apfs listSnapshots /Volumes/volume_name

To remove them simply run the following command for all snapshots:

diskutil apfs deleteSnapshot /Volumes/volume_name -uuid <uuid of snapshot>

As described here:

macOS 11 Big Sur on Unsupported Macs Thread

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...

forums.macrumors.com

 

[jhowarth]

Making sure that the seal actually is in place

diskutil info / | grep Seal

I boot into the USB installer (or Recovery for that matter) and fire up terminal.

I mount my Big Sur volume with write access:

diskutil mountDisk /dev/diskxsx
mount -uw /Volumes/volume_name

/S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -r ""

To list the snapshots:

diskutil apfs listSnapshots /Volumes/volume_name

To remove them simply run the following command for all snapshots:

diskutil apfs deleteSnapshot /Volumes/volume_name -uuid <uuid of snapshot>

As described here:

macOS 11 Big Sur on Unsupported Macs Thread

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...

forums.macrumors.com

So after you do that and reboot back into the Big Sur volume, what does 'mount' show for the line containing the mounted root partition? Without the seal, I was able to remove all of the listed snapshots but that still left mount showing the root partition as being on an unlisted snapshot (disk3s5s1). Also, at any point do you arrive at a configuration that allows 'mount -uw /' to work from a normal boot instead of from recovery or usb installer?

 

[jackluke]

Could someone compile this ? : https://github.com/macmade/dyld_cache_extract

I don't need the GUI app (that is also already released), but the command line version:
dyld_cache_extract - Extractor utility for DYLD shared cache

I guess it's a g++ main.cpp or gcc main.cpp :
https://github.com/macmade/dyld_cache_extract/tree/master/dyld_cache_extract

but can't get it compiled for the binary exec, the developer wrote that it requires this submodule:
https://github.com/macmade/PIMPL/tree/master/PIMPL/include/XS/PIMPL

But even after added it that I get some errors in compiling.

I also included this: https://github.com/macmade/dyld_cache_extract/tree/master/DCE

but I can't make the binary for dyld_cache_extract

 

[TimothyR734]

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

It has worked for me when I make a patcher using the ParrotGeek method I would get a need for internet connection error, when I made a Barrykn patcher I would get a dll.domanin error so I tried making a patcher following Parrotgeek's method the run the BarryKn micro-archer and it solved bother errors. The combo patcher

 

[ricoc90]

Also, at any point do you arrive at a configuration that allows 'mount -uw /' to work from a normal boot instead of from recovery or usb installer?

Once snapshots are deleted using the above method I boot from the actual Big Sur volume (diskxsx) with write access. No other steps have to be taken.

I am currently booting off of a snapshot because the only reason I'd need write access is to replace the IO80211Family.kext. However I've tested it a couple of times with beta 2 and beta 3 and all times it did boot off of the actual Big Sur Volume with write access.

I will do a new installation on a seperate SSD later today to give you the exact details.

 

[TimothyR734]

i get to 12 minutes left on the initial loading screen then constantly reboots ????

boot into your BS installer usb make sure your SIP is disabled, nvram boot-args="-no_compat_check" and try again soma mac's might need amfi_get_out_of_my way also and authenticated-root disabled another thing you could try and I use is the USBOpenCoreAPFSloader3b if you have a spare 1 gb usb use this then boot into it then choose your Install macOS Big Sur usb see if that works as this will set the variables you need for you

 

[jackluke]

No no no, disabling root DMG authentication. This is different from the regular csrutil authenticated-root disable. The latter disables authentication of APFS snapshot volumes (on the installed system). The former disables authentication of BaseSystem.dmg. The latter is rock-solid reliable for me. The former is something I have completely failed at.

For booting a patched BigSur BaseSystem.dmg from BigSur beta 3 , I use this method, you should try this custom SIP value: w%09%00%00

but before doing this you need csrutil disable otherwise that value is not stored in nvram and the command is only emulated ("csrutil disable" is also required to write on APFS Preboot Volumes).

If SIP is correctly disabled from any macOS (or Recoveries) you should get this output: nvram csr-active-config
w%00%00%00 (with this output you surely can write a next nvram address).

Then after you could use my csrutil2 (copying it on the root) from a Catalina Recovery (or directly from recovery single user mode so without booting the environment) that produces csr-active-config=w%09%00%00 , or you can use your method from Mavericks Recovery nvram csr-active-config=w%09%00%00 (probably from Mavericks Recovery you already have a full nvram write access so you might not need a preset csrutil disable).

Using this should allow to boot any patched BigSur BaseSystem.dmg , I used that method since beta1 and it worked.

 

[GSXB]

It has worked for me when I make a patcher using the ParrotGeek method I would get a need for internet connection error, when I made a Barrykn patcher I would get a dll.domanin error so I tried making a patcher following Parrotgeek's method the run the BarryKn micro-archer and it solved bother errors. The combo patcherView attachment 938231

I’ve tried numerous attempts to install all failed
Going to try a verbose boot to see if there’s a kernel panic at some point

 

[jhowarth]

Making sure that the seal actually is in place

diskutil info / | grep Seal

I boot into the USB installer (or Recovery for that matter) and fire up terminal.

I mount my Big Sur volume with write access:

diskutil mountDisk /dev/diskxsx
mount -uw /Volumes/volume_name

/S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -r ""

To list the snapshots:

diskutil apfs listSnapshots /Volumes/volume_name

To remove them simply run the following command for all snapshots:

diskutil apfs deleteSnapshot /Volumes/volume_name -uuid <uuid of snapshot>

As described here:

macOS 11 Big Sur on Unsupported Macs Thread

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...

forums.macrumors.com

Weirdly, after I rebooted into the Big Sur usb installer and checked with 'diskutil apfs listSnapshots /Volumes/BigSur', I found the update snapshot was still present. So using 'diskutil apfs deleteSnapshot /Volumes/volume_name -uuid <uuid of snapshot>' resulted in the root partition finally being disk3s5 rather than disk3s5s1. After rebooting and making sure sip was disabled on the supported machine, the root partition was finally able to 'mount -uw /' without errors. So I can finally start trying to rebuild some local prelinked kernel (knock on wood).

 

[OnawaAfrica]

has there been a fix for the 1st gen i5/i7-CPUs Kernel Panics on Big sur

 

[ricoc90]

Weirdly, after I rebooted into the Big Sur usb installer and checked with 'diskutil apfs listSnapshots /Volumes/BigSur', I found the update snapshot was still present. So using 'diskutil apfs deleteSnapshot /Volumes/volume_name -uuid <uuid of snapshot>' resulted in the root partition finally being disk3s5 rather than disk3s5s1. After rebooting and making sure sip was disabled on the supported machine, the root partition was finally able to 'mount -uw /' without errors. So I can finally start trying to rebuild some local prelinked kernel (knock on wood).

Great news!

As I mentioned I'd do a new installation to give you the exact details. Seems it's not needed anymore but will post it anyways as it might help someone else.

--

So, after a clean installation of Beta 3 you'll boot off of a (sealed) snapshot:

So boot off of the installer USB (still haven't tested this through Recovery) and fire up terminal:

After rebooting you should be able to mount -uw:

 

[startergo]

w%09%00%00

So this is a bit different than w%08%00%00 (which is the default) by this bit
#define CSR_ALLOW_ANY_RECOVERY_OS (1 << 8)

 

[TimothyR734]

Michael Tsai - Blog - Hopper for Apple Silicon and Big Sur

 

[Alex-Microsmeta]

So this is a bit different than w%08%00%00 (which is the default) by this bit
#define CSR_ALLOW_ANY_RECOVERY_OS (1 << 8)

Thank you to all the patchers here. Making all Cat supported pached macs compatible with BigSur will be really a difficult task to acomplish. 100 skilled ethic hackers supporting customers to save money during Covid-19 crisis, against the planned obsolescence traps of 70.000 programmers in the Apple Cupertino Starship! But it's very funny to learn from you

 

[jhowarth]

So this is a bit different than w%08%00%00 (which is the default) by this bit
#define CSR_ALLOW_ANY_RECOVERY_OS (1 << 8)

I not sure how to parse the csr active config values into the actual CSR defines but I wonder if it covers...

#define CSR_ALLOW_UNAPPROVED_KEXTS (1 << 9)

 

[jackluke]

So this is a bit different than w%08%00%00 (which is the default) by this bit
#define CSR_ALLOW_ANY_RECOVERY_OS (1 << 8)

I use this for my opencore setup for allowing patched BigSur BaseSystem.dmg booting : dwkAAA==

 

[startergo]

I not sure how to parse the csr active config values into the actual CSR defines but I wonder if it covers...

#define CSR_ALLOW_UNAPPROVED_KEXTS (1 << 9)

OpenCore on the Mac Pro

I understand that. But 0x77 is : #define CSR_ALLOW_UNTRUSTED_KEXTS (1

forums.macrumors.com

for some reason w%08%00%00 w is ASCII representation of 77 in hex. the rest of the numbers are in HEX.

 

[TimothyR734]

here is another patching method

https://www.reddit.com/r/BigSurPatcher/comments/hyzo74

 

[Alex-Microsmeta]

here is another patching method

https://www.reddit.com/r/BigSurPatcher/comments/hyzo74

Have you tried it? If it could be possible to choose the external disk partition... But seems to me that it could overwrite my perfectly working Catalina internal unit... It's a mystery box like dd command. I wait an expert to check if some commands could be useful eg to fix error 66.

 

[jackluke]

OpenCore on the Mac Pro

I understand that. But 0x77 is : #define CSR_ALLOW_UNTRUSTED_KEXTS (1

forums.macrumors.com

for some reason w%08%00%00 w is ASCII representation of 77 in hex. the rest of the numbers are in HEX.

Infact apple with BigSur introduced some SIP new non standard values: 0x877 (this can't be used on refind) , in my case I used 0x977 , ASentientBot patched boot.efi are 0x867 and another 0xFFF , I used 0x977 because I can represent that hex address as a kind of standard w%09%00%00 (instead of w%08%00%00) , and it allows to boot patched BaseSystem.dmg while keeping the apple stock boot.efi and also includes the "csrutil authenticated-root disabled" (probably only "csrutil status" is in a custom configuration).

But if I need to boot with standard SIP, without opencore simply use csrutil disable that sets it again to w%00%00%00 while using a stock apple boot.efi .