Today in Tedium: There was once a time where downgrading from one piece of software to another was as easy as pointing your autoexec.bat to a different folder and switching to a different version of Windows. But as our computers become less repairable and stuff is more soldered in, the process of downgrading is destined to get harder. (Ever try doing it on a smartphone?) I learned this the hard way recently, when I found myself having to downgrade from a public beta of MacOS Monterey on my M1 MacBook Air. And it led me on an adventure of complications that I do not recommend, a classic in the form of yak shaving. And I wanted to highlight just how screwed up it was that it even happened, so that others are aware, and they don’t fall into the same trap. Install carefully! — Ernie @ Tedium
The Prepared is a newsletter for non-engineers who love engineering
As 19th-century American settlers headed west, the United States postal service followed along in lockstep, mirroring migration patterns, politics, and the nature of the federal government. This week, we feature a conversation with author and historian Cameron Blevins about the surprising history of the USPS. Subscribe for free today!
Today’s Tedium is sponsored by The Prepared.
What led me to install the Monterey beta
So the reason I wanted to install Monterey is rooted in the fact that I wanted to test out Monterey—but, additionally, I wanted to see what it was like to virtualize MacOS in Parallels on the M1 processor. This was a marquee feature of Parallels Desktop 17, which was just released a little over a week ago.
Now, a clear use case for running a virtual machine using a tool like Parallels is to virtualize an operating system newer than the one you’re running for testing purposes, so you could get a feel for the interface and understand where bugs might be in the process.
But no, that was not what the virtualized Mac-in-a-Mac setup offered. Because Apple is still trying to work out the kinks of its virtualization approach on the M1, apparently, it requires you to run the Monterey virtual machine on Monterey. And there were some limitations in the format—for one thing, it did not support any changes in settings. You couldn’t throw more RAM at the VM, or increase the size of the virtual disk. It was basically a black box of sorts, and nothing like the VMs you can usually use on Parallels.
I get that Apple is building a new architecture, but it feels like Apple may not fully get the convenience factor of running a virtual machine if this was what I had to go through to run Monterey even for testing. So I tried it, and it worked, even if I uncovered some limitations with Parallels in the process.
Now, Monterey was a little buggy for me in aspects that I considered important—namely webcam quality and audio recording quality—so I thought, hey, let’s downgrade. I have a backup. How hard could it be?
In the hands of someone who hasn’t perhaps Hackintoshed a laptop before, these might have been famous last words. But for me, personally, they were still still extremely annoying.
The many steps it took for me to get my machine working correctly again
So the process of downgrading from the current version of MacOS to the previous version was an annoying stew of terminal commands and increasingly complex tactics as, for nearly a week, I did not have full control over my computer.
Let me break down my process, step by step:
- Download the Big Sur package. Installing the package for Big Sur was a GUI-driven process, but it was the only part of the only thing that could be considered user friendly. If you clicked on the app in Monterey, it would report the app as unable to load.
- Run a command to create an installer USB drive. With a trusty flash drive (which I had to connect through a dongle, of course), I was able to run a command in terminal to create a bootable installer for Big Sur. Why doesn’t Apple offer a graphical interface to do something so basic? Ask them!
- Run the installer from the USB. During this process, I had to basically reformat the old drive to install the operating system fresh. This part of the process seemed fairly normal.
- Restore the backup using Time Machine. I had a backup of my data from before the Monterey install, so I had that ready to go upon reboot. However, this was a particularly slow process, taking four and a half hours to complete for about 500 gigabytes of data, despite the fact I was using a high-speed NVMe drive in an enclosure, connected over USB-C.
- Load up MacOS, and realize there was a problem. So things seemed OK at first, but then I tried loading an application I regularly use, Rogue Amoeba’s Loopback, and found that the process would not work at all. The process of making Loopback work on Big Sur is already needlessly complicated, requiring logging into the M1’s recovery mode, lowering the system’s security settings in Startup Security Utility, and typing in a specific command. (Dear Apple, if you’re reading this, this is a crappy user experience!) But on the plus side, it exposed a problem that could have been a huge headache down the line. As I was trying to lower the system’s security settings, I ran into a strange error: “No administrator was found.” I was not the first to run into this error, but nothing I did could fix it. I could not create new accounts on this machine. No terminal command I tried seemed to work. It was an Apple problem, but I was the one who had to solve it.
- Call Apple support. I tried explaining my problem to them, and they offered a few ideas, but nothing I tried would work. They eventually offered a few suggestions, and after I got those, I kept working. Now, the laptop was technically usable during this time, it was just sort of untenable in case of an update, because the machine would become impossible to use.
- Flash the machine using a tool called Apple Configurator 2. Remember that time when setting up your laptop required the use of a completely different laptop? No? Well, that’s what I had to do here, using a tool intended for system administrators to fix my home laptop. I had to boot my laptop into DFU mode, a device mode better known for restoring devices on iPhones, but now possible to use on MacBooks. The process of setting the machine in DFU mode required pressing a specific key command in a specific way, and waiting for the other laptop to detect it. Once I got it to detect (it took about half a dozen tries to get DFU mode to take), this process took about 20 minutes. But the interesting thing I heard from technical friends of mine while doing this was sort of general concern that it would brick the machine. The Apple guy seemed nervous I’d take this approach during our support call. But I did it, and it booted.
- Set up a new account, then restore the Time Machine backup. I wasn’t taking any chances that I’d restore the machine with no ability to set up an account, so I created a dummy account to confirm that I could make accounts on the machine. After I did that, I did the Time Machine restore—which took another four and a half hours of my life to do, but at least this time, it did so without any broken accounts.
- Double-check everything to make sure it still works. I found that, even after the restoration, a number of tools I commonly use, including Dropbox, did not completely work the right way, and that required me to make changes to the computer to get them to work. But for the most part, we’re back to a usable computer once again.
All in, it took about a week to properly downgrade the device, access to another Mac laptop, and searching on obscure forums to find specific commands to allow something that should seem basic—installing the operating system that came with the computer back into the machine—but instead became an adventure.
I had to go through a Time Machine restore process twice, making my device basically inaccessible for about 10 hours, and I only caught a serious problem with the way my machine installed the operating system because of complex security rules that make it extremely difficult to install a piece of software I actually want to use.
And I had experience Hackintoshing—a process that can, at times, require the use of single-user mode to get things working—so I had experience figuring out stuff like this.
And to think, Apple could have saved me all this trouble had they made it possible to virtualize their beta operating system on their prior stable operating system.
Why does Apple make this so hard?
Now, to be clear, this is a computer I own, that I control, and that I’m technical enough to use in sophisticated ways. I’m a big fan of Macs, and I often find myself in the terminal to use tools such as Homebrew or to wind up a server or to fix the file permissions on something.
But even this stretched my abilities as a user of the Mac. I was able to figure it out in part because I knew where to look. If I was a less-skilled user, I would have had to go to the Genius Bar most likely—not exactly a fun thing to do during a pandemic.
And after recovering from Time Machine, I found myself dealing with locked alias files of essential folders because of my use of Dropbox, creating headaches that I could only solve by temporarily enabling the root user on my own machine. That doesn’t seem like something that a user should have to do when downgrading from a piece of beta something to something more stable, but here I was, doing it. I figured it out, but I read that people on forums who had similar issues found themselves having to work with Dropbox support for hours just trying to solve this problem.
The complexity here comes as a result of the company’s security mechanisms—particularly the Secure Enclave that most recent Macs use—which make everything more complicated when you’re trying to do something that Apple doesn’t want you to do. You know, like downgrade a machine from a public beta version of its software. The fact that I was able to downgrade the machine in a partly broken form highlights just how problematic this can be.
To offer a point of comparison here: Upon release of Windows 11, Microsoft actually makes it possible to downgrade a beta on the machine within 10 days of download by just pressing a button. Apple offers nothing like that, and beyond that makes it impossible to try out the beta of Monterey in a VM on the M1 … unless you’re already using Monterey. So you’re kind of in this weird position where, to test something, you have to sacrifice a machine that is likely the only M1 Mac that you own, and just sort of pray to the Gods of the beta that it works OK the first time.
And honestly, that just doesn’t seem logical.
Over the years, I’ve done fairly risky and experimental things with my machines in the name of additional technical knowledge … and yes, for the sake of writing stories, as I am a journalist.
I’m a special case as an end user, and I own that. So yes, I was installing a beta because installing beta software is something I do.
But I think there’s a fair assumption that properly downgrading the operating system on a computer should require less technical knowledge than literally having to flash the machine on a separate computer using a piece of software designed for system administrators at large companies.
The downgrade process shouldn’t be left half-completed because of some security limitations that the end user played no role in designing or implementing, leaving a happy surprise at the end of the process. The expectation among end users is: I put the operating system on a flash drive, I reinstalled it, and it works. Had I not been digging in recovery mode for the sake of a kernel extension, I might not have caught that problem for months—at which point it could have turned from annoyance to serious problem for which I wouldn’t have been able to pinpoint the cause.
This is a machine I physically own, that I activated with my own passwords. That I was able to prove was mine every step of the way. But because of the complexity of this process, the end user no longer feels fully in control, even when they’re having to make changes to the file structure as root.
So this is about 2,100 words to ask Apple: Hey, make downgrading something that mere mortals can do.
--
Find this one an interesting read? Share it with a pal—especially if they installed Monterey recently.
And thanks again to The Prepared for giving us a push. Reward them for helping us by checking out their newsletter.