I was thinking more of having a transactional system within the update software itself independent of anything on the filesystem.
Something like this:
1. Download all compressed archives that are required for the update from the update website and unzip somewhere.
2. Check the package manifest and figure out which files need to be changed/added/deleted.
3. Write a flag somewhere on the boot drive that says the update process has begun and which files will be altered.
4. Make copies of all the files which will be changed.
5. Work through the update process by modifying or overwriting the copied files with the contents of the update archives.
6. Temporarily suspend the scheduler so the update process is the only thing running and release locks on all of the files which will be changed.
7. Work through every file that needs to be changed and link the filesystem reference from the old version to the new version whilst keeping a copy of the old version.
8. At every stage in 7 mark in a log which references have been updated.
9. Mark a flag to indicate that the update process has been completed, either resume the scheduler and re-instate locks or force a restart of the OS if necessary.
When the system next starts up as part of the bootup process it can check if both the transaction start and finish flags are set.
If the start flag is set but not the finish flag then it knows that an update failed so it can roll back by re-linking to the old versions of every file (reading the logs to know which files to re-link) and setting the start flag back to 0 so it can try again.
If the update was successful then it can delete the old files if the disk space is needed or keep them around in case there is an issue later which required a restore.
In regards the kernel example, my Linux install actually keeps old versions of the kernel on the system so that if a kernel update breaks something for whatever reason it is still possible to boot the system from the previous kernel. I imagine Windows and OSX do something like this , although possibly more transparently.
Note: This is what I could think of off the top of my head, I'm sure it's not a perfect way of doing it but it demonstrates the idea.
I don't know if it follows those exact steps, but in the last few months I had several times a machine crash (flaky power supply) in the middle of various Windows Updates and it always recovered pretty well. It looked to this outsider like there was some sort of journalling going on.
Something like this:
1. Download all compressed archives that are required for the update from the update website and unzip somewhere.
2. Check the package manifest and figure out which files need to be changed/added/deleted.
3. Write a flag somewhere on the boot drive that says the update process has begun and which files will be altered.
4. Make copies of all the files which will be changed.
5. Work through the update process by modifying or overwriting the copied files with the contents of the update archives.
6. Temporarily suspend the scheduler so the update process is the only thing running and release locks on all of the files which will be changed.
7. Work through every file that needs to be changed and link the filesystem reference from the old version to the new version whilst keeping a copy of the old version.
8. At every stage in 7 mark in a log which references have been updated.
9. Mark a flag to indicate that the update process has been completed, either resume the scheduler and re-instate locks or force a restart of the OS if necessary.
When the system next starts up as part of the bootup process it can check if both the transaction start and finish flags are set. If the start flag is set but not the finish flag then it knows that an update failed so it can roll back by re-linking to the old versions of every file (reading the logs to know which files to re-link) and setting the start flag back to 0 so it can try again.
If the update was successful then it can delete the old files if the disk space is needed or keep them around in case there is an issue later which required a restore.
In regards the kernel example, my Linux install actually keeps old versions of the kernel on the system so that if a kernel update breaks something for whatever reason it is still possible to boot the system from the previous kernel. I imagine Windows and OSX do something like this , although possibly more transparently.
Note: This is what I could think of off the top of my head, I'm sure it's not a perfect way of doing it but it demonstrates the idea.