{"id":32970,"date":"2021-06-30T16:56:25","date_gmt":"2021-06-30T20:56:25","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=32970"},"modified":"2021-06-30T16:56:25","modified_gmt":"2021-06-30T20:56:25","slug":"why-you-cant-roll-back-big-surs-system-volume","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/06\/30\/why-you-cant-roll-back-big-surs-system-volume\/","title":{"rendered":"Why You Can’t Roll Back Big Sur’s System Volume"},"content":{"rendered":"

Howard Oakley<\/a>:<\/p>\n

\n

If you as a user make a snapshot of the System volume, you’ll get an unsealed replica of the System volume that can’t be used to replace the new sealed snapshot, and hasn’t even been blessed to make it bootable. Trying to roll back to that would only end in failure.<\/p>\n

What has been tried earlier in Big Sur is preserving the previous bootable sealed snapshot rather than deleting it once a macOS update has been completed. This isn’t a cheap option, though: it would probably require up to 15 GB of free space on the System volume. Because of that, macOS would need to remove it automatically after a period of a week perhaps, which sets a time limit on its use for a rollback.<\/p>\n

It’s unclear why Apple doesn’t provide an option in its updaters to automatically preserve the old snapshot for a maximum of one week, to support rollback over that time. Unfortunately, it’s not something the user can achieve any other way.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n