@neil: the point being - when we have not even tested out an OTA yet - this will be the first one - at that stage absolutely insisting that the OTA also manage to retain all sorts of unsupported user-mods, and not listening to the explanations of why thats not possible - thats where the issue is. I saw a post earlier where it was advised to lock the “outernet” login, add a new userid, change its password, etc. How is an ota supposed to handle such things? I need to make sure that OTA ends up in a known device state. Is it that much work really to simply change the password back after the OTA? There is no reason why anyone should get in such a huff about something that basic.
And honestly: show me another system which does OTA of a 150MB rootfs + support files, over a 2kbps, unreliable, unidirectional link, on a very resource constrained device, without user assistance. While the overall datacasting approach is itself innovative, I believe the OTA system is also un-equalled. And I want to test that out - see how it performs in the field. When people who genuinely don’t have internet access use this device, they won’t be able to update any other way. So OTAs are absolutely critical to the Outernet setup. If/When the OTA works - it would be a big achievement in its own right, even though I say so myself.
Instead of talking about that, we have been sidelined to a completely different topic. The user in question could very easily just change the passwords back after the OTA. Absolutely demanding that their mods be supported by the first-ever OTA and refusing to listen to all the explanations - thats just…not ok.