This commit completes the list of default / board-wide dtparams
to include some `baudrate` and `vc` i2c params.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
Previously, getBootConfig() of the config.txt backend was omitting
array configurations such as gpio settings, thus resulting in the SV
mistakenly assuming that boot config had not been applied, since gpio
would not be in current config.txt config but would be in target config.
This resulted in SV entering an infinite loop of attempting to apply the
gpio config when it wasn't necessary.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
While ordering is important in the RPI firmware configuration file (config.txt),
some dt params are by default considered part of the base dt overlay
if they are not used by other overlays.
Unfortunately the [list of dtparams](https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L133)
is too long to add all of them as exceptions, but we can add the params
used in the default config.txt provided in OS images, to avoid reboots
when updating to this new supervisor and correctly parsing the
provisioning config.txt as variables.
While this addition handles most common scenarios, there is still a
chance a user may have use other base overlay dt params in the initial
config, in which case those will be interpreted according to the
relative ordering
Change-type: patch
DT overlays and DT params need to be consumed in the order that they
appear on the file. DT params apply to the last dtoverlay defined on the
file, or to the base overlay.
This commit updates config.txt parsing to consider this ordering, and it
also ensures global dtparams are written first so they cannot be
overriden by later overlays.
Because of the more strict parsing method, it is possible that existing
HOST_CONFIG vars do not match the interpretation of the parser. If
that's the case, the supervisor will re-apply the target state which
will cause the device to reboot.
Change-type: major
Fixes behavior for release updates which removes a service in current state
and adds a new service in target state.
Change-type: patch
Closes: #2095
Signed-off-by: Christina Ying Wang <christina@balena.io>
Moby v25 adds the dynamically generated MAC address to the Config field,
which breaks the state engine, preventing the state from settling as the
current state never matches the target state (empty mac address). This
seems to be a bug in Moby that we reported in moby/moby#47228
The issue won't affect Balena devices until balenaEngine is updated, and this
change fixes testing for now.
Change-type: patch
From docker 25, the engine will validate IPAM config. This would cause
the docker utils test to fail since the network/subnet configuration was
incorrect.
Change-type: patch
The tsserver lsp doesn't seem to work well with .editorconfig. Using
prettierrc will allow formatting to work correctly with editor plugins
This also updates editorconfig to work well with json
Change-type: patch
This is meant to allow users to configure their device to
resolve `.local` queries via dnsmasq by modifying config.json, e.g. `dnsServers":
"/bob.local/172.17.0.33`.
This would fail before as MDNS lookups would always come first
Change-type: minor
The description incorrectly states the endpoint would start a service
in the whole fleet while it only affects the device.
Change-type: patch
Signed-off-by: Alex Gonzalez <alexg@balena.io>
The `updateMetadata` step renames the container to match the target
release when the service doesn't change between releases. We have seen
this step fail because of an engine bug that seems to relate to the
engine keeping stale references after container restarts. The only way
around this issue is to remove the old container and create it again.
This implements that workaround during the updateMetadata step to deal
with that issue.
Change-type: minor
Relates-to: balena-os/balena-engine#261
Whenever the Supervisor reports current state, it diffs the current state
with its last reported current state. However, when the Supervisor starts
up, there is no last reported state, since that last report is stored in
process memory. Caching the last report in a location that survives
Supervisor restarts will reduce the current report bandwidth used on startup.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
Intermediate state is utilized when executing device actions such as a
volume purge. It's a type of state apply, but despite that,
applyInProgress is not true.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
