The Wiki needs an FAQ entry on how the update process for OSMC works. Much of what I’m writing in this post could be way off, simply because I’m not sure I understand the details.
By reading here, I see posts about backing up before update, the possibility that a bad update could brick the device, etc. Some of this would be difficult for non-technical users to understand, like where do you place the backup so that it is safe (SMB browsing being broken doesn’t help here), what is the backup for (it appears to be just Kodi user settings, but misses some important files that people here change, like Lircmap.xml), and some is downright scary (like the bricking part).
I’m pretty experienced with the Debian update system, and I can’t see how an update could ever “brick” the device. Sure, it could make it not boot, or it could make some hardware not function, but then all you have to do is boot off the old kernel, and at least you’d have SSH available, even if Kodi, etc., isn’t working right. From there, you could roll back to older versions of packages (either through restore from backup, or apt and forcing a specific version), and everything should just work again.
So, it really looks like the only missing step is a way to select a different kernel at boot time (like in normal grub installs), and then either a minimal graphic recovery system, or a text-based one. You could even leave a cache of the last known good versions of crucial packages (like the vero3-* and mediacenter-* packages), so that a downgrade/revert doesn’t even need a working network. Now, it might require that the user get a USB keyboard plugged in if the default remote is hosed, but that’s not too much of a hardship for most people.
On the other hand, if an update re-images the system, then that’s doing it completely the wrong way, since then every little change a user has made that isn’t part of Kodi (adding apps through My OSMC, tweaked network config, lircd changes, anything using apt-get, etc.) has to be re-done.
I’ve dealt with this sort of “update via image” in VMware ESXi, and it doesn’t take me long to create a script that I run after an image upgrade that puts back all the config changes that the system designers forgot that people might want change. At least with that, the new image only wipes the boot device, which is usually quite small. Here, it will nuke everything, including the extra 12GB on the Vero 4K that are available to the user. If imaging is the way to go for upgrades, then it should be a partition image that is only as big as necessary (maybe 4GB), leaving the rest of the NAND available and untouched for a user to create and mount partitions.
And, again, for less technical people, that means that even one little custom change that they managed to work through after hours of reading this forum and other Internet sources becomes not worth doing. And, if they can’t keep the setup they want, maybe they drop OSMC/Vero for something else, and warn other people not to buy.
