Balena local push fails with unknown error 'esparse'

No additional logs when running with DEBUG=1. I can push to the app in balena cloud no problem, but local push fails:

PS C:\dev> balena scan
Reporting scan results
  host:          b2b1217.local
    Containers:        1
    ContainersRunning: 1
    ContainersPaused:  0
    ContainersStopped: 0
    Images:            5
    Driver:            aufs
    SystemTime:        2020-06-04T21:38:21.850324748Z
    KernelVersion:     5.2.10-yocto-standard
    OperatingSystem:   balenaOS 2.50.1+rev1
    Architecture:      x86_64
    Version:    18.09.17-dev
    ApiVersion: 1.39
PS C:\dev> balena push b2b1217.local
[Info]    Starting build on device b2b1217.local
UNKNOWN: UNKNOWN: unknown error, stat 'C:\dev\node_modules\.bin\esparse'

Additional information may be available by setting a DEBUG=1 environment
variable: "set DEBUG=1" on a Windows command prompt, "$env:DEBUG = 1" on
powershell, or "export DEBUG=1" on Linux or macOS.

Also I’m curious to know how to push a branch to the device other than master. Normally this would be git push balena newbranch:master but it doesn’t look like there’s a corresponding argument for the balena push cli.


Hi, what base image are you using in your project?
To answer your second question, balena push does not care about code versioning. So if you want to push a different branch of your git project, then first checkout that particular branch and then run the balena push command.

Hi @floion, the base image is Intel NUC. I believe that’s what you’re asking.

No. I meant the base image you are using in your Dockerfile. Can you share your entire Dockerfile?

Ah, sorry - here it is:

FROM balenalib/%%BALENA_MACHINE_NAME%%-node:12


# cross-build for x86
RUN if [ %%BALENA_ARCH%% = "i386" ] || [ %%BALENA_ARCH%% = "amd64" ] ; then [ "cross-build-start" ] ; fi

# Set the timezone
ENV TZ=America/Los_Angeles
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && dpkg-reconfigure -f noninteractive tzdata

# Different libgcc packages based on architecture
RUN if [ %%BALENA_ARCH%% = "i386" ] ; then install_packages libgcc-4.9-dev ; elif [ %%BALENA_ARCH%% = "amd64" ] ; then install_packages libc6-dev ; else install_packages libgcc-6-dev ; fi

# Install apt-get packages
RUN install_packages \
    # utilities
    curl git vim openssh-client telnet ftp lynx wget \
    # for node-sass
    node-gyp \
    # for staticIP
    network-manager \
    # for sqlite3
    sqlite3 python-dev build-essential 

RUN update-alternatives --set iptables /usr/sbin/iptables-legacy

# Add npm bin to path (for sequelize and other CLIs in NPM)
ENV PATH "${PATH}:/root/node_modules/.bin"

# Allow nmcli (network-manager) commands to run from terminal
ENV DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket

# Useful npm-based utilities
RUN npm i -g wscat

# Install cellmate dependencies
COPY package.json .
RUN npm install --production

# Copy directories in /client over
COPY . .

# Build Admin ui (rebuilds whenever ui files change)
RUN cd ui \
  && npm install \
  && npm run build \
  && mv build .. \
  && cd .. \
  && rm -rf ui \
  && mv build ./ui

# Make files executable as needed
RUN chmod a+x lib/network/

RUN if [ %%BALENA_ARCH%% = "i386" ] || [ %%BALENA_ARCH%% = "amd64" ] ; then [ "cross-build-end" ] ; fi

CMD npm run container-start

This appears to be some limitation/bug in balena push handling the variables – I’ll ping the CLI team to see if this can be quickly fixed.

Hey @jgentes

This seems to be related to a missing symlink when the node_modules were installed.
We recommend changing

# Copy directories in /client over
COPY . .

such that you only copy the required files and directories. Ideally, you would omit copying over the node_modules folder.

Hope this helps

Thanks @rahul-thakoor, we use a .dockerignore file to ensure node_modules isn’t copied over, but good catch!

I made that adjustment and it didn’t help with the balena push issue so I assume it’s the variable issue that @dfunckt mentioned. I’ll wait to hear back on your progress.

@dfunckt FYI - I modified the dockerfile and commented out the lines with %%BALENA_ARCH%% and %%BALENA_MACHINE_NAME%% variables (replacing the lines with hard-coded versions of the same) but that didn’t seem to make any difference.

I think it’s unlikely to be the variable issue noted above, as these are pretty well tested. Can you try altering the COPY step, to isolate whether it’s an issue with .dockerignore file handling please?

If I remove the dockerignore file entirely, the same problem occurs. If you push the same dockerfile, does it work for you?

I didn’t mean to remove the dockerignore file, sorry if I wasn’t clear. I meant can you change the COPY step to only copy in what you need for the build and that will then highlight if it’s a problem with the dockerignore file handling.

I reduced the file down to basically nothing and the problem persisted, so I’m thinking the issue may be with the docker-compose file that I have… sorry, forgot to mention that. I’ve trimmed that down to the very basics but unfortunately I’m still seeing the issue. Here’s the docker compose file:

version: '2'
    build: ./client
    privileged: true
    restart: always
      - 'sidekick-data:/data'

And the dockerfile in /client:

FROM balenalib/%%BALENA_MACHINE_NAME%%-node:12


CMD npm run container-start

If I try to balena push directly from the /client directory, I get this:

PS C:\dev\client> balena push b2b1217.local --debug
[debug] Using . as build source
[Warn]    "docker-compose.y[a]ml" file found in parent directory: please check that
[Warn]    the correct source folder was specified. (Suppress with '--noparent-check'.)
[Debug]   Checking we can access device
[Debug]   Sending request to
[Debug]   Checking device version: 11.4.10
[Info]    Starting build on device
[Debug]   Loading project...
[Debug]   Resolving project...
[Info]    No "docker-compose.yml" file found at "."
[Info]    Creating default composition with source: "."
[Debug]   Creating project...
[Debug]   Tarring all non-ignored files...
UNKNOWN: UNKNOWN: unknown error, stat 'C:\dev\client\node_modules\.bin\_mocha'

Oh right I see. Yeah I think this must be a CLI issue, in the way it’s traversing the file system. If you remove the local node_modules by deleting the directory does that help? (Is there even a directory present?). Could you fill in the template at with your system information please and we should be able to get a resolution from that.

I tried renaming the node_modules folder but saw the same issue. Very odd… I’ll submit a new issue - thanks!

Can you also paste here the issue you opened? Thank you

Here’s the link:

We were able to figure it out - as it turns out I was running balena push from powershell even though my dev environment was in WSL. I installed balena-cli in WSL and push worked from there.

Thanks for your help!

I’m glad you solved the issue!