We attempted to upgrade a remote Mac running Mojave and ran into the macOS upgrade bug. This post walks through the steps we took to remotely recover the Mac and finish the upgrade.
I got a shiny new M1 Max MacBook Pro this week. When I setup new computers I tend to opt for setting them up new and transferring the data over “manually”; i.e. not using Migration Assistant.
I started this migration the same way that I traditionally have, using Share Disk (formerly Target Disk Mode (TDM)) and
rsync. I made a few observations and, in the end, changes to how I’ll be doing data migrations going forward.
Recently I’ve been trying to get a KEXT to load in Big Sur on both Intel and Apple Silicon Macs without requiring an admin user to approve loading the KEXT and avoiding Apple Silicon’s “reboot into recovery to allow KEXT loading” bit.
This post will cover the MDM profile I’m deploying along with some commands that I used to help with testing KEXT deployment and approval on Big Sur.
- macOS 11 host and guest
- VMware Fusion 12.1
- Download and install VMware Tools 11.2.5 or later
- Edit the VM’s VMX file
- Right click the VM
- Hold the option key
- Click Open Config in Editor
Those of us getting the new M1 Macs quickly found out that the traditional way of wiping a Mac using Disk Utility no longer works as expected. When using this method we’ve found numerous bugs and it typically leads us to needing to DFU the M1 Mac and use Apple Configurator 2 to completely wipe and restore it.
Here is the best way that I’ve found to completely wipe and reload an M1 Mac.
With the M1 Macs out and getting my hands on an M1 Mac mini, I got curious which applications are installing as Universal Binaries for ARM, and which are x86 only and need Rosetta 2 to run.