canupdate.sh

Maybe somebody could give me a hint on how to check canupdate.sh is working or explain the sequence, how (or in which sequence) the update should work...

I am playing around with the update.tar file on my Cubox system to check and prevent upgrade of unsupported installations. (i.e. kernel too old, bootloader not using extlinux.conf...)

I added some echo messages for debugging to my canupdate.sh script just before the script decides if update/upgrade is supported or not.

After placing the update file in the .update folder, rebooting, a new .tar archive is found, extracted and kernel, system file and dtbs are updated, system reboots, finished.

My canupdate.sh script is placed in SYSTEM:/usr/share/bootloader, just beside the update.sh script, the two files for u-boot and all of those device tree files.

Do I have to add a call to canupdate.sh to the update.sh script to get this working?

I am also not sure if the sequence of update/upgrade is correct: I am facing a problem on my productive installation (v7.0.1), where kernel and system files get already replaced before mounting the new system fails. (so no access to the canupdate script and no warning message for upgrade not supported) - the system is stuck in the end.

If using the latest v8.2.5 image and trying to apply the update, also no debug information appears indicating my canupdate.sh was executed, the mounting of the new system fails, but here the system is still working after reboot.

So at this point, it seems for me, there is no way to prevent update/upgrade on unsupported older installations...

Quote from chewitt

I appreciate the desire/intent to support a nice upgrade experience, but IMHO the simplest and best option is to force a clean install and not attempt to handle upgrades and migration from legacy images.

I fully agree. I was not looking for a way to provide an upgrade routine for the old installations. I was just wondering how to prevent a "DAU" from trying to upgrade such an old installation and getting a messed up installation.

So at the moment, the canupdate.sh script fails for the imx6 platform:

for installations < v8.0: They will not expect a canupdate script, update will proceed until mount of squashfs fails due to the newer zstd format and leaves the actual installation messed up

for installations >= v8.0 (< v9.8/nightly): the script should be executed and should stop the update as $ARCH is "imx6" and not "iMX6". This also fails, as the mount of the squashfs (in which the canupdate script resides) fails due to the newer zstd format.

for installations >= v9.8/nightly there is no need for this script at the moment, as there is only one $ARCH for the project.

So in the end, it should be mentioned in the (future) WIKI, that for the recent images a clean install is forced.

Just to finish my investigations:

Either I didn't get the config right or it seems not to to be working on newer installations too. I started with a recent nightly build and prepared an update tar with canupdate.sh set to

#!/bin/sh
if [ "$1" = "imx6.arm" ]; then
  exit 0
else
  exit 1
fi

Placed the script at different positions (root of update.tar, inside folder /3rdparty/bootloader and also in the squashfs beside the update.sh). Result each time: Update of the running system.

Do I still use a misconfiguration of canupdate.sh or was its functionality removed from recent the project?

Quote from chewitt

Your current script passes imx6.arm as $1 (the $PROJECT.$ARCH of the current image) to the script which evaluates true (exit 0) so the upgrade continues.

I was trying this on a recent nightly build of LE, which should pass "iMX6.arm" to the script and then exit with 1...

But busybox threw a monkey wrench into our works. Its init-script checks architecture of both, current image and update image ('fake'-check of /etc/os-release, not the real running architecture). Only if they differ, it will look for a canupdate script. (and btw, canupdate could then also 'echo' debug information to the console, at least on my cubox it did)

So indeed canupdate.sh could be used to control update of arm/aarch64 systems of the same (or even different) $project.

But as long as both have the same architecture, it could not be used to evaluate not to update older kernel versions.

So I guess, a Rockchip Tinkerboard LE 9.0 will be upgraded by an RK3288 LE 9.8 image although using a kernel version 4.4? (Rockchip.arm == Rockchip.arm -> no call of canupdate.sh, just call update.sh)

Also a RK3288 LE 9.8 system accepts an RK3399 LE 9.8 update.tar (stupid user mistake) and gets stuck due to the new aarch64 kernel? (Rockchip.arm != Rockchip.aarch64 -> call to canupdate, which will return 0 and update continues...)

Maybe it's a good idea to check that, before releasing official images of Kodi19/LE10, JM2C