Jump to content

Updated Tips and Observations for Big Sur and Monterey b1

3 posts in this topic

Recommended Posts

Updated  22 June, 2021


tags: Big Sur/Monterey b1 multibooting chainloading tweaks brew migrating apps


Some updated tips and observations concerning Big Sur/Monterey installation to an available APFS HDD container/partition.  Assumes an existing working ESP bootloader.  System file modifications are made in recovery terminal with SIP disabled (csrutil disable and csrutil authenticated-root disable)  Any changes to the system files in recovery console require creating a new shapshot to be retained.


A comment about installing Monterey beta.


If you have downloaded a Monterey full installer and if you have an existing installation of Big Sur with sufficient free space, you can create a new APFS partition and replicate Big Sur to your new partition with SuperDuper v3.5 beta3 or newer.  Then install Monterey over the copy of Big Sur.  This should preserve your configurations and installed programs without having to create a USB installer.


For both Big Sur and Monterey you can edit the name of your Open Core or Clover boot entries within


located in the file tree here:


where a UUID is the actual directory name.


As pertaining to Big Sur:


1. Go ahead and make your USB installer with Open Core or Clover, but if you have an existing install of Catalina you can save time by starting the Big Sur installer directly from Catalina, choosing the target partition, and letting the installer copy over the install files rather than waiting on USB to boot and copy. If you then need the USB installer to boot and complete the Big Sur installation, you are prepared.  


Bootmanagers and bootloders and partitioning

A warning about partitioning.
There are numerous well known third party partitioning programs, including those running on windows, that can alter the partiton table in such a way as to render your APFS containers unrecognizable and unbootable.  Whenever possible use the mac OS Disk Utility to do your partitoning, and do so after you have backed up your partition table with a suitable utility.  One such free utility for linux is sgdisk.  You can boot a live linux distro from USB, and backup/restore your hard drive (example: /dev/sda) GPT partition table to/from USB media as follows:


backup:  sudo sgdisk --backup=/path/to/USB/sda_partition_table_01.01.2021 /dev/sda
restore: sudo sgdisk --load-backup=/path/to/USB/sda_partition_table_01.01.2021 /dev/sda


2. If you are a linux multi-booter and using GRUB2 as your main bootloader, and if you have an existing Catalina install with a working chainloaded Open Core or Clover, suggest you don't disturb/break your existing bootloader by making tweaks for Big Sur.  You can make an additional small 200MB FAT32 partition on your HDD and put your Big Sur bootloader there.  Note that if you choose to use clover you can directly chainload from GRUB2 by adding this entry to your grub.cfg file (where xxxx-xxxx is your Big Sur bootloder partition from "lsblk -f" or "sudo blkid" terminal output in Linux):

menuentry "Clover"{
    insmod part_gpt
    search --no-floppy --set=root --fs-uuid xxxx-xxxx
    chainloader /EFI/CLOVER/CLOVERX64.efi  # or whatever path you use

With Open Core version 0.6.4 and earlier chainloading from GRUB2 was relatively simple with grub.cfg menu entry:

menuentry "Open_Core"{
    insmod part_gpt
    search --no-floppy --set=root --fs-uuid xxxx-xxxx
    chainloader /EFI/OC/OpenCore.efi  # or whatever path you use

It now appears that Open Core 0.6.5 and newer have undergone code change that prevents directly chainloading OpenCore.efi from GRUB2.
However, if you want to continue to use GRUB2 as your main ESP bootloader, you can work around this issue by installing Refind 0.13.2 to the same ESP with GRUB2 and chainload to Refind in grub.cfg with the following menu entry (where xxxx:xxxx is your ESP UUID}:

menuentry "refind"{
   insmod part_gpt
   search --no-floppy --set=root --fs-uuid xxxx-xxxx
   chainloader /EFI/refind/refind_x64.efi

You can launch Open Core from the Refind GUI.  Here is a sample refind.conf that should chainload Open Core (where xxxx is the volume name or UUID name of your Open Core partition):

menuentry "OpenCore" {
    icon /EFI/refind/icons/youricon.png
    volume xxxx
    loader /EFI/OC/OpenCore.efi
    options "-v"   

When chainloading Open Core from Refind you may have to change the Vault configuration in Open Core config.plist from Secure to Optional.

This chainloading is an extra step but it preserves GRUB2 as the main bootloader and facilitates use of newer Open Core versions.

Note that you can install GRUB2, Refind, Open Core and the windows 10 bootloader bootmgfw.efi all on the ESP or you can install Open Core to a separate partition in order to edit/tweak your Big Sur bootloader settings without breaking an existing working ESP bootloader.  
When editing config.plist files, if you are not comfortable using an XML editor, and you have Catalina installed, you can download ProperTree from github and launch it from Catalina.  For Linux multibooters, you can modify your linux /etc/grub.d/40_custom to include any custom bootloader menu entries you want to keep, and then run update-grub from within Linux.

Using GRUB2 to chainload windows 10 in EFI mode.


Make sure that both secure boot and TPM are disabled in BIOS  Hide TPM in BIOS config.  Verify that windows was installed in EFI mode or has been configured after the install to boot in EFI mode.  Ensure that GRUB2 in your BIOS EFI config is your default boot selection.  Migrate the windows 10 boot files including BCD files to the main Windows partition as they are not there by default.  Verify that your machine is booting in EFI mode and not CSM.  Verify that your EFI boot partition has "boot" and "ESP" flags set.  Make sure you shut down windows while holding down the shift key until completely shut down.

As an example, using a single hard drive for all of your OS's, your GRUB2 grub.cfg windows 10 boot entry should look similar to the configuration below where xxxx-xxxx represents the UUID of the windows 10 partition, where the "x" in sdax represents the linux GRUB2 number of your ESP (with /efi/Microsoft/Boot/bootmgfw.efi), where the "x" in hdx and ahcix represents the GRUB2 hard drive number of the windows 10 installation, and where the "x" in gptx represents the GRUB2 partition number of the windows 10 installation.  GRUB2 numbers hard drives starting with 0, and partitions starting with 1. 


Examples: /dev/sda1, hd0,gpt3, ahci0,gpt3.


menuentry 'Windows Boot Manager (on /dev/sdax)' --class windows --class os $menuentry_id_option 'osprober-efi-xxxx-xxxx' {
    insmod part_gpt
    insmod fat
    set root='hdx,gptx'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hdx,gptx --hint-efi=hdx,gptx --hint-baremetal=ahcix,gptx xxxx-xxxx
      search --no-floppy --fs-uuid --set=root xxxx-xxxx
    chainloader /efi/Microsoft/Boot/bootmgfw.efi

3. When your install is finished and you are finally at the working desktop, you may want to make a backup. With Catalina this was easily done by using Disk Utility from a bootable USB installer to restore to an APFS formatted backup media.  The Big Sur Disk Utility ASR has repeatedly failed to replicate (bootable) Big Sur and it appears Disk Utility from Catalina 10.15.7 can not perform this task with Big Sur APFS containers. You can, however, use third party freeware other than dd to make a sector by sector clone of the entire Big Sur container onto removable media.  Alternatively, depending on the size of your AFPS container/partition and transfer rate, using dd can take quite a long time to do the backup.


If you only clone to USB media and then boot the clone to test the backup on the same computer from which it was made, both the Big Sur USB clone and the Big Sur HDD container installation show up within disk utility, in the USB media area.  The clone will have the same UUIDs.


SuperDuper v3.5 beta3 is tested and produces bootable backup with different UUIDS for both Big Sur and Monterey beta 1.


4. If your Open Core keyboard language is not properly configured the recovery console language may default to Chinese or some other language.  To avoid this make sure your keyboard language is specified in Open Core NVRAM section of the config.plist.
Recovery terminal is available for system file changes.

The mount command within recovery terminal will show volumes.  You can then run: diskutil mountDisk diskXsY (where x is the number of your Big Sur disk and y is the read-only slice from the mount command output).

You can then run: mount -uw /Volumes/thenameofyourBigSurvolume (not Data volume) to make the normally read-only volume writable.

Make any desired system file changes from the console and reseal (where X is your Big Sur volume name shown with mount command):

bless --folder /Volumes/X/System/Library/CoreServices --bootefi --create-snapshot

5.  If you have an existing Catalina installation with brew and numerous brew installed programs such as ntfs-3g, you can directly copy the brew files/programs (usr/local) to the corresponding file system locations within Big Sur and if necessary, manually create the soft links to enable programs.  If you need to write to the system file tree you can do this from the recovery console as previously referenced.

NTFS volumes will normally mount read-only but read-write can be enabled if the installed /sbin/mount_ntfs supports read/write:

From terminal make a mount point of your choice for each ntfs volume.  Example: sudo mkdir ~/ntfs
Unmount the target read-only ntfs volume where x is disk number and y is slice: sudo umount /dev/diskxsy
Mount ntfs volume as read-write: sudo mount -t ntfs -o rw,auto,nobrowse /dev/diskxsy ~/ntfs
Link to desktop: sudo ln -s ~/ntfs ~/Desktop/whatever_name_you_choose
Make sure finder is configured to show mounted volumes on the desktop.

Keep in mind that if you use ntfs-3g with osxfuse in Big Sur to automount ntfs volumes, install version 4.1.2 or later of macFUSE.  You may have to copy the ntfs-3g mount_ntfs binary directly to /sbin using recovery console.  Note that brew's ntfs-3g 2017.3.23_3 has previously failed to mount NTFS volumes with all files and folders visible.  You can use a prior Catalina Version, although it may be necessary to copy mount_ntfs directory to /sbin.


Note that as of this writing macFUSE 4.12 apparently does not work properly in Monterey beta 1.

There is a 4.20 beta that works in Monterey.   If you already have an install of Big Sur with version 4.20 (beta upgrade box checked) you can easily boot into Monterey and go into Big Sur file system to Library/PreferencePanes and click the 4.20 beta preference pane to install in Monterey.  Then reboot.


Any changes made to system files in recovery console should be followed by creating a new shapshot:

bless --folder /Volumes/x/System/Library/CoreServices --bootefi --create-snapshot (where X is your Big Sur volume name shown with mount command.

Here are some post-install terminal tweaks/info for zsh.  If you do not know what they do, don't use them:

defaults write NSGlobalDomain NSDocumentSaveNewDocumentsToCloud -bool false
defaults write com.apple.finder AppleShowAllFiles TRUE
defaults write com.apple.TextEdit RichText -int 0  
defaults write com.apple.finder _FXShowPosixPathInTitle -bool YES
sudo defaults write /.Spotlight-V100/VolumeConfiguration Exclusions -array "/Volumes"
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
defaults write com.apple.desktopservices DSDontWriteUSBStores -bool true
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true
sudo mdutil -i off -d /Volumes/whatevervolumename  (Disable Indexing AND Searching of specified Volume)
sudo mdutil -a -i off
top -o CMPRS
top -o MEM

6. If you have an existing Catalina installation with third party programs they may work without modification by copying them directly from Catalina Applications folder to the Big Sur Applications folder AND copying the corresponding entries for those programs from Catalina ~/Library/Application Support to Big Sur ~/Library/Application Support.  Note that ~/Library/Application Support refers to Users/yourusername/Library/Application Support.

7. A suitable Open Core NVRAM csr-active-config value to receive software updates with a supported hardware profile is 67080000.

8. Automator utility can create an apple script or shell script app for Big Sur but it may fail with error message when run from the desktop if absolute paths are not specified within the script.  Test by opening the app in automator and click the step button and see if the app executes with the desired result.  Test by running the command line directly within the zsh terminal.

9.  The attached EFI with OC was modified for Skylake/520/Sunrise Point but you may find that it works for a range of models with similar Intel hardware.  Supply your own Platforminfo.  If you multi-boot with linux you can run lspci -k from terminal in linux to show your pci hardware configuration.  The EFI attachment may be omitted from the post due to upload limitations.

10.  If you desire an Open Core GUI, change the config.plist PickerMode specification from BuiltIn to External and make sure you have the required Resources installed for your version of Open Core.  Set the applicable resolution for Open Core or all icons may not be completely visible.  Change HideAuxiliary to true if you do not want to see recovery.

11.  Removing old/unwanted snapshots.
Boot into recovery mode and disable SIP: csrutil disable/csrutil authenticated-root disable.

Reboot into recovery mode if necessary.


Run the mount command to see your Big Sur partition name and disk/slice.


In terminal type:

diskutil mount /dev/diskXsY  and hit enter (where X and Y are your Big Sur disk and slice)


then type: mount -uw /Volumes/X and hit enter (where X is your Big Sur volume name)


Your Big Sur volume should now be read-write.


Run: bless --folder /Volumes/x/System/Library/CoreServices --bootefi --create-snapshot (and hit enter to generate a new snapshot)


Now you can remove old/unwanted snapshots.


diskutil apfs listSnapshots diskXsY  for a list of snapshots/uuids

delete unwanted snapshots one at a time:


diskutil apfs deleteSnapshot diskXsY -uuid (the snapshot uuid you want to delete)

How to name snapshots and make bootable snapshots from recovery console (tested with Big Sur).


Create a new APFS snapshot:

/System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot -s "you_pick_name" -v /Volumes/your_Big_Sur_volume_name


Second, make it bootable:

/System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot -r "you_pick_name" -v /Volumes/your_Big_Sur_volume_name


12.  Change the Big Sur login background.  
Boot into recovery mode with SIP/authenticated-root disabled.  


From prompt run: cd /


cd into the desktop pictures folder (where X represents the name of your Big Sur install volume)


cd /Volumes/X/System/Library/Desktop\ Pictures


The default Big Sur login background in Desktop Pictures is Big Sur Graphic.heic.  You can optionally save this graphic by typing:


mv /Volumes/X/System/Library/Desktop\ Pictures/Big\ Sur\ Graphic.heic  /Volumes/X/System/Library/Desktop\ Pictures/Big\ Sur\ Graphic.heic.orig


Create a symlink to the desired login graphic....using Big Sur.heic as an example:


ln -s /Volumes/X/System/Library/Desktop\ Pictures/Big\ Sur.heic    /Volumes/X/System/Library/Desktop\ Pictures/Big\ Sur\ Graphic.heic


Run: bless --folder /Volumes/x/System/Library/CoreServices --bootefi --create-snapshot



Due to a glitch in Big Sur you make occasionally reboot with your prior login background if you do not remove the snapshot that contained it.


Once you have altered the installation snapshot ensure that your csr-active-config will allow booting.  A suitable value for Open Core is 67080000, and for clover 0x867.


Updates via full installer after altering install snapshot.


13. Memory and Swap.
Note if you disable swap without enough memory your machine may freeze or slow to a crawl.  The risk/performance tradeoff is up to you.


turn off swap:
sudo launchctl unload -wF /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist


re-enable swap:
sudo launchctl load -wF /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist


delete swap:
sudo rm /private/var/vm/swapfile*


for those who have nvram.plist:

search for swap enabled:
nvram.plist vm_compressor=4


or swap disabled:
nvram.plist vm_compressor=2


view swap status:
sysctl -a vm.compressor_mode


nvram config to enable swap:
sudo nvram boot-args="vm_compressor=4"


disable swap:
sudo nvram boot-args="vm_compressor=2"

14.  Disabling Sleep/Hibernation
check state:
sudo pmset -g | grep hibernatemode


sudo pmset -a hibernatemode 0


remove file to reclaim space:
sudo rm /private/var/vm/sleepimage
in /private/var/vm/ make a dummy:
sudo touch /private/var/vm/sleepimage


prevent write access to it:
sudo chmod 000 /private/var/vm/sleepimage
sudo chflags schg /private/var/vm/sleepimage

15. Manually install kexts to System/Library/Extensions.   
You need to enter recovery mode, open terminal, type at prompt  csrutil status
hit enter

verify response is "disabled"


if not, run at prompt: csrutil disable


type at prompt csrutil authenticated-root status
hit enter

verify response is "disabled"


if not run at prompt: csrutil authenticated-root disable

reboot into recovery mode if required

open terminal, at prompt run: mount
hit enter


verify volumes, disk numbers, slices.

confirm with: diskutil list

at prompt type:
diskutil mountDisk diskXsY  where X is the Big Sur disk number and Y is the Big Sur slice.
hit enter

at prompt type:
mount -uw /Volumes/your Big Sur volume name
hit enter

at prompt type: mount
hit enter

Your Big Sur volume should no longer indicate read-only

at prompt:  cp -r where/ever/your/kext/is/whatever.kext /Volumes/your Big Sur volume name/System/Library/Extensions

hit enter

for each kext:


at prompt: chown -R 0:0 /Volumes/your Big Sur volume name/System/Library/Extensions/target.kext && chmod -R 755  /Volumes/your Big Sur volume name/System/Library/Extensions/target.kext

hit enter

then type at prompt:  touch /Volumes/your Big Sur volume name/System/Library/Extensions && kmutil install --volume-root /Volumes/your Big Sur volume name  --update-all --force


hit enter, wait for finish

then type at prompt: /Volumes/your Big Sur volume name/usr/sbin/kcditto

hit enter, wait for finish


then type at prompt:

bless --folder /Volumes/your Big Sur volume name/System/Library/CoreServices --bootefi --create-snapshot


hit enter, wait for finish


16. some intel wifi info
Lilu.kext should load first and -lilubetaall in boot arguments in config.plist.


Use either Itlwm.kext with Heliport.app OR AirportItlwm.kext.  Don't load both Itlwm.kext and AirportItlwm.kext.

Itlwm.kext version 1.2.0 has worked well with Catalina and Big Sur when used in conjunction with the Heliport.app.

If you have both Catalina and/or Big Sur and/or Monterey installed and prefer to use AirportItlwm.kext, you can rename them (example: Catalina version renamed to AirportItlwm2.kext) and inject them with Open Core by specifying MinKernel and MaxKernel versions in the config.plist to load the appropriate kext based on whether Catalina or Big Sur is booting.  With clover use can use separate small FAT32 partitions for each OS version when different kexts are required.


Useful links:

          Audio config
The following information excerpted from the web may help you:


For Open Core:


Suggest you use AppleALC and modify the Open Core config.plist to show the layout-id for your audio.  Don't use the kernel switch method for Open Core.


Configuring your Audio Device


Audio devices are much simpler to configure than they used to be thanks to the development of AppleALC. AppleALC is a kernel extension that provides native Apple audio capabilities. To use it, the first thing you will need to know is what audio codec your laptop uses. If you don't already know, or if you're unsure, you can use a Linux live USB to do a codec dump. A codec dump provides a treasure trove of information about your device and the paths it uses to connect things like internal amplifiers to speakers or headphones.


Creating a Codec Dump


If you do need a codec dump for whatever reason, boot from your Linux live USB and find the nearest terminal or command line. The following command will display the details of your codec on screen with a pause so you can read it.


cat /proc/asound/card0/codec#0 | less


The first line should provide your codec. It will look something like this:


Codec: Realtek ALC294


If you would like to save the codec to a file so you can reference it again when you're back in macOS, cat it to a file instead and save the file to the boot partition of the USB drive, on another USB drive, or somewhere on your network.


cat /proc/asound/card0/codec#0 > /mnt/MyOtherUSBDrive/codec.txt


Now that you're familiar with your codec, let's install AppleALC.


AppleALC Prerequisites


If you're dual booting with Windows or Linux, you should enable the Devices/Audio/ResetHDA property which will reset the audio device on startup to flush any configuration .


Installing AppleALC


Installing AppleALC is simple. You just need to download the AppleALC kext from the project's release page and add the kext to Open Core Kexts. If you do add it, make sure to edit your config.plist


Download AppleALC @ Github


Open Core:


Your new AppleALC kext path should look like it does in the tree below.

└── OC
    └── Kexts
        └── AppleALC.kext


Before rebooting, let's configure it!


Configuring AppleALC


Knowing your codec makes things somewhat easier as you can look it up in the AppleALC WIKI and find all of the layouts that could work with it.

AppleALC Supported Codecs


If you don't find your codec listed, you might find that it's just a rebranded version of another so it wouldn't hurt to search for "AppleALC {your codec}".


Once you have a list of layouts, but you don't know which is the right one you can test them one by one.


Just configure the layout id in config.plist with your favorite plist editor and reboot. If audio works, congratulations! Otherwise, repeat until you've found it.


Open up your plist editor and the config.plist, then browse to DeviceProperties/Add and your layout-id.

None of the Layout IDs Worked!


You could try using VoodooHDA instead.

Using VoodooHDA

VoodooHDA is an alternative to AppleALC, and it works pretty well but rather than adding native support,


VoodooHDA provides its own audio solution. Installing it is pretty straightforward. Simply download the kext, preference pane, and settings loader and add them to your system.




The kext goes in Clover/kexts/Other, if you have AppleALC installed you'll want to remove it. Open (execute) the preferences pane and it should prompt you to install, if it doesn't drag it onto System Preferences and it'll install that way. The settings loader should be installed to Applications, and you should run it once to enable it.

Download VoodooHDA @ SourceForge


Open Core:


As with AppleALC, it should follow the same pattern in the tree.


└── OC
    └── Kexts
        └── VoodooHDA.kext
Big Sur Missing Secure Boot Manifests
Sometimes the already installed operating system may have outdated Apple Secure Boot manifests on the
Preboot partition causing boot failure. If there is a boot message: “OCB: Apple Secure Boot prohibits this boot entry, enforcing!”, it is likely the case. When this happens, either reinstall the operating system or copy
the manifests (files with .im4m extension, such as boot.efi.j137.im4m) from /usr/standalone/i386 to
/Volumes/Preboot/<UUID>/System/Library/CoreServices. Here <UUID> is the Big Sur system volume identifier.


On HFS+ installations the manifests should be copied to /System/Library/CoreServices on the system volume.


Find your preboot volume from terminal:
diskutil list


mount the Preboot volume
diskutil mount diskxsy (x=disk, y=slice)
CD into your Preboot volume


Note the actual volume is under /System/Volumes/Preboot in macOS
however in Recovery it's simply under /Volumes/Preboot


cd /System/Volumes/Preboot


Grab your UUID


f multiple show up(ie. you dual boot multiple versions of macOS), you will need to determine which UUID is correct.


Print the value of .disk_label.contentDetails of each volume.


cat ./46923F6E-968E-46E9-AC6D-9E6141DF52FD/System/Library/CoreServices/.disk_label.contentDetails
 Big Sur HD%


cat ./CD844C38-1A25-48D5-9388-5D62AA46CFB8/System/Library/CoreServices/.disk_label.contentDetails
 Catalina HD%


Copy over the secure boot files, recovery will need different commands


Example commands for inside macOS


Replace 46923F6E-968E-46E9-AC6D-9E6141DF52FD with your UUID value

cd ~

sudo cp -a /usr/standalone/i386/. /System/Volumes/Preboot/46923F6E-968E-46E9-AC6D-9E6141DF52FD/System/Library/CoreServices


Example commands for Recovery:

Replace Macintosh\ HD and 46923F6E-968E-46E9-AC6D-9E6141DF52FD with your System Volume's name and Preboot's UUID

cp -a /Volumes/Macintosh\ HD/usr/standalone/i386/. /Volumes/Preboot/46923F6E-968E-46E9-AC6D-9E6141DF52FD/System/Library/CoreServices


Enable SecureBootModel and reboot.


          useful links
https://github.com/OpenIntelWireless/itlwm/releases orig.
https://github.com/topics/hackintosh?o=desc&s=updated posted EFIs





Edited by HenryV
update/add info
  • 3 weeks later...
  • HenryV changed the title to Updated Tips and Observations for Big Sur and Monterey b1
  • Create New...