Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
  • Aug 11 20:19
    jakogut opened #2757
  • Aug 11 18:20
    jakogut synchronize #2752
  • Aug 11 16:41
    renovate[bot] edited #899
  • Aug 11 16:24
    lmbarros synchronize #2734
  • Aug 11 16:20
    alexgg commented #2755
  • Aug 11 16:17
    lmbarros edited #2734
  • Aug 11 16:15
    lmbarros commented #2326
  • Aug 11 16:14
    lmbarros edited #2734
  • Aug 11 16:12
    lmbarros commented #2423
  • Aug 11 16:08
    jellyfish-bot closed #1314
  • Aug 11 16:08
    jellyfish-bot reopened #1314
  • Aug 11 16:07
    jellyfish-bot edited #1314
  • Aug 11 16:07
    alexgg closed #1314
  • Aug 11 16:07
    alexgg commented #1314
  • Aug 11 16:05
    alexgg commented #1676
  • Aug 11 16:02
    alexgg closed #1977
  • Aug 11 16:02
    alexgg commented #1977
  • Aug 11 16:01
    alexgg closed #1983
  • Aug 11 16:01
    alexgg commented #1983
  • Aug 11 15:58
    alexgg closed #2088
Gutemberg Ribeiro
@imrehg I made one progress yesterday before sleep
the problem is that for whatever reason, ioctl calls are failing
which I use to figureout some of the display capabilities
so I’ve hardcoded the /dev/fb0
and it don’t crash anymore. Hoever, it doesn’t draw anything to the screen
I’m checking on that now
Gutemberg Ribeiro

ok, now changing the compose file to include:

      - "/dev/fb0:/dev/fb0"
      - SYS_RAWIO

And on the Dockerfile:

it works
but for whatever reason the app screen is showing that tons of messages :/
Gutemberg Ribeiro
I was able to build the kernel module for my touch display and load it
[Logs]    [4/7/2019, 9:06:06 AM] [main] OS Version is 2.31.5+rev1
[Logs]    [4/7/2019, 9:06:06 AM] [main] Loading Elo Touch Kernel Module: elo_mt_input_mod_2.31.5+rev1.ko
[Logs]    [4/7/2019, 9:06:09 AM] [main] elo_mt_input_mod       16384  0
@imrehg however, I had to hack the build scripts from the sample u gave me… it isn’t able to find the kernel module headers for that 2.31.5+rev1 yet so I’ve change it to get the 2.26.0+rev1 ones and then renamed the module to use the .31 one and it loaded… I guess it is because the version you gave me isn’t pushed to production yet so we don’t have the headers
now need to figure out how to get files from the build container in balena :)
Balena team
[Gergely Imreh (imrehg)] @galvesribiero yeah, those files are uploaded when the version is released, which hasn't happened yet. Should have been clearer.
Not sure what you mean by getting the Iles from the build container in balena. Are those the kernel modules? If so it is just a modprobe inside the container, isn't it?
We'll be able to help more during the week though, when the release is done and the team is around.
What hardware you use for your screen? What driver is needed? The touch support? If so, where is the source you use for that module?
Gutemberg Ribeiro

Not sure what you mean by getting the Iles from the build container in balena.

I meant files :) Already got it thanks to transfer.sh :P

Are those the kernel modules? If so it is just a modprobe inside the container, isn't it?

The touch display has its own kernel module and a daemon that is started. Without that running, the kernel report wrong events to evdev

that is the touch display
let me get the driver source
the daemon is already built (proprietary code from Elo) for armv7lhf but they provide the driver source there so we can build for different kernels
there is a readme.txt on the root that explain what they want in order to build it
Balena team
[Trevor Sullivan (pcgeek86)] Is there a thread with context? @imrehg

@resinio I faced a strange error on one device running supervisor 9.11.3.
Deployment was successful to the app and only the device running the most recent version of the supervisor did not download the latest release. I tried issuing a restart of the app running in that device and a red banner popped up with the message
"Request error: There was an error validating configuration input for key: persistentLogging, with value:" and the device does not respond at all.
I also tried enabling "persistent logging" and the config.json inside the supervisor is also not being affected .
I Then also checked supervisor logs and got

Supervisor API: GET /v1/healthy 200 - 10.530 ms
[2019-04-08T08:25:15.438Z] Event: Restart container (v1) {"appId":6666666}
Supervisor API: POST /v1/restart 503 - 101.114 ms
[2019-04-08T08:26:46.023Z] Applying target state
[2019-04-08T08:26:46.148Z] Scheduling another update attempt due to failure: 900000 { t: There was an error validating configuration input for key: persistentLogging, with value:
at t.checkValueDecode (/usr/src/app/dist/app.js:300:130397)
at /usr/src/app/dist/app.js:300:127019
message: 'There was an error validating configuration input for key: persistentLogging, with value: ',
name: 't' }

Any ideas?

Balena team
[Cameron Diver (CameronDiver)] @me-sosa the parsing of values for environment and configuration values has been tightened up recently. This specific error comes from the fact that you have an empty string as the value for `RESIN_SUPERVISOR_PERSISTENT_LOGGING` on the dashboard, or you have `"persistentLogging": ""` in your config.json. If you remove the offending entry, and restart the supervisor `systemctl restart resin-supervisor` you should be good to go
[Cameron Diver (CameronDiver)] this has also been changed in later versions of the supervisor, which will fall back to the default value when an environment variable fails parsing
ok, done. Now that device is being updated. Thanks.
Are you planning a new release? Do you have an ETA and github link to follow?
I am asking this since there are also more devices in prod with the same config.
Valentin Alexeev
hi everyone! a quick reach to the community wisdom - how do you manage shared resin-data volume between the apps? I'm using some stock docker images which have no way to set specific paths for their files in a volume and it creates a mess in the shared volume. Is this something I can fix with configuration on balena or I should work on the images?
Gutemberg Ribeiro
hey folks
@imrehg question… if I understood correctly, it looks like recent versions of Balena doesn’t allow us to map /dev/* individually and enable evdev unless we’re making the container privileged, is that correct?
I’m just concerned that the container will have access to the whole host when it is not necessary when you make /dev/* available
Balena team
[Shaun Mulligan (shaunmulligan)] @galvesribeiro can you ask this question in the forums please
Gutemberg Ribeiro
Gergely Imreh
@valentinalexeev you have to set named volumes for the different services, in your docker-compose.yml filet
https://www.balena.io/docs/learn/develop/multicontainer/#named-volumes and more particularly similarly how in this Stack Overflow answer https://stackoverflow.com/a/44284993 as we only support these named volumes format (and inside the two container you can set the path where to mount it different)
Valentin Alexeev
@imrehg "inside the two container you can set the path where to mount it different" - this is where the problem is. One of the containers exposes a mount point /config which I want to be somewhere on resin-data shared volume in e.g. folder /[container-name]/config
Gergely Imreh

@valentinalexeev I'm not sure I understand what you are trying to do.
So far I gather:

  • there's one service that should have a volume at /config
  • another service might access that in a shared volume, that you want to mount inside another existing volume?

I think the important part is that you can have volumes and mount them in different places in different service, don't have to be at the same place. Just set their internal endpoint to the right one your service needs. So for a simplified version, here's a docker-compose.yml, that you can try on your development machine (if you have docker and docker compose installed) with docker-compose run, so you can play with the volumes:

version: '2.1'
    image: "alpine"
    command: touch /config/test
      - service1-config:/config
    image: "alpine"
    command: ls -la /data/other-config
      - resin-data:/data
      - service1-config:/data/other-config
      - service1


This will result in something like:

$ docker-compose up
Starting volumes_service1_1 ... done
Starting volumes_service2_1 ... done
Attaching to volumes_service1_1, volumes_service2_1
service2_1  | total 8
volumes_service1_1 exited with code 0
service2_1  | drwxr-xr-x    2 root     root          4096 Apr  9 17:20 .
service2_1  | drwxr-xr-x    3 root     root          4096 Apr  9 17:18 ..
service2_1  | -rw-r--r--    1 root     root             0 Apr  9 17:24 test
volumes_service2_1 exited with code 0

thus in service2 you can see the test file created by service1.

But it's in the service1-config volume, not related to the resin-data volume at all (that volume alone is empty), and you don't need that. Just use the volumes you want to share between services, and set the internal mount points where you need them or want to use them. For example if service1 needs a volume mounted at /config, that 's fine, in other service , maybe in service2 you control the code, just mount wherever it makes sense.
Not sure if this helps at all, but hope so. :) If you have some more concrete example of what you want to achieve (maybe the docker-compose.ymlthat you are trying to use?) then we can give more specific advice. Also would recommend posting it in our forums, where there's more chance to get feedback and quicker https://forums.balena.io/
Gutemberg Ribeiro
if anyone can shed a light on this issue https://forums.balena.io/t/build-kernel-modules-on-ci-servers-for-balenaos/5972 I would appreciate that. Thanks!
Gutemberg Ribeiro
@resinio folks, can someone make my post visible again? https://forums.balena.io/t/build-kernel-modules-on-ci-servers-for-balenaos/5972/6
I’ve posted a long log as requested by someone on the team and the Akismet thought it was spam :(
Shaun Mulligan
@galvesribeiro it should be visible now
Gutemberg Ribeiro
:+1: tkz
Gutemberg Ribeiro
@imrehg yo! Updates on the release of the Tinkerboard images?
Gutemberg Ribeiro
@shaunmulligan do you have any updates on the Tinkerboard images?
also, the lack of rotate support for Tinkerboard is really a problem for us :( we’re running kiosks as the main devices for Balena, and without rotation, we’re screwed
Balena team
[Shaun Mulligan (shaunmulligan)] @galvesribeiro i believe @imrehg was doing the final round of testing
[Shaun Mulligan (shaunmulligan)] there will definitely be a way to rotate the screen, but will need to find out from ASUS if there is a hardware specific way to do it, otherwise you will need to do it in software via xorg or whatever windows manager your kiosk system uses