I developed a docker file and was able to deploy it on a RPi 3 on the ResinOS image from resinos.io. When I wanted to test out the fleet management features on ResinIO, I used the OS image from the the site to burn an SD card for the Pi. Using the Resin CLI, the container build fails with the OS linked to my app on ResinIO.
Here is an output of the error from Resin
Step 1/16 : FROM resin/rpi-raspbian:jessie jessie: Pulling from resin/rpi-raspbian 675864ba0040: Pull complete 7bf3f2fb6095: Pull complete 3fd1f6eb7320: Pull complete aa27f50daaae: Pull complete c8a7be5ebe5f: Pull complete 394899c2bf9d: Pull complete bb1073a7468e: Pull complete d49a5a1e2ebf: Pull complete 995fe058036a: Pull complete 3c0ddf3c9e2b: Pull complete ---> 5fea260b13c0 Step 2/16 : RUN apt-get -y update ---> Running in 5c6f703c3170 Get:1 http://archive.raspberrypi.org jessie InRelease [22.9 kB] Get:2 http://archive.raspbian.org jessie InRelease [14.9 kB] Get:3 http://archive.raspberrypi.org jessie/main armhf Packages [169 kB] Get:4 http://archive.raspbian.org jessie/main armhf Packages [13.3 MB] Get:5 http://archive.raspbian.org jessie/contrib armhf Packages [49.5 kB] Get:6 http://archive.raspbian.org jessie/non-free armhf Packages [101 kB] Get:7 http://archive.raspbian.org jessie/rpi armhf Packages [1297 B] Get:8 http://archive.raspbian.org jessie/firmware armhf Packages [1202 B] rdt push failed. Error: The command '/bin/sh -c apt-get -y update' returned a non-zero code: 137 Error: The command '/bin/sh -c apt-get -y update' returned a non-zero code: 137 at Stream.<anonymous> (/usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/build/docker-utils.js:145:23) at emitOne (events.js:96:13) at Stream.emit (events.js:188:7) at drain (/usr/local/lib/node_modules/resin-cli/node_modules/through/index.js:36:16) at Stream.stream.queue.stream.push (/usr/local/lib/node_modules/resin-cli/node_modules/through/index.js:45:5) at Parser.parser.onToken (/usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/node_modules/JSONStream/index.js:132:18) at Parser.proto.write (/usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/node_modules/jsonparse/jsonparse.js:135:34) at Stream.<anonymous> (/usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/node_modules/JSONStream/index.js:23:12) at Stream.stream.write (/usr/local/lib/node_modules/resin-cli/node_modules/through/index.js:26:11) at IncomingMessage.ondata (_stream_readable.js:555:20) at emitOne (events.js:96:13) at IncomingMessage.emit (events.js:188:7) at readableAddChunk (_stream_readable.js:176:18) at IncomingMessage.Readable.push (_stream_readable.js:134:10) at HTTPParser.parserOnBody (_http_common.js:123:22) at Socket.socketOnData (_http_client.js:362:20) at emitOne (events.js:96:13) at Socket.emit (events.js:188:7) at readableAddChunk (_stream_readable.js:176:18) at Socket.Readable.push (_stream_readable.js:134:10) at TCP.onread (net.js:547:20)
Here is the Dockerfile I’m using:
FROM resin/rpi-raspbian:jessie
WORKDIR /usr/src/app
RUN apt-get -y update
RUN apt-get install iputils-ping
RUN curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
RUN apt-get install -y nodejs
RUN npm install -g npm@3.10.9
COPY package.json package.json
RUN apt-get update && apt-get -yq install \
htop \
git \
virt-what \
libsodium-dev \
libtool \
build-essential \
libkrb5-dev \
automake \
autoconf \
lsof \
rsync\
ecryptfs-utils \
keyutils \
mercurial \
python-dev \
python-setuptools \
libyaml-dev \
libssl-dev \
swig \
python-pip \
ntfs-3g \
samba samba-common-bin
RUN git clone https://github.com/thomasmacpherson/piface.git
RUN cd ./piface/c/ && ./autogen.sh && ./configure && make && make install && ldconfig
ADD . .
RUN npm install
EXPOSE 80
CMD ["node", "main.js"]
This is not the cause of your problem, but I think you should make far less “RUN”, because Docker creates one layer per RUN. Moreover, in older kernel versions (currently in use by ResinOS), you may not override permissions and file ownership set in a previous layer.
Just use “” like you do in “apt-get install” and if you have logical blocks, you can still introduce new lines and “#” comments to separate them.
It doesn’t appear like I’m changing file permissions. The issue occurs when I use the CLI to deploy locally and on the first RUN command, regardless of what the RUN is supposed to accomplish
This is the version of resinOS that’s on the device: Resin OS 2.0.8+rev1 (dev) from resinIO
This is the command i’m trying to run from the CLI: sudo resin local push -s .
I then select the device I’m trying to build the container on, causing the failure in my original post.
Hey @d.imade it turns out to be a known issue… It comes back to that if the user application does not have a commit pushed, then the supervisor running on the device is not put into local mode correctly, and thus it just cleans up the images while local push is building (as it does in “managed mode”)…
The current workaround is to push just any code (that builds correctly) to the application first. For example this this “dummy” project:
Afterwards you can work in local mode totally fine. When you switch from Local Mode back to managed, just push your application with a --force option for the first time. Or… you can just push your project’s current state to the application if it builds, then no need for the force push later when you switch back. Hope it makes sense!
We are working on fixing this, likely happening at the next milestone, as it seems like where we are heading with the supervisor and multicontainer support, it will be much simpler to get the correct behaviour. Sorry about the inconvenience in the meantime!
@d.imade oh, sorry, there was this one more thing on my mind, and forgot by the time writing to you…
There’s this issue that is pending for resin-cli because of the update to Docker 17.03:
We are working on a fix for this (see the linked conversation on Github). In the meantime using resinOS 2.0.6 (which has earlier Docker version) can be a workaround.
Sorry for this, really piled up for the moment, but getting there.
@imrehg, using resinOS 2.0.6, the “idling” image doesn’t seem to persist. The container runs for a certain amount of time and then closes on it’s own. Doesn’t show up when I SSH into my RPi and run docker ps
git push resin master any working code to the application on resin, the idling is an example project that is very light.
once there’s any code successfully pushed to the application, if you provision a device, and let it download this first code, afterwards it will be put into local mode correctly with the dashboard switch
resin local push your own application to this Local Mode device (you don’t have to care about the idling project at all, it is a “quickfix” until the local mode setting fixes are released)
Sorry if it is confusing, and thanks for bearing with us!
Hey @d.imade, the issue for resin local push on recent ResinOS devices has just been fixed, get the changes with updating resin-cli to 6.3.0! So now you should be able to use resinOS 2.2.0 that was just released this week.
(Just a note, that the “first have to push code to the application before local mode can be enabled” is still outstanding, but you should be set with that)