Feature #731


Automate upgrades

Added by Hammel about 4 years ago. Updated 9 months ago.

In Progress
05 - Releases
Target version:
Start date:
29 Nov 2019
Due date:
% Done:


Estimated time:
02 - High


Use the tools created by RM #730 to automate an upgrade. This probably requires a daemon or at least a cron job to check for upgrades and install them.

Related issues

Blocked by PiBox - Feature #730: Add upgrade toolsNewHammel29 Nov 2019

Actions #1

Updated by Hammel over 3 years ago

  • Priority changed from High to Immediate
  • Severity changed from 02 - High to 03 - Medium
Actions #2

Updated by Hammel over 3 years ago

  • Severity changed from 03 - Medium to 02 - High
Actions #3

Updated by Hammel over 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
Now that PiBox boots with a squashfs/overlay for the rootfs the upgrade is actually pretty straight forward.
In the Busybox init:
  1. Before mounting squashfs, check if a new squashfs exists.
    1. This would be in /mnt/user/upgrade/rootfs-new.squashfs
    2. If it exists
      1. save the old squashfs to /mnt/user/upgrade/rootfs-old.squashfs
      2. install /mnt/user/upgrade/rootfs-new.squashfs to /mnt/root/overlay/current/squashfs/rootfs.squashfs (or what current points to)
    3. Continue booting

There should be a new package that does a validation of the system on the next boot to make sure it's working. This validation is system specific - it's different for the dev platform, media system, piplayer, ironman, etc. If validation passes then rootfs-old.squashfs is removed. If validation fails then the system reboots and init removes the new squashfs and restores the old one.

Note: this isn't exactly correct. The "current" points to an image id. The upgrade should be installed to a new image id directory and the swap between old and new is just a matter of changing the current symlink - don't move the files around!

This also only works if the new and old are compatible so any packages installed on the old won't break with the new. This can be handled with a versioning test that disables/uninstalls packages that are not compatible with the new, but I need a definition of how this versioning would work. One way to do that is to have whatever mechanism is used to grab the new rootfs also check for new packages that match the existing packages on the platform and download them too. Then place a stamp file that packages need to be updated on the next boot.

Actions #4

Updated by Hammel about 3 years ago

  • Priority changed from Immediate to Urgent
Actions #5

Updated by Hammel 9 months ago

  • Target version changed from 2.0 - Harkonnen to 3.0 - Corrino

Also available in: Atom PDF