Hi Antonio,
-----Original Message----- From: Lava-users lava-users-bounces@lists.lavasoftware.org On Behalf Of Antonio Terceiro Sent: 30 June 2020 18:55 To: lava-users@lists.lavasoftware.org Subject: Re: [Lava-users] fastboot in docker support
[snip]
I had seen this udev.py failure when first working with the new docker changes in
2020.02.
Then the fix was to shared the udev database (/run/udev) into the container. So I was wondering if I had missed a change when migrating from 2020.02 to 2020.05 and that's a check I need to complete but it is weird that the WaitDeviceBoardID succeeds for the
simple
deploy case. So it does not appear to be a simple containerisation issue.
The current implementation shares the devices with the container via the docker run --device= option, and for that it needs the device to be available (hence the WaitDeviceBoardID). That works for simple test jobs but doesn't for more complex ones.
I'm finishing a set of patches right now that changes the implementation and solves this by not waiting forever, sharing any devices that are already available with the container upfront, and adding dynamic mappings so that devices are shared with the container on udev events when they appear.
OK. I look forward to the patches. The links I provided are to an oss alliance lava instance so you can get information on the setup, but if there is anything information you want to check your changes cover this simple case then please get in touch.
Whilst I wait on the patches I'll try disabling the wait test in the test python. I've not checked but hopefully the code determining which USB device to pass into the docker run is independent of it. I know the container has what it needs to complete the fastboot communication so if the correct device is passed then it should work if the wait is skipped and the container started.
In parallel I might also try running the flash script from a test section although that approach requires I deal with getting the images into the container.
Regards
Steve