canupdate.sh

1st Official Post

    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...

    • Official Post

    I have fuzzy memory (git history will confirm) but I think we added canupdate.sh for LE v8.0. I know it was not part of the OpenELEC codebase that we forked from or the initial LE v7.0 release. The update process is controlled by the older image (not the newer) so this means there is no check against canupdate.sh when updating from older OE or LE v7.0 images. It is also not an upgrade script or place to effect complex changes. It is a deliberately simple check to see whether the update should proceed or not. The calling update script simply passes $PROJECT.$ARCH so crossgrades between arm and aarch64 of the same $PROJECT can be allowed and wrong $ARCH or wrong $PROJECT updates prevented. If the canupdate.sh script exits with "exit 0" update proceeds and if it exits with "exit1" update is blocked.

    In the current PR that I submitted I'm simply checking "if [ "$1" = "iMX6.arm" ]; then" because all "legacy" images are "imx6.arm" (not iMX6.arm) so we can fail the update. I've included an "echo" message but In hindsight (thinking about it now) I think the on-screen failure message comes solely from the update script that calls canupdate.sh and I think there is no way to pass a nice message back or display on-screen info from canupdate.sh .. the only thing passed back is the exit code.

    There are ~380 active installs for imx6 images (and approx. the same number of OE installs). Legacy LE images stopped at v8.2 and OE ended at v8.0 (which was a mess so most users remained on v7.0). Those installs are now old and we see greater problems (mostly from add-ons) when updating older installs to current. 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.

    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

    Bash
    #!/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?

    • Official Post

    The canupdate file must be at /usr/share/bootloader/canupdate.sh within the SYSTEM file either by embedding it directly into the filesystem or being picked from a "bootloader" folder at project or device level. If you put it anywhere else it will not be seen or used.

    Code
    [ "$1" = "iMX6.arm" ] && exit 0 || exit 1

    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. In the PR I've changed it to ^ this which will evaluate false (exit 1) and fail .. but as you point out, if the older image doesn't support zstd it will also fail.

    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

    Edited once, last by eTrax (February 22, 2021 at 7:23 AM).