Closed kernelgurumeditation closed 7 months ago
@jimaek
Container update in Firmware V2
A container version is still bundled when the firmware is created, this is the initial version. A process called jsdelivr-updateContainerAuto.sh periodically checks for updated containers, the periodicity of this check is between 1 day and 2 days. If a new version is detected, it is downloaded to a special partition(mmcblock0p4), after the download finishes, it's compressed and copied to the container partition(mmcblk0p3) In case a previous update was already present in (mmcblock0p4), only the delta between the current version and the newer is downloaded. This new version will be used from the next reboot onwards The next reboot will be ordered(in normal status) by the jsdelivr-mandatoryReboot.sh and the time interval for it will be between 2 and 5 days. If, for any reason, the container fails to start (corruption in the file/card or bug in the container), the jsdelivr-systemWatchdog.sh script will reset the system to use the bundled container. After the probe returns to normal function, it will be updated by the automatic process. During the container update, the probe software continues to work nonstop.
If, for any reason, the container fails to start (corruption in the file/card or bug in the container), the jsdelivr-systemWatchdog.sh script will reset the system to use the bundled container.
Let's say the container updates successfully 10 times over two years. Then 11th update fails. Does it return to the 10th (previously working) version or to the very first, two years old version?
Closing this, Given the changes in the container hub, I need to redo a portion of the system to handle Skopeo limitations when run on an embedded system.....
Don't merge it YET! ->STILL UNDER TESTS <-
includes: Fix for the SSH host keys changing at every boot Automatic container update feature New user "devlogs" to enable checking for firmware logs