Thanks for the fast reply @jeremias.tx,
I’ve made the repository producing a symlink public for your testing: Docker Hub. Let me know when we can set it private again, but it contains no critical code and is simply a small edit of Weston. I hope it still occurs using only that repo, but I suspect it will as the symlink pointed to another layer within that image. The docker-compose snippet of this weston container is included below. I did find some info online that this is a thing docker save can do. I also manually replaced the symlink with a copy of the layer.tar it pointed to which seemed to fix the issue. I’ll be scripting that step if necessary.
This did seem to be consistent yes. It always occurs in the same spot and I tried a few different lockboxes and copy methods before I singled in on the issue.
I can try the docker load later, but don’t have the time now.
Kind regards,
Ernest Van Hoecke
weston container definition in docker-compose:
weston:
cap_add:
- CAP_SYS_TTY_CONFIG
container_name: weston
device_cgroup_rules:
- c 4:0 rmw
- c 4:7 rmw
- c 13:* rmw
- c 199:* rmw
- c 226:* rmw
environment:
ACCEPT_FSL_EULA: '1'
image: jabbla/allora3-weston@sha256:73aa9327063a85d943cf31471bb123a1b61b7fc4585111cd29f034f74db9026a
network_mode: host
restart: unless-stopped
volumes:
- source: /tmp
target: /tmp
type: bind
- source: /dev
target: /dev
type: bind
- source: /run/udev
target: /run/udev
type: bind
- source: /allora3/weston/weston.ini
target: /etc/xdg/weston/weston.ini
type: bind
- source: /allora3/weston/icons
target: /usr/share/icons
type: bind