-----Original Message----- From: Antonio Terceiro antonio.terceiro@linaro.org Sent: 10 August 2020 21:13 To: Stephen Lawrence stephen.lawrence@renesas.com Cc: lava-users@lists.lavasoftware.org Subject: fastboot reboot-bootloader from docker test shell (was "fastboot in docker support")
[snip]
Just to simplify further and eliminate the possibility that the recent PR didn't have all the code I retested using the latest code. LAVA master branch HEAD~3 (sha a2bd1a87). I got the same results, with fastboot on the host not finding the device after reboot: https://lava.genivi.org/scheduler/job/1166
Hi,
I could reproduce your issue with a job like this (I reboot from adb first because $reasons):
run: steps: - adb devices - adb reboot-bootloader - fastboot devices - fastboot reboot-bootloader - fastboot devicesThis seems to be a timing issue. When I add a sleep between `fastboot reboot-bootloader` and the following `fastboot devices`, it works:
2020-08-10T20:04:22 + fastboot reboot-bootloader 2020-08-10T20:04:22 < waiting for 69E78A7B00325ACE > 2020-08-10T20:04:27 Sharing /dev/bus/usb/001/083 with docker container lava-docker- test-shell-380-3.3 2020-08-10T20:04:27 rebooting into bootloader... 2020-08-10T20:04:27 OKAY [ 0.001s] 2020-08-10T20:04:30 finished. total time: 3.011s 2020-08-10T20:04:30 + sleep 10s 2020-08-10T20:04:30 Sharing /dev/bus/usb/001/084 with docker container lava-docker- test-shell-380-3.3 2020-08-10T20:04:40 + fastboot devices 2020-08-10T20:04:40 69E78A7B00325ACE fastboot
Hi,
Thank you for taking the time to look into this. We really appreciate it.
of course sleeping is a lazy hack and not a real solution, the point is: when LAVA itself triggers reboots/resets, it usually also handles the waiting for you, but when you do it yourself, you need to do it yourself.
Ok not ideal, but I think the sleep after a reboot would be fine - especially as a first solution to get us moving on to some testing. I realise we are operating in some what of a corner case in using fastboot commands not supported in 'deploy'.
In my simplified case I have a 'fastboot --set-active' after the reboot that will cause the host to naturally wait, but I did wonder about the discovery code getting the chance to find and share the restarted device. So anyway I tried a 10s and 20s sleep after the reboot. Unfortunately still no device discovery after reboot: https://lava.genivi.org/scheduler/job/1176#L240 https://lava.genivi.org/scheduler/job/1177#L240
I think I need to deep dive the new discovery code to better understand what methods need to be supported. It feels like it might be something minor. A missing udev rule or something extra required in the device dict like usb IDs to trigger the discovery the second time. It's curious that the serial number is sufficient for discovery to succeed the first time though.
The other thought is my recent mea culpa over the changes for tee support and having a Worker that is running newer code than the Master. Looking at your changes it appears they are confined to the Worker only, but that is another possibility if you know that in fact a change on the Master is required as well.
Regards
Steve