Update can bring itself into trouble

[Michael Vogt]

As noted in https://bugs.launchpad.net/snappy/+bug/1458898 a SyncBootloader/handleAssets update may fail on a BBB.

If this is the case the system fails to update (which is fine). On the subsequent update(s) however it will only fetch the delta from the OS update and no kernel because the "other" partition is marked to have a very new system. It will download only this delta which lacks the new kernel. The subsequent update is successful because /boot/uboot was not touched. But the reboot fails because the kernel is from the old system but the modules get loaded from the new system that only contains modules for the new kernel and not the old kernel.

To illustrate hopefully better.

Let:
- system-a have version 1 (kernel v1)
- system-b have version 10 (kernel v10)

Then:
1. snappy update runs
2. updates the base system and updates /etc/system-image/channel.ini as part of this to version 10
3. tries to install kernel v10 into /boot/b but fails and the upgrade fails as expected

*but*
4. snappy update runs again
5. update notices that the system-b has version 10
6. nothing to download, certainly no kernel
7. claims to have updated and asks for reboot
8. reboot into system-b, kernel v1 boots and tries to load "nls_8859-1.ko" from /lib/modules/v1
9. emergency shell because it can not mount /boot/uboot (needs the nls module) there is no modules for v1 on system-b, just modules for v10

[Michael Vogt (mvo)]

Another robustness issue:

The key is that the new OS version in $other/etc/system-image/channel.ini must only be written *after* everything got installed correctly.

[Leo Arias (elopio)]

We no longer have two partitions, all the three components involved are snaps, and everything is mounted from the squashfs file that we download from the store. So I think this is solved.

If you think there's still a hole where this problem can happen in the new system, please report a new bug.

Thank you!