Hi,
-----Original Message----- From: Stephen Lawrence Sent: 15 July 2020 18:48 To: Antonio Terceiro antonio.terceiro@linaro.org Cc: lava-users@lists.lavasoftware.org; gandersson@genivi.org Subject: RE: [Lava-users] fastboot in docker support
Therefore on a base level the dispatcher docker is allowing the host and device to find each other and the failure appears to relate to the different discovery and device passing code used by test/deploy to downloads. Could the new code bring requirements to the android-tool docker not needed before?
Yes, they work a bit differently.
For flashing lava itself just waits for the device to be available via udev, and since you have /run/udev mounted (and I assume also /dev) in the container it works because the device node is passed excplitily in the docker run call.
For the docker test action, first the docker container running your tests is spawned. we can't just pass the device node in the docker run call, because your tests can e.g. reboot the device, and we need it to become available again after rebooting, getting a new device number etc.
Therefor, for this case the device is shared dynamically with the container by lava-dispatcher-host, which is triggered from the udev daemon. Thus you need lava-dispatcher-host and its udev rules in the host operating system.
Ok, thanks for the summary. Once I have tested and provided feedback on your 'deploy to downloads' PR I'll have a look at trying to debug the new udev discovery failure.
Ok so with the local docker image support added to 'test with docker' and 'deploy to downloads' (thanks for that Antonio) I went back to try running fastboot from both. So I was running your PR 1268 (downloads: support local docker image for postprocessing)
1) 'test with docker': The udev discovery appears to be working now. It finds the device and attempts to pass it to the test docker. Testing did show an issue when the Worker is running in a docker container. I got a file error when the dispatcher could not access the sysfs devices.allow file for the test docker devices: https://lava.genivi.org/scheduler/job/1113#L193
That of course is just an issue of resource access from the Worker docker, but I just mention it as a fyi and in case it helps anyone who finds this later. As a stop gap, until I can consider the most secure method, I am currently working around this by sharing /sys/fs/cgroup/ into the Worker container. That works and I can now have 'test with docker' interacting with fastboot: https://lava.genivi.org/scheduler/job/1118#L232
Thank you to everyone who helped in getting it going. Just need to get the images into the test docker now. Hopefully I can do that with 'deploy to downloads' or the ability to mount a volume if it comes.
2) 'deploy to downloads': Here the behaviour is different to 'test with docker'. There appears to be no passing of the device and running fastboot from the host results in an eventual timeout. For example: https://lava.genivi.org/scheduler/job/1111#L142
For my flashing use case it may be that udev discovery support in 'test with docker' is sufficient. I thought I would raise the difference in behaviour in case you wanted to make it consistent at some point. Do you want me to raise an issue with the details?
Best Wishes,
Steve