On NXP iMX devices the partitions are not encrypted with LUKS but with
the lower level dm-crypt subsystem.
Adapt the partition mount script to use dmsetup which works for both
LUKS and dm-crypt encrypted partitions.
Change-type: patch
Signed-off-by: Alex Gonzalez <alexg@balena.io>
Debian no longer publishes linux/arm/v5 images for bullseye, breaking
support for raspberry pi zero.
This change might not solve the issue indefinitely
as we don't know how long debian will continue publishing armv5 images.
Change-type: patch
balenaOS v6 enables zstd module compression by default. Add kmod to
runtime-base to support loading of compressed modules.
Change-type: patch
Signed-off-by: Joseph Kogut <joseph@balena.io>
Alpine allows the `~=` syntax to match a part of the package version
when installing. In this case we want to use it to specify node and
npm major versions
Change-type: patch
We were still on 3.16, where the nodejs package was
pointed at Node 16. 3.18 moves the pointer to Node 18.
Change-type: minor
Signed-off-by: Christina Ying Wang <christina@balena.io>
The node-dbus module is unmaintained and a blocker for the update to
Node 18. Switching to our own node bindings for systemd solves this
issue
Relates-to: Shouqun/node-dbus#241
Change-type: patch
This is necessary since the builder no longer passes the platform flag
to the build. This would lead to dockerfiles that are mixing multi and single
arch stages to pull the wrong architecture images, particularly when
trying to build images in emulated builds (e.g. armv7hf built on aarch64).
Moving the full build to multi-arch solves this as the docker engine is
capable of chosing the right architecture from the manifest.
Relatest-to: balena-io/balena-builder#1010
Change-type: patch
We don't need this anonymous volume as /data is bind mounted into
the container from host (legacy), and will soon be mounted by the
Supervisor itself on startup.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
As the Supervisor is a privileged container, it has access to host /dev, and therefore has access
to boot, data, and state balenaOS partitions. This commit sets up the framework for the following:
- Finds the /dev partition that corresponds to each partition based on partition label
- Mounts the partitions into set mountpoints in the device
- Removes reliance on env vars and mountpoints provided by host's start-balena-supervisor script
- Simplifies host path querying by centralizing these queries through methods in lib/host-utils.ts
This particular changes env vars for and mounts the boot partition.
Since the Supervisor would no longer rely on container `run` arguments provided by a host script,
this change moves Supervisor closer to being able to start itself (Supervisor-as-an-app).
Change-type: minor
Signed-off-by: Christina Ying Wang <christina@balena.io>
This reverts commit 00e389e5f5.
Images generated using this dockerfile still don't have the right
architecture. More testing is needed
Change-type: patch
This is necessary since the builder no longer passes the platform flag
to the build. This would lead to dockerfiles that are mixing multi and single
arch stages to pull the wrong architecture images, particularly when
trying to build images in emulated builds (e.g. armv7hf built on aarch64).
Moving the full build to multi-arch solves this as the docker engine is
capable of chosing the right architecture from the manifest.
Relatest-to: balena-io/balena-builder#1010
Change-type: patch
This is necessary since the builder no longer passes the platform flag
to the build. This would lead to dockerfiles that are mixing multi and single
arch stages to pull the wrong architecture images, particularly when
trying to build images in emulated builds (e.g. armv7hf built on aarch64).
Moving the full build to single-arch solves this as the docker engine is
capable of chosing the right architecture from the manifest. Once some
of the builder issues are fixed, we should move to #2141
Relates-to: balena-io/balena-builder#1010
Change-type: patch
The supervisor had to chroot into the host root in order to read the
journal logs. This won't be possible anymore once the supervisor becomes
an app. This commit copies the journalctl binary and necessary libraries
from a debian image into the supervisor image in order to be able to use
the tool on runtime.
Change-type: patch
This PR changes the way the supervisor reads and writes files from /mnt/boot. Reads will
now use the [fatrw utility](https://github.com/balena-os/fatrw/) as a way to minimize corruption of
files in the boot partition, and thus preventing possible bricking of the device.
Since this basically changes the way a lot of configurations are read, this work was being blocked because of
the way tests were being done. While there still remain a couple of legacy tests to be migrated, this PR disables
test:legacy tests when running npm run test, as the work on refactoring those tests is in progress (see #2048) and
fatrw integration is of higher priority.
Change-type: minor
Replace test with test:base to make sure integration tests don't run in CI.
Integration tests for the Supervisor fail when not run in container, leading
to an error-exit and cause the Flowzone CI job for Node to fail.
By returning true, the Flowzone Node CI job succeeds, and this is fine even if tests
fail because they will be caught in the Docker job anyway.
Also, combine original npm test script with test:node.
Signed-off-by: Christina Ying Wang <christina@balena.io>
This allows to run integration tests during development and on CI
with the right dependencies. There are several changes that this
involves, but the gist of it is that a test environment is setup using
`docker-compose.test.yml`. This file is loaded by `resin-ci` during the
build, and ensures that integration tests are ran after setting up all
requirements. This commit also defines a test environment command that
can be setup using `npm run test:env` in order to run tests in a local
development machine.
This sets up the new `test/unit` and `test/integration` folders
and starts classification of some of the test files.
Note that unit tests include, `fs-utils` and `system-info` tests.
While these tests interact with the filesystem, the implementation
of these modules is simple enough, and the tests are fast enough to
allow these tests to fall under the `unit` test category (according to
test/README)
Change-type: patch
The supervisor used to perform tests both for the transpiled code (after
tsc) and one for the typescript code (using
ts-node/register/transpile-only). There is not really a reason for this
and this added complexity to the test configuration. This used to make
testing harder, as the built code didn't include source maps, meaning
the tests did not point to the right code.
Since we want to split tests in unit and integration tests as the next
test improvement, it makes sense to simplify these commands before
adding more complexity.
Change-type: patch
Restructure the supervisor image to remove the dependency on the custom `alpine-supervisor-base`
image and the custom node build. The dockerfile is now a multi-stage
build that splits the process into two build stages and two runtime
stages.
Here is the full list of changes
- The node binary is now copied from `balenalib/${ARCH}-alpine-node:12-run`, the node binary
now supports running with a debugger.
- The runtime image now inherits from the official `alpine:3.16` image
- Tests are ran within the runtime image configuration instead of the
build image
- Livepush is ran within the runtime image context
- Unnecessary packages have been removed
- Removed avahi-daemon.conf as that service is not being used
- Fix livepush to work with a multi-stage image. This also deprecates the `image-tag` argument to npm run sync as
`SUPERVISOR_TAG` is no longer used by new OSs
- Fix livepush build on old rpi devices. Allows passing a 'PREFIX'
argument to let the builder pull images directly from docker hub arch
repositories. Relates to https://github.com/balena-os/balena-engine/issues/269
Change-type: patch
The linked issue describes the Supervisor not cleaning up locks it creates due
to crashing at just the wrong time. After internal discussion we decided to
differentiate Supervisor-created lockfiles from user-created lockfiles by using
the `nobody` UID (65534) for Supervisor-created lockfiles.
As the existing NPM lockfile lib does not allow creating lockfiles atomically
with different UIDs, we move to using the lockfile binary, which is part of the
procmail package. To allow nonroot users to write to lock directories, permissions
are changed to allow write access by nonroot users.
See: https://www.flowdock.com/app/rulemotion/r-resinos/threads/gWMgK5hmR26TzWGHux62NpgJtVl
Change-type: minor
Closes: #1758
Signed-off-by: Christina Wang <christina@balena.io>
Cpu id is set to null so far for non ARM devices (e.g. Intel NUC). This
parses the output of dmidecode to get the cpu id and system model.
Change-type: patch
