Why You Can No Longer Roll Back a macOS Update
As some of us learned in the last week, it’s easy to uninstall a troublesome Rapid Security Response (RSR). Several naturally asked why that isn’t possible with a macOS update, pointing out that it was available and worryingly popular between High Sierra and Catalina 10.15.2, since when the ability has been lost.
[…]
To be able to roll back to the previous SSV, all the firmlinks between the updated SSV and the Data volume would have to be broken, and remade between the old SSV and the same Data volume. All the evidence is that wouldn’t be easy, could be unreliable, and may not even be feasible. Without that, roll back couldn’t work.
This pretty disappointing, as it negates a major benefit of APFS snapshots. It’s not clear to me that the SSV is more useful than being able to roll back a bad update. And rolling back manually, e.g. using a backup utility to make or restore bootable backups, is harder than before. I don’t really understand why firmlinks are so difficult to work with—is there an intrinsic limitation or was this just not prioritized? If the two pieces can’t be made to fit together, I wonder why Apple designed the SSV this way. There must have been other ways the content could be verified.
Although traditional Unix architectures bring some separation, there are many directories that contain mixtures of files, some that are part of the system, and others that the user installs. The solution Apple’s engineers came up with is the firmlink, an essential part of the structure and function of macOS since Catalina.
[…]
Apple has never documented firmlinks in any detail, and doesn’t provide the user with any tools for working with them. They don’t appear to be easy to create, though, and rejoining existing volumes using firmlinks may not be possible. During the early days with Big Sur, it was all too easy to end up with orphaned Data volumes that had lost their firmlinks to the System volume. At that time, it appeared that firmlinks had to be created early in the life of a volume, probably before its file system had been populated with files. Currently, there doesn’t appear to be any method for the user to join together any given pair of System and Data files using their firmlinks.
Without wishing to deepen the conundrum, all these answers are correct: the System volume isn’t itself encrypted, but it can only be mounted when FileVault has been unlocked, because of the firmlinks that splice the Data volume into it.
Previously:
- Rapid Security Responses Pulled Due to User Agent
- Disk Utility in macOS 13.4
- Rapid Security Response
- Why You Can’t Roll Back Big Sur’s System Volume
- The Role of Bootable Duplicates in a Modern Backup Strategy
- Mojave Security Update Removes Support for Automatic Snapshots
- Is Big Sur’s System Volume Sealed?
- APFS Snapshots of the Big Sur System Volume
- Creating Root-level Directories and Symbolic Links in Catalina
- Backing Up macOS 10.15 Beta
Update (2023-08-04): I got a volume hash mismatch.
3 Comments RSS · Twitter · Mastodon
For years after APFS I was saying they will eventually invent FreeBSD boot enviroments. They now seem determined not to.
The only way I've seen to work with these links is with the `synthetic.conf` file. In that case though you are restricted to creating your own links, not repairing existing ones.
The only thing I see that could maybe help recreate synthetic links is the `-t` option of `apfs.util`. I've not tried it though.
