Preemptive Update

Now I want to make two assumptions: Updates come in a temporal sequence (of course there are big chunks of updates, but you have many small updates in between as well) and ZFS Snapshotting allows you to have as many states of your system as you want.

Okay, let's assume your running system is based on the state Sys. Sys is a state of the system right from the installation media. You modified it a little bit (like new files and other stuff), so you have a state Sys'. Obviously in ZFS lingo Sys would be a snapshot and Sys' would be a clone generated out of the Snapshot Sys. Okay, now there is an update available for download. The system downloads it automatically. You clone the snapshot Sys again and call it Sys+1. The system automatically updates the clone Sys+1 with the updated packages in the background. The system places a new boot-environment in the GRUB configuration and places a transient SMF service into the new boot environment. This transient service is responsible for the reintegration of changes introduced by the user and removes itself after completion.. Whenever a new update arrives, the process is repeated by system. As long as the user doesn't boot into an automatically updated version of her or his system, nothing changes. But as soon, as he or she considers to use an updated environment, the reintegration SMF service kicks in.

The reintegration is easier as it sounds in the first place The sequence of Sys snapshots is a sequence of unmodified, pristine installations of the operating system, whereas the single Sys' contains all the user-introduced changes to the system. Obviously you have to preserve this changes while updating, but it's relatively easy to find this changes. At first: The home directories of the user have their own ZFS file system. We can ignore it and just mount it at the next start. I would introduce an additional separated file system for log files, so we can ignore it, too. File systems are cheap in ZFS. So, how do we find the changes: Another tool is helpful for this task. I've talked about it in the LKSF tutorials. It's the Basic Audit Reporting Tool aka BART. The baseline manifest would be generated out of Sys, the control manifest out of Sys'. So a bart compare run should yield all changes introduced by the admin of the system. Based on the results of bart, you can preserve the changes to Sys by copying them to Sys+1. Obviously you wouldn't copy them to Sys+1 you would clone Sys+1, call it Sys+1' and use this clone as your working operating environment.

Obviously the reintegration part is the part with all the devils, but you should consider, that we have many helpful information. For example ipkg doesn't know a global scripts to add files or data. It knows a certain set of actions for this case. When the preemptive update process detects, that there is a file in the operating environment changed by the user, it should be possible to copy the old file into the new boot environment and rerun the actions for this file.

So it should be feasible to do such preemptive updates without user interaction. I have to think a little bit more in depth about the reintegration part, but that was out of the scope of a single cup of tea