We’ve added the following environment variable: RESIN_HOST_CONFIG_dtoverlay=pi3-miniuart-bt, however, on some devices we’re seeing that this isn’t applied.
After looking into it, I saw the following environment variable is added to the device itself: RESIN_HOST_CONFIG_dtoverlay="vc4-fkms-v3d". I’m 100% sure I haven’t added this environment variable myself, because I don’t even know what it does .
This causes some problems, because some devices now use ttyAMA0 for their UART, and some have to use ttyS0. I know about the serial0 symlink, however, when the container is running privileged, serial0 isn’t available anymore.
Some details:
Raspberry Pi 4
balenaOS version 2.65.0+rev1 (supervisor v12.2.11)
openBalena API v0.109.2
openBalena VPN v9.16.1
openBalena registry v2.13.11
openBalena DB v4.1.0
Didn’t try that yet, I’m busy to try and understand how this works, so I can prevent it from happening in the future.
Unfortunately, when trying to figure this out, I’ve deleted all config variables of all devices in my openBalena instance (around 300 devices), so I’m busy with fixing that first
When I’ve fixed that, I’ll try to upgrade one and see how it goes!
I’ve just flashed a new Raspberry Pi 4 (balenaOS 2.75.0+rev1, supervisor v12.5.10) and the RESIN_HOST_CONFIG_dtoverlay "vc4-fkms-v3d" is added again.
This causes huge problems for us, because the application environment variable of RESIN_HOST_CONFIG_dtoverlay doesn’t get added to the config.json. This means the miniuart-bt isn’t added and thus the serial port is on /dev/ttyS0 instead of /dev/ttyAMA0.
I think this’ll also cause problems for other users, because application-level dtoverlays will not be applied.
On provision, the supervisor uses the initial device configuration to override configuration variables API side. This is meant to be a feature allowing users to modify config.json on the provisioning image and have those configuration values be persisted as overrides on the cloud. This also ensures that configurations in config.txt get persisted on the cloud to ensure future availability. However, as you have noticed, these values are not being set to the fleet defined defaults. This seems to be a timing issue, where the cloud value for the variable is not yet available device side at the moment of provisioning so the local value is set as default every time.
We are still investigating the proper solution for this issue, however, one workaround you can use for now is to modify the config.txt file on the provisioning image you are using to flash your devices with the proper value for dtoverlay to ensure that value gets set cloud side.
I’ll test the workaround asap.
Please let me know once you’ve decided what the solution will be and once it’s implemented. Our devices will not function properly if they don’t have the right dtoverlays set in the application and testing every device (we do batches of around 150 devices) isn’t very efficient
Any news on this?
I’ve created a new application with BalenaOS v2.82.10+rev1, supervisor version v12.9.3 (Raspberry Pi 4), and this just happened again, so the RTC on the device won’t work.
I can probably use the workaround, but the config environment variables on application level are now unusable, because they get overwritten by the device itself…
We haven’t been able to work on this issue yet. It unfortunately is not a quick fix since we need to decide on the proper behavior so it works as expected for most users, for instance I could imagine someone wanting to provision a device with a diverging configuration from the rest of the fleet. I will bring this in our internal discussion forum and let you know how we progress with this.
For now I think the workaround is your best bet, although I agree that is not ideal since you end up having an override for each device.
.
