Jump to content
6 posts in this topic

Recommended Posts

Updated  22 August, 2021

 

tags: Big Sur/Monterey partitioning multibooting chainloading tweaks brew migrating apps links swap virtual memory

 

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

.disk_label.contentDetails

located in the file tree here:

System/Volumes/Preboot/UUID/System/Library/CoreService

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
}

 

Note: Observed with Open Core 0.7.3, GRUB2 can once again directly chainload OpenCore.efi.  Future code changes may prevent direct chainloading and you may wish to use Refind boot manager.
 
You can install 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
}

 

A note from the refind page author:

 

http://www.rodsbooks.com/refind/

 

begin excerpt:

 

Note: I've seen reports that rEFInd is failing to boot macOS 11 ("Big Sur"). There seem to be two problems. First, and confusingly, macOS 11 requires booting via the boot loader Preboot partition, not the main macOS installation partition. With recent versions of macOS, rEFInd normally presents both options, but users might reasonably hide the poorly-named Preboot option, which is the only one that works. Second, a bug in rEFInd 0.12.0's memory management could cause it to hang on some EFIs, including some that Apple rolled out as part of the macOS 11 upgrade. Using rEFInd 0.13.0 and booting via the Preboot loader option should work around these problems. If all else fails, the new (rEFInd 0.13.0) feature to boot via an EFI firmware boot option may help; see the description of this feature here.

 

end excerpt.


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
    else
      search --no-floppy --fs-uuid --set=root xxxx-xxxx
    fi
    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.

 

4. If your Open Core keyboard language is not properly configured the recovery console language may default to an undesired 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

Reboot.


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.

 

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.

 

 

https://osxfuse.github.io/


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

Reboot.

 

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

 

disable:
 

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

and:
 

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

reboot


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

 

links:
https://github.com/1hbb/OpenIntelWireless-Factory/releases
https://github.com/ClayMoreBoy/Hackintosh-Kext-Factory/releases

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

EFI
└── 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.

 

Clover:

 

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.

 

EFI
└── 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

Where <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)
 
Change directory 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

ls

example output:

46923F6E-968E-46E9-AC6D-9E6141DF52FD
CD844C38-1A25-48D5-9388-5D62AA46CFB8

 

If multiple UUIDs 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

example output:
 

Big Sur HD%

 

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

example output:
 

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 Default in SecureBootModel in Open Core config.plist and reboot.

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
          useful links
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

posted EFIs

https://github.com/topics/hackintosh?o=desc&s=updated
https://github.com/topics/hackintosh?o=desc&s=updated

#####
https://github.com/CloverHackyColor/CloverBootloader/releases
https://github.com/1hbb/OpenIntelWireless-Factory/releases
https://github.com/ClayMoreBoy/Hackintosh-Kext-Factory/releases
https://gitter.im/OpenIntelWireless/itlwm#
https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true
https://github.com/ic005k/QtOpenCoreConfig/releases/
https://github.com/OpenIntelWireless/itlwm/releases orig.
https://github.com/1hbb/OpenIntelWireless-Factory/issues
https://osxfuse.github.io/
https://www.shirtpocket.com/blog/index.php/shadedgrey/comments/finally/

https://github.com/MonitorControl/MonitorControl/releases
https://github.com/acidanthera/MaciASL/releases

https://github.com/ITzTravelInTime/MenuBarSIPDetector/releases

https://github.com/0xFireWolf/RealtekCardReader/releases
https://github.com/headkaze/Hackintool/releases

https://github.com/zzanehip/Safari-Experiment/releases/tag/v1.0

+============EOF==================

 

EFI_Clover5137.zip

Safari.zip

Edited by HenryV
update/add info
  • Like 9
  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...
  • 4 months later...

Thank you for linking my app, nice writeup man, i would recommend using different fonts and font weights so someone ca  better distinguish between paragraphs and contents.

 

PS: i have updated my app to include more detailed information about the current status of SIP check it out 😉 

Link to comment
Share on other sites

  • 3 months later...

Greetings HenryV

 

I have a problem where the Monterey install failed leaving os-update snapshot

on disk1s9s1

 

Reading over your beautifully written piece here I thought I might be able to remove this.

 

how to remove this pestilence?

 

I tried running this command in Terminal in Big Sur normal desktop mode: sudo rm -rf "/macOS Install Data" 

unfortunately I did not see it gone. Perhaps this command should be run in Recovery Mode?

The instructions did not say do this in Recovery.

 

What is your suggestion and the proper way to go about this without damage?


Thank you

 

 

Link to comment
Share on other sites

HenryV

 

After having tried the above method, the /dev/disk1s9s1 doesn't show up in OS Recovery at all.

I have Catalina first installed then Big Sur in it's own partition

 

disk1s8 is the Update preboot for Big Sur and is hidden and not seen in diskutil list and cannot mount while in Big Sur

but is seen as a mount Update in Catalina.

 

In OS Recovery, Big Sur and the Catalina are disk3

 

The os update snapshot is only seen so far while in running Desktop as /dev/disk1s9s1 has a 15.3GB apfs 

This partition apfs is the Monterey update that did not install for some reason,


Reading the Install.log states device bridge problem.  Could not bridge device. 

 

Have you any ideas here?

 

 

 

 

Link to comment
Share on other sites

I found the answer to this /dev/disk1s9s1 as being the startup apfs boot up.  

Probably a new bootup besides the Update prebooter.

 

Performed on here a direct update to Big Sur within Catalina and the result was Update apfs as preboot.

When tried to upgrade Big Sur to Monterey a new startup apfs appeared that being the one above as mentioned.

It is the new one.

 

But I have to do a migration restore from Time Machine after installing new copies of Big Sur and Catalina.

Interesting situation.

 

Thank you for this excellen write up post

Have great weekend

Link to comment
Share on other sites

 Share

×
×
  • Create New...