Upgrades using kairos-agent with a local file source fails

[nano2007]

I am trying to use kairos-agent to upgrade an air-gapped system. The command I use is (2544.tar is an image archive generated using docker save):

sudo ./kairos-agent upgrade --source file:/home/rancher/2544.tar

warning: skipping /oem/.userdata_load because it has no valid header
warning: skipping /oem/grubenv (extension).
INFO[2023-06-06T12:33:08Z] kairos-agent version v2.1.0-rc6
INFO[2023-06-06T12:33:08Z] Applying 'before-upgrade' hook
INFO[2023-06-06T12:33:08Z] Running before-upgrade hook
INFO[2023-06-06T12:33:08Z] deploying image /home/rancher/2544.tar to /run/initramfs/cos-state/cOS/transition.img
INFO[2023-06-06T12:33:08Z] Copying /home/rancher/2544.tar source...
INFO[2023-06-06T12:33:12Z] Finished copying /home/rancher/2544.tar into /run/initramfs/cos-state/cOS/transition.img
ERRO[2023-06-06T12:33:27Z] Failed to apply label COS_ACTIVE to $s%!(EXTRA string=/run/initramfs/cos-state/cOS/transition.img)
ERRO[2023-06-06T12:33:27Z] Failed deploying image to file '/run/initramfs/cos-state/cOS/transition.img': exit status 1
1 error occurred:
* exit status 1

[nano2007]

Digging a little, in the case of file:<source_file>, source_file is expected to be a disk-image? Can we extract the tar.gz file from the docker saved tar file and generate the image file out of it?

[mauromorales]

moving to kairos main repo so it gets visibility

[liouxiao]

any progress? still encounter the same issue with kairos-agent version v2.1.3

[nano2007]

any progress? still encounter the same issue with kairos-agent version v2.1.3

I use a workaround for now. If I use the tar file generated as part of the osbuilder process (I created a custom build after looking at how osbuilder works) to upgrade, it works. The tar file generated contains the /build/rootfs directory.

tar -czvpf test.tar -C /build/rootfs . && luet util pack cfnc test.tar myproj.tar

Then I use the myproj.tar to perform an upgrade:

#!/bin/bash -x

upgrade_archive="$1"
echo "Extracting upgrade file from ${upgrade_archive} ..."
unarchive_dir=/tmp/unarchive
mkdir -p ${unarchive_dir}
rm -rf ${unarchive_dir}/*
tar -C ${unarchive_dir} -xvf ${upgrade_archive}
upgrade_file=$(ls ${unarchive_dir}/*.tar.gz)

mkdir -p ${unarchive_dir}/tgz_contents
# though the file is named tar.gz it is only a tar file.
tar -C ${unarchive_dir}/tgz_contents -xvf ${unarchive_dir}/*.tar.gz

echo "Upgrading CFNC ..."
/opt/certes/kairos-agent upgrade --source dir:${unarchive_dir}/tgz_contents

# Check if the upgrade was successful
if [[ $? -eq 0 ]]; then
   echo "Upgrade completed successfully. You should reboot the CFNC for the changes to take effect."
else
   echo "Upgrade failed."
fi
rm -rf ${unarchive_dir}

This is not ideal, but works for now. I believe the change to support upgrade from a local oci image shouldn't be hard, but I haven't got time yet to explore the kairos-agent code on how to do it.

[Itxaka]

actually a feature :D

As we now support different sources for the upgrade, the underlying --file was in there but never tested. This seems like a good feature to have.

[gbevan]

I found a docker export of a stopped container from the image you want to upgrade to, will work when untarred into a folder and processed with kairos-agent upgrade --source dir:d/ - similar idea to what @nano2007 did above...

[Itxaka]

I had a look at the source for this and could find what this is about.

File source is meant to install/upgrade from a system image file, so an image built like our active/passive/recovery
The upgrade just picks the image and copies it directly into the system subsituting the existing one, so its a basic copy
Not sure if this is useful or has been used ever.
Maybe a change in behaviour to make this work for oci images dump is much more useful, so we can dump an image from a repo, copy it into an usb and use it as the upgrade source.

[Itxaka]

Ah, reset uses this file source to reset the active and passive using the recovery image, so it just copies over them, so we cannot rework this as its being used.

I propose a new source called ocitar or something similar (oh god, Im no good with names) that its for an extracted tar file from an OCI source, so its clear that its meant for that exactly.

[cheese]

I propose a new source called ocitar or something similar (oh god, Im no good with names) that its for an extracted tar file from an OCI source, so its clear that its meant for that exactly.

I suggest to follow CONTAINERS-TRANSPORTS(5) schemas.

[Itxaka]

Good link, seems the original implementation was based on that, should be ok to keep expanding it with the other entries