-----Original Message----- From: Antonio Terceiro antonio.terceiro@linaro.org Sent: 12 August 2020 14:59 To: Stephen Lawrence stephen.lawrence@renesas.com Cc: lava-users@lists.lavasoftware.org Subject: Re: fastboot reboot-bootloader from docker test shell (was "fastboot in docker support")
[snip]
It should be enough. see if there are any errors in the udev logs. e.g. if lava-dispatcher-host fails for some reason there will be a correspoding line there (but no output unfortunately as udev does not capture it, only the failure exit code)
Thanks for the hints. Nothing in the host logs from lava-dispatcher-host via journalctl. In the worker container there is no systemd and in the lava-slave /var/log I don't see anything.
At this current moment it feels more a fundamental lava worker in docker issue given the lack of udev events being reported by udevadm monitor in the worker container. That the udev discovery code in lava-dispatcher-host has no chance if there are no events. Unless something about the container environment means I can not take the udevadm reporting at face value.
btw just a couple of additional comments about my post earlier today. I'm really trying not to be that new guy to a list who just spams with their issues and 'fix this next one' one after another. I did not mean that the developers should be maintaining some nice document set for running LAVA in docker.
I just meant two main points. Firstly, how the devs thought udev should work in such a lava environment - if its been considered. Secondly, that the wider community can collaborate on some patterns as to what needs to be shared into a container for certain LAVA services to work. Of course that can be codified where sensible in the docker base image or downstream projects like lava-docker. Web searches about enabling udev in docker containers returns very little outside some hacks.
Meanwhile I will try running the container in more privileged modes to see if that sparks some life.
Regards
Steve