20A2314a Install Guide

20A2314a_Install_Guide.md

Here’s a quick guide on how to install macOS Big Sur build 20A2314a.

Disclaimers:

I do not take any liability for any damage or data loss caused by following this guide or running this build of macOS, this guide is strictly for educational purposes only. This guide is strictly meant to be followed with your brain turned on, do not follow this guide with your brain turned off or not paying attention, as messing up some of these commands could render your main system unbootable! This guide also assumes you know how file permissions and such work, and that you are capable of diagnosing issues yourself. The guide as-is will only work on Intel Macs. (The only ARM Mac this build legitimately supports is the DTK - I will not be covering how to install this build on those nor is it necessary, if you have a DTK you should be able to adapt the guide based on knowledge of the boot-flow of the DTK)

Thanks to MykolaG for explaining how to mount a sealed volume as read-write, and for explaining how to recreate the APFS snapshot for the System partition.

Concept:

The fundamental idea behind this guide is that we need to get the root filesystem from the disk dump of this build (I strongly do not recommend using the tarball for the root filesystem as it is very likely missing bits that are necessary, please just mount the disk dump as is (which implies you will need a drive big enough to store the full dump)) onto an APFS container that’s partitioned in the right way for macOS to boot. (With the preboot partition set up right ideally) The easiest way to do this is to install macOS Big Sur (any version, though preferably dev beta 1 as it’s the closest to this build) onto that APFS container, then completely replace the root filesystem with the one from the disk dump of this build (in addition to the Data partition, which we will be using the tarball for, as the one in the disk dump is sadly encrypted)

Guide:

1. Download the disk dump of this build and the Data partition tarball, and untar the disk dump so that you have the raw image (will have an ISO extension) (I cannot help you procure this build but it is very much publicly leaked, and out there) Copy both to an external working drive which will house these files. (If your target for this build is another Mac, you can also use Target Disk Mode on that Mac to install directly to its drive and skip partitioning.)

2. Clean install macOS Big Sur DP1, make sure to completely erase the main disk and create two HFS+ partitions (one will be for your main “technician install” that will stay on DP1, and one will be the partition which will become the one that houses the install of this build). (This install will be on the technician partition)

3. Go through initial setup, create your user as you normally would, then reboot into recovery mode (hold Command-R). Open a terminal window, then run these two commands:

csrutil disable
csrutil authenticated-root disable

If you're following this guide on a T2 Mac (UNTESTED), you will also need to lower system boot security policy to "No Security" so as to disable EFI from requiring personalization from Apple to your ECID and to disable kernelcache verification.

Explanation: SIP needs to be off, because we're going to be installing Big Sur dev beta 1 on the target APFS container. This will seal the system volume in that container, meaning it will "root"/boot from a snapshot vs the live filesystem. While we can probably patch this part of the install out (at minimum on non-T2 Intel Macs) so that the kernel will root off the live filesystem, this causes the release distribution of the APFS kext (which is shipped in all retail versions of macOS) to panic, as this isn't an allowed scenario on release builds normally.

4. Boot back into your technician partition, and install Big Sur DP1 again on the target partition, SIP settings should be preserved from the main install (on x86, the per container SIP policy isan Apple Silicon only thing) and the target container should be in a bootable configuration at this point

5. Make a mount directory for the target container System partition (The data partition is going to be overlaid on top of the System Partition for this to work properly, so it’s not necessary)

6. Find your System and Data partitions’ disk identifiers by running this command:

diskutil list

This will list out all the disks connected to your system and the partitions that macOS recognizes exist on those disks. Note the identifiers (the diskXsY identifiers) for the System and Data partitions on the target container, these will be important later.

7. Mount the DTK disk dump with this command:

hdiutil attach -readOnly -blocksize 4096 [dtk_disk_dump_img]

What this command does is mount the DTK disk dump assuming a sector size of 4096 bytes (if you try to naively mount it, it’ll be assumed to have 512 byte sectors, which is incorrect for Apple Silicon disk dumps) Note that failure to mount the Data partition is normal and expected, because you don’t have the keys to decrypt it (this is the case on Apple silicon disk dumps)

8. Note where your DTK disk dump’s root filesystem is mounted, this will be important in a second. Run the following command to verify mount points:

mount

It should be mounted under /Volumes/System, note both it’s mount point and disk identifier.

9. Unmount the data and system partitions of your target container with the following commands:

diskutil umount diskXsY
diskutil umount diskXsZ 

where diskXsY is the identifier of the Data partition on the target container you found earlier (the order of mount/unmount will matter later, so to be safe, anytime you are unmounting, always unmount Data first, then System (which is the diskXsZ identifier)

10. Mount the target container system partition (The order matters here!) with the following command:

sudo /sbin/mount -o nobrowse -t apfs /dev/diskXsZ [mount_directory]

This command mounts the system partition on the target container. Do a similar thing for the Data partition, pay very careful attention to the syntax here!

sudo /sbin/mount -o nobrowse -t apfs /dev/diskXsY [mount_directory]/System/Volumes/Data

We are mounting the Data partition in the mounted System partition, this is to replicate how macOS mounts the disk normally, so that when copying stuff over, there aren’t breaking issues.

11. Run the following commands to gain ownership over the files on the target container (make sure to cd to the mount directory first, the view should be the files on your target system container:

sudo chown -R [username] .
sudo chmod -R 777 .

This takes complete ownership of all the files on the target container, this is just so that you can delete stuff in the container easily.

12. Remove all the files on the mounted containers (PLEASE MAKE SURE THAT YOU ARE IN THE MOUNT DIRECTORY WHERE THE TARGET SYSTEM IS AND NOWHERE ELSE OR YOU WILL LOSE DATA YOU DON’T MEAN TO. I AM NOT RESPONSIBLE FOR ANY LOST DATA. IF IN DOUBT, CD AGAIN TO THE MOUNT DIRECTORY ROOT TO ENSURE YOU ARE IN THE RIGHT PLACE, and type pwd TO ENSURE YOU ARE IN THE RIGHT PLACE)

sudo rm -rf .

(THAT DOT AT THE END MEANS ANYTHING IN THE CURRENT DIRECTORY, RF means “forcibly, go recursively from ./ downwards,” which is just the things on the target data/system containers (ASSUMING YOU ARE IN THE RIGHT PLACE)

Errors from the rm command are ok, due to weirdness in APFS directory hierarchies.

13. Run this command to copy over the System partition’s directory hierarchy over.

sudo rsync -a -v -x -H -p -W -E -S --progress --numeric-ids --ignore-errors [mount point of disk image System partition]/ [mount point of target container System partition]/

NOTE: The trailing slash on the source folder is very important, as if you don't include it, rsync will try to copy the source as a folder to the destination.

This command is doing the heavy lifting of copying over the disk image's System partition over, it will take time. If you see a line about errors at the end of the command, this is expected.

numeric-ids here means that the permissions from the source as numbers (which should mostly be root:wheel) will be copied over.

14. Run this tar command to untar the Data partition to the right place:

sudo tar -x -z -v -p --same-owner -f [DTK data partition tar gz] -C [mount point of target container System]/System/

This will copy over the contents of the Data partition. Note that sudo is important as is --same-owner, to prevent permissions from causing problems during boot.

Again, will take a while, errors are expected at the end of the process.

15. Run these commands to force the target container to enter initial setup mode again:

cd [mount point]/System/Volumes/Data/private/var/db
rm .AppleSetupDone

16. Now that the entire directory hierarchy is in place, recreate the APFS snapshot for the System partition based on the new one:

/usr/sbin/bless --folder [mount point of target System]/System/Library/CoreServices --bootefi --create-snapshot

17. Unmount the disk image, then the data and system containers:

hdiutil detach [mount point of disk image] //unmount the disk image
diskutil umount diskXsY // Data partition of target
diskutil umount diskXsZ // System partition of target

18. Optionally, to boot the development or KASAN kernelcache, set the following boot-args:

sudo nvram boot-args="kcsuffix=development"

Replace development with kasan in the above command to boot the KASAN kernelcache.

You may want to also add -v to the end of the boot-args to activate verbose boot, to find out if there are any boot issues, but it's not strictly necessary.

19. Reboot the system, boot into the target container, and pray. if done right, you should be able to boot into the target system, in initial setup mode.

Let me know if you have questions about the guide or issues.