[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
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
@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?
/dev/*
individually and enable evdev
unless we’re making the container privileged, is that correct?
docker-compose.yml
filet@valentinalexeev I'm not sure I understand what you are trying to do.
So far I gather:
/config
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'
services:
service1:
image: "alpine"
command: touch /config/test
volumes:
- service1-config:/config
service2:
image: "alpine"
command: ls -la /data/other-config
volumes:
- resin-data:/data
- service1-config:/data/other-config
depends_on:
- service1
volumes:
resin-data:
service1-config:
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
.
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.
docker-compose.yml
that 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/