I’m thinking about implementing live OS patch by client. Colibri machine is headless with www and other controls. To update whole root FS, which may be required having new BSP version, I’m going to trigger from www fw_setenv command to change U-Boot’s bootcmd to perform setupdate and update on reboot, restore bootcmd back to notmal bootup after update.
But whole root FS update will require some reconfiguration from client. So it is necessary as well to be able to perform smaller patch rather than whole RFS. After receiving update command it would be nice to switch runlevel to perhaps no network level, patch files from tar on USB key and switch runlevel back to graphical.target or multi-user.target. The question is which level or target? runlevel1 is rescue.target, which asks for user password, so bad choice. All other higher levels are linked to multi-user or graphical.target… So the only choice is to stop/restart services which are about to be patched?
As well there’s an runlevel issue with WiFi. I have connmand configured to connect to user configurable AP. After bootup it connects well. But if I do
systemctl isolate default.target
or
systemctl isolate multi-user.target
or switch to rescue then back to mult-user.target, then WiFi doesn’t connect any more. Any missing connmand setting? It connects well after bootup, doesn’t reconnect changing run levels, as well disconnects switching to current level (multi-user.target). Why does it disconnect if runlevel doesn’t change?
Another question regarding WiFi what is where is the best place to set regulatory domain (iw reg set XX)? I’m doing it from one of my services. Shouldn’t there be dedicated place for default setting? Since there is connmand, should I still edit wpa_supplicant.conf or iw reg set from my services?
Well, if that matters VF50 V1.2A, VF61 V1.2A, IMX7D V1.1C, Iris V1.1A. That’s for development. We are using our custom carrier board.
Application - serve some protocols on CAN, RS232, USB serial gadget, and TCP ports. The problem is that it has no keyboard, no display, everything has to be configured over network (wired ethernet and/or WiFi). As you understand it is not friendly for users. Another problem how to let users upgrade some of our services and/or whole BSP with minimum efforts and the most comfortably?
Triggering fw_setenv bootcmd, followed with reboot is fine to upgrade whole BSP. But that triggers the need to reconfigure network settings again, which is not nice for our users.
Looks like I didn’t notice and understand that connmand doesn’t connect to WiFi in case eth0 is connected. This explains why I was loosing wlan0 connection changing runlevel, it just didn’t reconnect to secondary connection if eth0 was well and connected.
I made some progress regarding my previous questions. It seems it is enough to overwrite /var/lib/connman folder with previously backed up settings. Connman seems reconnecting well without changing run level. If not I may reboot.
Regulatory domain, though it’s weird Linux iw reg set doesn’t take care to make it permanent, will be restored from one of our services.
The most problematic is full BSP upgrade. Looks like I need to let users put configuration backup file to USB key/SD card and automatically start service to look for network config file, restore if settings are available.
I still don’t understand your product and application, but providing an update procedure as you described would be a very difficult task. Especially for the module type you are using.
I would rather suggest you to have a look at Torizon our latest Toradex labs project which will integrate OTA update functionality out-of-the-box.
Thanks for your efforts trying to understand. Well, I made further progress and see light in the tunnel implementing what I need, kind of working already.
Regarding Torizon, OTA sounds great, but without spending a lot of time I don’t see how will it work. OTA, do you mean automatic updates? How much then? OTA sounds great, but what if update suddenly breaks our own services? It could be worse than no updates at all… Is it going to be updated from our own servers, where we put only verified to work updates? But thanks, I hope I’ll look better at it later.
The OTA that Torizon will implement, in short is a file-system based update that is capable of updating the entire root file system (OSTree). The update packages can be provided/defined by either you or Toradex (for general system updates). These updates can then be deployed at your discretion. In the scenario of a “bad” update the system can also roll back to a previous update.
The idea would be that the TorizonCore OS would provide a foundation that is capable of OTA updates, with Toradex providing a well-tested (paid) service. Alternatively, there are open source tools that we have built our OTA service on that can be used in place (with some work on your end) for no cost. As for the infrastructure side, similar idea either Toradex provides the infrastructure at a cost or you can stand up your own. Just a note that the monetization details of OTA are still quite early with no hard numbers.
As for the verification, our OTA is Uptane compliant meaning every update is signed and verified by a trusted user either you or Toradex before it is pushed to the server.
I hope this helps clear up some of your questions about our up-and-coming OTA service. I’m more than happy to go into further detail if you wish.
