i found a solution and was able to upgrade our open-balena server from 3.8.2 direct to the latest 4.1.x version.
this was my way. Maybe also yours.
open-balena upgrade path from 3.8.2 to latest 4.1.x
At first make a SNAPSHOT or at least a backup of your server!
Be sure you can restore your backup!
Create a server-clone, to be sure, the upgrade path is working at your system.
This is the path, which is working on our environment.
After the upgrade use the docker log --follow <container> funciton to detect error messages in the api, registry, haproxy or db container.
update server and install required packages
sudo apt-get update && sudo apt-get install -y make openssl git jq
switch to sudo balena user
sudo su balena
cd /home/balena
rename open-balena root folder, to correct prefix
Otherwise the command ‘make up’ will create new volumes, the prefix of the container volume is the name of the installation folder
The migration only works if the new system uses the old container!
mv open-balena openbalena
cd openbalena
clean up your changes
git restore compose/version
now upgrade the open-balena server to latest version
git pull
define your Main-Url of the server
export DNS_TLD=<your-domain>
Prepare docker-compose file!
nano docker-compose.yml
change the volume names to old pattern
to this by the volume definition and for the s3 and db container
db-data => db
s3-data => s3
prevent crazy load in api container
sometimes the api tries to refresh the device list.
some devices are in private repos and open-balena have no premission to show the details.
a lot of error messages appears in api container and is not available for some minutes
happens mostly by generating a new device config.
To activate a devicetype filter add this to API-Container Environment Variable section:
CONTRACT_ALLOWLIST: arch.sw/armv7hf;arch.sw/aarch64;hw.device-manufacturer/asus;hw.device-family/tinkerboard;hw.device-type/asus-tinker-board-s;hw.device-type/asus-tinker-board;hw.device-type/raspberrypi3;hw.device-type/raspberrypi4-64;sw.os+hw.device-type/ubuntu@lunar+raspberrypi3;sw.os+hw.device-type/ubuntu@jammy+raspberrypi3;sw.os+hw.device-type/alpine+raspberrypi3;sw.os+hw.device-type/debian@sid+raspberrypi3;sw.os+hw.device-type/debian+raspberrypi3;sw.os+hw.device-type/ubuntu@focal+raspberrypi3;sw.os+hw.device-type/ubuntu@focal+raspberrypi4-64;sw.os+hw.device-type/debian@sid+raspberrypi4-64;sw.os+hw.device-type/alpine+raspberrypi4-64;sw.os+hw.device-type/debian+raspberrypi4-64;sw.os+hw.device-type/ubuntu@lunar+raspberrypi4-64;sw.os+hw.device-type/ubuntu@jammy+raspberrypi4-64;sw.os+hw.device-type/debian@bookworm+raspberrypi4-64
Disable registry cache and force region to us-east-1 for s3 container
COMMON_REGION: us-east-1
REGISTRY2_CACHE_ENABLED: 'false'
repair make file
there is a faulty jq parsing command
nano Makefile
go to wait: -section and repair jq query
jq -r '.Health' => jq -r '.[ ].Health'
now we can finaly start the container
make up
allow migration of database
the db container is able to migrate the postgres database from 14 to 16 automatically.
But the API Migration Script is faulty.
The script 0074-normalize-release-contract is crashing the startup.
You have to delete this file at every ‘make up’ command!
go into api container and delete migrations file 0074*
docker exec -it openbalena-api-1 /bin/bash
rm src/migrations/0074-normalize-release-contract.async.ts
exit
docker restart openbalena-api-1
delete some wrong database entries
sometimes you see in the log (docker logs --follow openbalena-api-1) a strange output.
Error loading application config MigrationError: Failed to execute ‘balena’ model from ‘undefined’ due to: operator does not exist: boolean <> integer
To get ride of this message connect into the postgres database and delete some constraints entries from the release table.
docker stop openbalena-api-1
docker exec -it openbalena-db-1 /bin/bash
psql -U docker -d resin
show table details
\d+ release
delete wrong contraints check from release table => modify the relase$
ALTER TABLE release DROP CONSTRAINT "release$69zgYrVSJaN1avGiEeipPlJ9/lMKzOIt3iMPF6u/6WY=";
ALTER TABLE release DROP CONSTRAINT "release$RcddhgkY+99IgKXAUId7Q3iN4WylzgAxSFiF+JvyRiY=";
if you changed the domain url, tell the database where the images of your fleets are stored now.
UPDATE image SET "is stored at-image location" = REPLACE("is stored at-image location",'registry.<old-url>','registry2.<new-url>');
UPDATE release SET "composition" = REPLACE(composition::Text,'registry.<old-url>','<new-url>')::jsonb;
\q
exit
restart api container
docker start openbalena-api-1
check for unhealthy container and restart them
docker ps
docker restart openbalena-vpn-1
finalise the upgrade
if you have used a selft signed cert, i have no solution.
we switched to cloudflare.
only so our old devices are able to reconnect again.
i found no way to use the old self-signed certificates (we changed the url…)
sudo su balena
cd /home/balena/openBalena
add cloudflare credentials
nano .env
ACME_EMAIL=<your-user>
CLOUDFLARE_API_TOKEN=<your-token>
and/or
export ACME_EMAIL=<your-user>
export CLOUDFLARE_API_TOKEN=<your-token>
activate the cloud flare certificate mode
make auto-pki
make verify
api container resetet => delete faulty 0074* migration file again
docker exec -it openbalena-api-1 /bin/bash
rm src/migrations/0074-normalize-release-contract.async.ts
exit
docker restart openbalena-api-1
go to your dev-laptop and start hacking with newest open balena server
balena login -t <your_balena_token>