balena-io-library / base-images

Balena base images

Balena base images

Description

This repository contains Dockerfiles of the Balena base images. The images are organised as a tree structure to serve each device type supported by Balena. For more details on how the images fit together as a tree, see the full document: Balena Base Images

Contribute

• Issue Tracker: github.com/balena-io-library/base-images/issues
• Source Code: github.com/balena-io-library/base-images

Support

If you're having any problem, please raise an issue on GitHub.

Related Resources

• Balena Base Images Document

base-images's Issues

New info from systemd printed to logs

In the latest base images I now see additional info printed out when INITSYSTEM=on, this is actually pretty useful info to have, so I think it should be kept, just highlighting this.

libmraa build dependencies are installed forever

The build dependencies in the device base image for the edison should be cleaned up after use just like we'd do with a slim image. Otherwise even the slim images for the Edison won't be as slim.

https://github.com/resin-io-library/base-images/blob/master/device-base/Dockerfile.i386.edison.tpl#L4-L18

bug: Setuptools not cleaned up from python images

Currently there are these files in the root of the python images:

root@edison-b9d4d7:/# ls -lha setup*
-rw-r--r-- 1 root root 661K Apr  1 21:52 setuptools-20.2.2.tar.gz
-rw-r--r-- 1 root root   91 Apr  1 21:52 setuptools-20.2.2.tar.gz.sha256sum

Update base-images metadata

We need correctly tagging the architecture of our base images on the image metadata since they are all marked as amd64

INITSYSTEM should also accept 1 or 0 as well as on and off

relates to https://github.com/resin-io/hq/issues/364

Add sha256 verification for downloads

In https://github.com/resin-io-library/base-images/blob/master/golang/nuc/1.5/Dockerfile#L6 (and probably other places), it would be good to check the file is valid by performing a sha256sum comparison for the download with the hash provided by the vendor, as is done in https://github.com/resin-io-library/base-images/blob/master/python/Dockerfile.tpl#L47-L51

Needs Documentation: dpkg config may cause unexpected apt-get behavior

I've been developing my first resin-backed app. I started with a Dockerfile based on resin/raspberrypi-python and ran it in a local docker container while I iterated on the first pass of application code - roughly the first 20% of the project.

After everything configured properly and I had my code mildly organized, I used resin.io to build and push the container to resin.os on a nearby raspberry pi and I switched to interactive development via ssh, iterating mostly without rebuilding the image (perhaps just 5 times over two days). The mgrenier/remote-ftp Atom package makes remote development on the rpi super easy.

Consequently, I've ended up installing a few extra packages on my dev rpi that are only useful for local development and I intend to eventually remove them from my Dockerfile. One of them was the AWS CLI interface (pip install awscli), which I'm using interactively on the pi as I add the boto3 python AWS SDK to my code.

Long story short, the aws CLI tool wasn't able to display any help files on the pi, and it took me quite a while to figure out why: because it depended on groff, and although apt-get install groff apparently produced a working groff binary in the PATH, it had in fact not been installed with the output modules (ascii & utf8 devices in groff parlance) that aws assumed would be present. Because apt-get via dpkg had been configured in the base image to skip installing certain documentation resources, including anything in /usr/share/groff. Commenting-out the line in question in /etc/dpkg/dpkg.cfg.d/01_nodoc then apt-get install --reinstall groff-base restored aws expected behavior.

I think it's reasonable to exclude documentation files by default in the base images to save space, along with most of the other bloaty tools these "skinny" distros do away with. But it shouldn't lead to unexpected behavior of tools like apt-get. So please consider adding a note in the docs somewhere letting users know what kinds of things their base-image's package manager is configured not to install.

---

Some general thoughts on the development pattern with resin.io:

It would be great if there were a couple of resin.os base images "fattened up" to support interactive development environments, but fundamentally identical to the existing "skinny" production images. Then I could

1. do as much initial work as possible with the dev image running in a local container (simulating serial devices, GPIO, etc if possible);
2. push it over to the pi when necessary (to test embedded libraries and connected peripherals) and continue to work interactively, then bounce back to the local container;
3. switch to the production base image and check everything still works and release/repeat. Maybe this would be as simple as making a single change to the FROM directive in the dockerfile

#FROM resin/raspberrypi-python:development
FROM resin/raspberrypi-python

or if not, just maintaining dev and prod branches in git when the Dockerfiles required more elaborate changes.

Is anyone following a dev pattern like this already?

Unable to start udev on Alpine Edison base images

udev won't be able to start properly.
always hit Segmentation fault when executing udevd.

improve tag consistency through the image hierarchy: add more date fixed tag

I'm using images based directly on resin/raspberrypi2-debian:jessie-20161010. These images nicely share their base layers.
For another image I need node, so I was looking for a tag in resin/raspberrypi2-node that shares the same base .... but there is no such tag, and in general I see no combination of tags that would achieve this.

I think it would be nice to be able to select date tagged images form <device-name>-<distro> and <device-name>-<distro>-node such that:

• the base layers are long term stable
• the node version only adds layers to the base version.

Merge systemd images with base debian

The alpine images have the initsystem integration in their core, without an extra set of images named amd64-openrc. This makes sense and we should follow the same convention for the debian images as well by moving the bits added by the systemd layer to the base debian layer.

Update the way the hostname is set

ResinOS 2.x changed the way the hostname is set. See balena-os/meta-balena#509 . Discussed on Flowdock.

Improper CMD instruction parsing when using the CMD shell form

This investigation started when we noticed that this project wouldn't run as expected when installed on an Rpi2. Instead of the electron app, the application only presented a single xterminal, which is the default behavior of xinit.

Let's start by looking into the base image hierarchy. There we find the armv7hf-debian base image. In its Dockerfile we can find this instruction:

ENTRYPOINT ["/usr/bin/entry.sh"]

Now our affected application uses a Dockerfile.template, which is parsed and results in a Dockerfile that looks like this:

FROM resin/raspberrypi2-node:4.0.0
[...]
CMD xinit /usr/src/app/launch_app.sh --kiosk -- -nocursor

The effect of the CMD command is that it passes arguments to the ENTRYPOINT command; for more information you can refer to the related Exec form ENTRYPOINT example in the official Docker documentation.

Also notice that in our app's Dockerfile we use the CMD shell form, so the command will execute in /bin/sh -c. As a result, the command that will be executed is:

/usr/bin/entry.sh /usr/sh -c xinit /usr/src/app/launch_app.sh --kiosk -- -nocursor

The arguments are then parsed by the entry.sh file:

if [ "$INITSYSTEM" = "on" ]; then
[...]
  echo -e "#!/bin/bash\n exec $@" > /etc/resinApp.sh
  chmod +x /etc/resinApp.sh
[...]

So the final resinApp.sh on the device looks like this:

#!/bin/bash
exec /usr/sh -c xinit /usr/src/app/launch_app.sh --kiosk -- -nocursor

And there's the issue. /bin/sh -c expects a string wrapped in '' or "", or else it needs special care to pass the arguments after the next parameter. In our case, xinit will be executed and the rest of the parameters will simply be ignored, as we can see in the related sh(1) section:

The -c option causes the commands to be read from the string operand
     instead of from the standard input.  Keep in mind that this option only
     accepts a single string as its argument, hence multi-word strings must be
     quoted.

Now I'm not sure if this is a docker issue or ours, some possible solutions are:

1. Support only the CMD exec form (CMD ["command, "param1", "param2"]) and update the docs accordingly.
2. Update the scripts to handle CMD shell form, i.e wrap the command properly in "".

User can't use "latest" tag in resin/*-alpine-openjdk images because it doesnt exist

links to https://github.com/resin-io/hq/issues/608

Provide Python 3.6 image

The latest Python image is still 3.5.2. It would be nice to have 3.6.0 images too.

Missing python "3" tag

resin/nuc-python:3 doesn't exist

No readme + how to contribute

There should be a readme for these images, links to the other base architecture images and a short description of how to contribute.

Create new base images for Artik

Updating QEMU on base-images to fix issues of QEMU with Golang image

pypi links don't resolve

on line 47.

Refactor the base images wiki

as Shaun mentioned here balena-io/docs#308

Add owncloud images for resin devices

Please add support for C.H.I.P. base images

The CHIP is a 9 dollars ARMv7 computer that is debian and alpine compatible (getchip.com) - Adding it to the list of supported platforms would be a quick win.

Error message when systemd enabled

the following message "Failed to install release agent, ignoring: No such file or directory" appears after systemd enabled

Failing to call CMD commands when INITSYSTEM=on

When using resin/odroid-ux3-python:latest

If on DOCKERFILE:

INITSYSTEM=on
CMD bash start.sh

then start.sh is not executed (it's only executed if called as ENTRYPOINT bash start.sh)

If on DOCKERFILE:

INITSYSTEM=off
CMD bash start.sh

then start.sh is exectuted

Webterminal throws xargs error on fedora base images

Get the following error when spawning a web terminal using one of our Fedora base images:

sh: line 1: xargs: command not found     

The terminal still seems to work, so not sure if its an issue or not, it just looks ugly :P

linked to: https://github.com/resin-io/resin-proxy/issues/34

Integrate Artik SDK/API fedora into Artik base images

Install UPM module on edison images

We should install UPM, which is a high level repository for sensors that use mraa, on edison images. UPM main page: http://iotdk.intel.com/docs/master/upm/

libmraa source files are not cleaned up after build

We should remove the source files after building

https://github.com/resin-io-library/base-images/blob/master/device-base/Dockerfile.i386.edison.tpl#L26

Implement test for base images before pushing to dockerhub

Python 3 base image

I was looking to submit a pull request to generate Python 3 base images similar to how Node is setup to generate all the different versions, but it looks a little more involved than I was expecting. Any chance of getting this added or could someone help point me in the various locations to do so?

It looks like the following places would need updated:

• Update the scripts and templates under https://github.com/resin-io-library/base-images/tree/master/python
• Update the official library repos - https://github.com/resin-io-library/official-images/tree/master/library

I'm still trying to understand how they are built (bashbrew) and how the git repos relate to the images built

When building a node.js docker image, don't install dev dependencies

From balena-os/balena-supervisor#73

libmraa on Edison isn't versioned

We should pin a specific version for libmraa and update it whenever we see fit here https://github.com/resin-io-library/base-images/blob/master/device-base/Dockerfile.i386.edison.tpl#L22-L26.

The current version of the library is v0.8.1.

Node 6.4.0 doesn't work on debian wheezy base images

official v6.4.0 armv7l node binary requires GLIBCXX_3.4.18 which is not available on wheezy images. While gcc/g++ 4.8 or newer is required to compile v6.4.0 so we can't compile it from wheezy images too. Therefore we need to rollback to v6.3 for debian wheezy base images.

Alpine: hostname/UUID needs to be quoted

Using the alpine images, can run into an issue, not being able to start the application:

25.07.16 10:23:07 (+0800) Restarting application 'registry.resin.io/seeed/c67f3e9e16b0d8f0ac1b6292190626dd14280bd1'
25.07.16 10:23:08 (+0800) hostname: unrecognized option: 0
25.07.16 10:23:08 (+0800) Usage: hostname [-v] {hostname|-F file}      set hostname (from file)
25.07.16 10:23:08 (+0800)        domainname [-v] {nisdomain|-F file}   set NIS domainname (from file)
25.07.16 10:23:08 (+0800)        hostname [-v] [-d|-f|-s|-a|-i|-y|-n]  display formatted name
25.07.16 10:23:08 (+0800)        hostname [-v]                         display hostname
25.07.16 10:23:08 (+0800) 
25.07.16 10:23:08 (+0800)        hostname -V|--version|-h|--help       print info and exit
25.07.16 10:23:08 (+0800) 
25.07.16 10:23:08 (+0800)     dnsdomainname=hostname -d, {yp,nis,}domainname=hostname -y
25.07.16 10:23:08 (+0800) 
25.07.16 10:23:08 (+0800)     -s, --short           short host name
25.07.16 10:23:08 (+0800)     -a, --alias           alias names
25.07.16 10:23:08 (+0800)     -i, --ip-address      addresses for the hostname
25.07.16 10:23:08 (+0800)     -f, --fqdn, --long    long host name (FQDN)
25.07.16 10:23:08 (+0800)     -d, --domain          DNS domain name
25.07.16 10:23:08 (+0800)     -y, --yp, --nis       NIS/YP domainname
25.07.16 10:23:08 (+0800)     -F, --file            read hostname or NIS domainname from given file
25.07.16 10:23:08 (+0800) 
25.07.16 10:23:08 (+0800)    This command can read or set the hostname or the NIS domainname. You can
25.07.16 10:23:08 (+0800)    also read the DNS domain or the FQDN (fully qualified domain name).
25.07.16 10:23:08 (+0800)    Unless you are using bind or NIS for host lookups you can change the
25.07.16 10:23:08 (+0800)    FQDN (Fully Qualified Domain Name) and the DNS domain name (which is
25.07.16 10:23:08 (+0800)    part of the FQDN) in the /etc/hosts file.
25.07.16 10:23:08 (+0800) OpenRC init system enabled.
25.07.16 10:23:08 (+0800) /usr/bin/entry.sh: line 39: /sbin/init: No error information
25.07.16 10:23:09 (+0800) 
25.07.16 10:23:09 (+0800) Application exited 'registry.resin.io/seeed/c67f3e9e16b0d8f0ac1b6292190626dd14280bd1'

The UUID of this particular device is 0fb549fe00f9a9c4ba96a45f349b525c4e36498835dc0533b202606bd43d81 and because of the lack of quoting in hostname setting, the leading zero causes an issue.

Should properly quote the relevant variables.

Add onbuild warning message on wheezy systemd base images

Consider providing yarn as part of the base image

https://yarnpkg.com/ is a modern npm client replacement from Facebook, Google, et. al.
Providing it pre-packaged is a matter of npm install -g, but should make our images look way more modern.
Would probably only make sense for node >= 4

/etc/hostname is being appended to on container restart

Currently, if a container is allowed to restart enough times, eventually an error is output indicating that the hostname is too long - hostname: name too long.

Experimenting with a Dockerfile consisting of:

FROM resin/raspberrypi3-debian

CMD hostname; echo "$HOSTNAME"; cat /etc/hostname

Gives output as shown below, which clearly indicates that /etc/hostname is having -30fbcd (the first 6 digits of the device UUID) being appended to on each restart.

29.06.16 12:33:13 [+0100] Started application 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:13 [+0100] raspberrypi3-30fbcd
29.06.16 12:33:13 [+0100] raspberrypi3-30fbcd
29.06.16 12:33:13 [+0100] raspberrypi3-30fbcd
29.06.16 12:33:13 [+0100]
29.06.16 12:33:14 [+0100] Application exited 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:14 [+0100] Restarting application 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:16 [+0100] raspberrypi3-30fbcd-30fbcd
29.06.16 12:33:16 [+0100] raspberrypi3-30fbcd-30fbcd
29.06.16 12:33:16 [+0100] raspberrypi3-30fbcd-30fbcd
29.06.16 12:33:16 [+0100]
29.06.16 12:33:16 [+0100] Application exited 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:16 [+0100] Restarting application 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:18 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd
29.06.16 12:33:18 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd
29.06.16 12:33:18 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd
29.06.16 12:33:18 [+0100]
29.06.16 12:33:18 [+0100] Application exited 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:19 [+0100] Restarting application 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:21 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:21 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:21 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:21 [+0100]
29.06.16 12:33:21 [+0100] Application exited 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:22 [+0100] Restarting application 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:24 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:24 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:24 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:24 [+0100]
29.06.16 12:33:24 [+0100] Application exited 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:28 [+0100] Restarting application 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:29 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:29 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:29 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:30 [+0100]
9.06.16 12:33:30 [+0100] Application exited 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:36 [+0100] Restarting application 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'
29.06.16 12:33:40 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:40 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:40 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:40 [+0100] Application exited 'registry.resin.io/test/c6be287555ad93a8f0cde5d6daf986cf53c8d1dc'

...

29.06.16 12:33:54 [+0100] hostname: name too long
29.06.16 12:33:55 [+0100] raspberrypi3
29.06.16 12:33:55 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd
29.06.16 12:33:55 [+0100] raspberrypi3-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd-30fbcd

Hostname truncates UUID to 6 characters but we use 7 characters everywhere else

Can we change the device images to truncate to 7 as well

invalid hostename, denied permission, /tmp/console not found on RPi3

I get this errors/warnings if I try to run resin/raspberrypi3-node:latest on my raspberry pi 3 under arch linux:

$ docker run --rm -it resin/raspberrypi3-node node
Unable to find image 'resin/raspberrypi3-node:latest' locally
latest: Pulling from resin/raspberrypi3-node
[...]
Digest: sha256:f4a53345937ad416ff8adfad8e40476dc59a40fc751ba4133230cbed5aecbdfd
Status: Downloaded newer image for resin/raspberrypi3-node:latest
hostname: the specified hostname is invalid
mount: permission denied
mount: permission denied
mount: permission denied
mount: permission denied
mount: mount point /tmp/console is not a directory
umount: /dev: must be superuser to unmount
mount: permission denied
> 

Add timestamped tags to base-images

Add timestamped tags to base-images to avoid newly built images break user's apps

bug: python images uninstall build-essential in the process

It looks like build-essential gets uninstalled in our python images.

Add php images for resin devices

ARMv8 base images

Add Java base images

systemd booting logs are showed on resin dashboard logs

udevd use a lot of CPU

I've a situation with udevd witch take all the cpu

root 7588 1.0 0.2 4508 2332 ? Ss 15:56 0:00 _ /bin/bash /usr/bin/entry.sh /usr/local/bin/node index.js
root 7691 20.5 0.3 10664 2968 ? D 15:56 0:11 _ udevd
root 7704 0.1 0.3 9968 3336 ? D 15:56 0:00 | _ udevd
root 7709 0.1 0.2 9972 2100 ? D 15:56 0:00 | _ udevd
root 7710 0.1 0.3 9612 3248 ? D 15:56 0:00 | _ udevd
root 7711 0.1 0.2 9612 2688 ? D 15:56 0:00 | _ udevd
root 7712 0.1 0.2 9612 2632 ? D 15:56 0:00 | _ udevd
root 7713 0.1 0.2 9612 2684 ? D 15:56 0:00 | _ udevd
root 7714 0.1 0.2 9612 2444 ? D 15:56 0:00 | _ udevd
root 7715 0.1 0.1 9612 1824 ? D 15:56 0:00 | _ udevd
root 7721 0.1 0.1 9612 1840 ? D 15:56 0:00 | _ udevd
root 7722 0.1 0.1 9612 1840 ? D 15:56 0:00 | _ udevd
root 7723 0.1 0.2 9612 2400 ? D 15:56 0:00 | _ udevd
root 7724 0.1 0.2 9744 2008 ? D 15:56 0:00 | _ udevd
root 7725 0.1 0.2 9744 2008 ? D 15:56 0:00 | _ udevd
root 7726 0.1 0.2 9744 2012 ? D 15:56 0:00 | _ udevd
root 7727 0.1 0.2 9744 2072 ? D 15:56 0:00 | _ udevd
root 7728 0.1 0.1 9744 1892 ? D 15:56 0:00 | _ udevd

Am i alone in this situation ?

Add .NET base images

Bad error message when the CMD points to a file which does not exist

When trying in our image you get

$ docker run --privileged --env="RESIN_DEVICE_UUID=test" -it resin/raspberrypi-systemd foobar
/usr/bin/entry.sh: line 47: exec: : not found

which is not very informative, when trying in sh you get:

$ foobar
sh: 1: foobar: not found

which is a lot easier to understand

can/do we ignore all the doc files

can we exclude docs/locales since they're not much use on the device. I know we do this via the command COPY 01_nodoc /etc/dpkg/dpkg.cfg.d/ in other places I think.

contents of 01_nodoc

path-exclude /usr/share/doc/*
path-exclude /usr/share/man/*
path-exclude /usr/share/groff/*
path-exclude /usr/share/info/*
path-exclude /usr/share/lintian/*
path-exclude /usr/share/linda/*

path-exclude /usr/share/locale/*
path-include /usr/share/locale/en*

python images lack python-dev package

Python headers are useful for many packages, we should have it installed by default