Question: Why we do not carry the changes on upgraded version to old version when we boot from the older partition?
The simple answer is - we want to retain the logic of rolling back to the older image .
1. The reason to have two partitions on CPPM is to make sure we upgrade the current configuration and data to newer version and keep the other partitions as it is. Once the upgrade is done. Initially the OS will be installed on second partition and the second partition will now become a Active partition.
2. Once the server is rebooted/restarted after the upgrade, the database from the first partition will be converted at the backend onto the new partition. This may take time depending upon the amount of data that is present.
Note : we are only converting the data to second partition. The data on first partition stays intact.
3.The reason to have the upgrade on new partition is to make sure for some reason the upgraded version hit any road blocks or corruption we can always boot the server with non-active partition and have the server working.
4. If there are any changes made to configuration (like adding services etc) or data (by adding guest accounts etc) after the upgrade, when we revert back to old version these changes will NOT be present. The reason as stated above the database on second partitions stays intact and we are just booting off with that partition and NOT converting the data.
Question : why we do not carry the changes on upgraded version to old version when we boot from the older partition
Answer : Major release always have changed database tables or new database tables as result of adding new features. When we boot off from older partition which has older code, the database conversion may fail as the newly added tables or columns to existing tables would not be present.
Also, the expectation to boot from older image is when the newer version has any db corruption or crash. If intended to convert the db when we boot on older image the database corruption could carry to the older version and server would be become unusable.
Any issues seen after the image upgrade please open a case with firstname.lastname@example.org to address the issue. The option to boot from older partition is given to ensure that there would be no production impact if the upgrade fails or have some other issues. We keep the configuration and data on two separate partitions. whatever changes made on either boot partition will not be reflected on other partition.