openBalena 2024

Hello folks, looking for some feedback on the new getting started guide, which is part of this openBalena PR.

We’ve made some fairly major structural changes and updated all the deps.

Cheers!

3 Likes

Hi,

I noticed the minimum version requirements have been updated.

The current release of openBalena has the following minimum version requirements:

  • balenaOS v5.2.8
  • balena CLI v18.2.2

If you are updating from previous openBalena versions, ensure you update the balena CLI and re-provision any devices to at least the minimum required versions in order for them to be fully compatible with this release, as some features may not work.

I’ve been using API version 20.1.14 with some devices still running Balena OS 2.115.x and haven’t encountered any issues so far. Do you know of any specific cases where something broke with these older versions? Or are the new minimum requirements primarily a precautionary measure?

Additionally, I think it would be helpful to have a section about upgrading to newer versions, This section could also include information about necessary changes during the upgrade process. For instance, I recall that the TRUST_PROXY variable needed to be set for the API in a previous update.

Kind regards,
Maurits

Do you know of any specific cases where something broke with these older versions? Or are the new minimum requirements primarily a precautionary measure?

There really wasn’t a lot of science behind this, we just took the currently latest version stamp and put it into the docs. The automated tests alway use the latest version of balenaOS to test with.

So, while we don’t test with previous versions as it would be expensive (we spin up AWS/EC2 instances for each run), they probably will work up to a certain point, 2.100+ should be safe, but testing is recommended prior to upgrade.

Additionally, I think it would be helpful to have a section about upgrading to newer versions, This section could also include information about necessary changes during the upgrade process. For instance, I recall that the TRUST_PROXY variable needed to be set for the API in a previous update.

This is all now codified in the single composition, along with other items, such as REDIS_IS_CLUSTER, I’ll add a note about upgrading, but since we aren’t actively supporting real openBalena deployments anywhere, we’ll look to the community to perform the ultimate upgrade test…

Thanks for the quick reply.

This is all now codified in the single composition, along with other items, such as REDIS_IS_CLUSTER , I’ll add a note about upgrading, but since we aren’t actively supporting real openBalena deployments anywhere, we’ll look to the community to perform the ultimate upgrade test…

I think it’s important to highlight this in the documentation. New people might assume the master branch to just work and it can help set the right expectations when trying out OpenBalena.

Over the past year, I have upgraded several OpenBalena instances, starting from version v0.209.2 all the way up to v20.1.14. I have taken notes during these upgrades and I’m more than willing to contribute them to some sort of community upgrade guide.

Over the past year, I have upgraded several OpenBalena instances, starting from version v0.209.2 all the way up to v20.1.14. I have taken notes during these upgrades and I’m more than willing to contribute them to some sort of community upgrade guide.

We’d love that. I suggest we create another link off the main README.md called “Upgrade/migration guide” or something to that effect, cleanup and put your notes there.

Great to hear. I’ll look into it when I have some free time

Hy

is there some progress of the new helping page?

We try to upgrade from a old open-balena server to the latest one.

It seems there are huge differences between this versions (we have installed the 2 year old one, without the new Makefil)

The new makefile is creating new volumes for every container.

is it possible to copy the content from the old volumes to the new ones?

Is there a upgrade path to migrate the old version to the newest one?

we have this container version installed.
a simple git pull and make up is not possible anymore…

balena/open-balena-api:v0.209.2     
balena/open-balena-registry:v2.25.3 
balena/open-balena-s3:v2.13.10      
openbalena_cert-provider            
redis:alpine                        
balena/open-balena-db:v5.1.2                                                                                      openbalena_db_1

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>

1 Like