Hi Conrad,
one of the devices in our setup is a nexus4, which will be most useful for reference.
It has this device dictionary jinja: {% extends 'nexus4.jinja2' %} {% set adb_serial_number = 'someserialnumber' %} {% set fastboot_serial_number = 'someserialnumber' %} {% set device_info = [{'board_id': 'someserialnumber'}] %} {% set static_info = [{'board_id': 'someserialnumber'}] %}
Maybe the fastboot_serial_number is the critical part here? I think some parts in the device type definition expected this value to be defined.
The device type is the nexus4 definition that is included in LAVA. It runs with the health check from the LAVA repos [1], expect that Debian Sid is replaced by Stretch for LXC (seems that the scripts are not compatible with the current Sid). Adding the following test demonstrates some fastboot commands that work here: - test: namespace: tlxc timeout: minutes: 5 definitions: - from: inline name: some-fastboot-commands path: inline/some-fastboot-commands.yaml repository: metadata: format: Lava-Test Test Definition 1.0 name: some-fastboot-commands description: "some-fastboot-commands" run: steps: - adb start-server || true - adb wait-for-device - adb reboot bootloader - sleep 60 - fastboot devices -l - fastboot reboot - sleep 10 - adb wait-for-device
The LAVA master+dispatcher are running on Debian Buster. LAVA version is 2018.2-1 (Debian packages).
[1] https://git.linaro.org/lava-team/refactoring.git/tree/health-checks/nexus4.y...
Regards, Karsten
On Wed, Apr 11, 2018 at 8:42 PM, Conrad Djedjebi <conrad.djedjebi@linaro.org
wrote:
Hi Karsten,
Thank you for your answer,
In the device dictionnary, I wrote the board_id number but neither vendor_id nor product_id. I did the same thing as you. My adb serial number is the same as my fastboot serial number. The board_id was set to adb/fastboot serial number.
It is really strange that the device is not being discovered in fastboot mode.
Can you share with me the configuration you used while testing fastboot? (Is it a debian LXC?, which versions of fastboot/adb packages did you use? If you runned a LAVA Test Job Definition, can you share it with me?). There must be a detail I missed.
Thanks
Regards,
Le mer. 11 avr. 2018 à 19:58, Karsten Tausche karsten@fairphone.com a écrit :
Hi,
out of curiosity I tried using fastboot on our setup. It works here without any issues. Could your problem be related to different USB meta data reported in adb and fastboot mode? The documentation here [1] suggests to add usb_vendor_id/usb_product_id to the device dictionary. However, these can be different in different boot stages. That's why I'm only setting board_id, which is for our devices the Android serial number and equal to iSerial reported by lsusb in fastboot and adb modes.
Regards, Karsten
[1] https://staging.validation.linaro.org/static/docs/v2/ admin-lxc-deploy.html#android-testing-with-lxc-support
On Wed, Apr 11, 2018 at 4:31 PM, Conrad Djedjebi < conrad.djedjebi@linaro.org> wrote:
Hi Senthil, Chris,
Thank you for your answers,
Senthil, the udev rule is triggered each time my device switch from fastboot to adb mode or from adb to fastboot mode. I tried the process of switching from adb to fastboot mode and vice versa in the container. Before that, I uninstalled fastboot and adb packages from the host so there is no way the adb and fastboot daemons of the host are creating conflicts with the fastboot and adb deamons of the container.
Each time the device enters adb mode, the udev rule is triggered and I can find the device with the command adb devices. But each time the device switchs to fastboot mode, I can 't see it with the command fastboot devices. I can see that the udev rule is triggered in the logs but the device is still not appearing. *I even did a "lxc-device -n myLxcName add /dev/bus/usb/001/056" manually to add the device to the container in fastboot mode*. The add process was done properly but there was still no fastboot device visible.
Chris, my container is successfully adding the usb device each time it is plugged. In adb mode, I can easily run Android CTS or Android VTS test suites on the device. So I think the container have access to "/dev/bus/usb" and also to the host's network stack.
Someone told me he had to add an additional mount entry into /usr/share/lxc/config/debian.common.conf otherwise fastboot could not see his device from the container. I will explore that option.
*I am still looking for a way to fix my issue anyway.*
regards,
On 8 April 2018 at 14:47, Senthil Kumaran S senthil.kumaran@linaro.org wrote:
Hi Conrad,
On Sunday 08 April 2018 06:39 PM, Conrad Djedjebi wrote:
I am currently running jobs on a device through adb without issues.
LAVA
is adding udev rules which make it possible for the LXC container to successfully attach the target.
However, when the device turns into fastboot mode, a "fastboot
devices"
command in the LXC returns nothing. In fastboot mode, the USB link of the device is added whereas the device is not listed among the
fastboot
devices.
The udev rules gets applied only when the device gets re-enumerated / restarted ie., on an udev add event. Otherwise the udev rule will not get applied to a device. For devices that are attached already when the job starts or if the device will not get re-enumerated, then use static_info as seen here - https://git-us.linaro.org/lava/lava-lab.git/tree/ staging.validation.linaro.org/master-configs/staging-master. lavalab/lava-server/dispatcher-config/devices/ staging-hi6220-hikey-r2-02.jinja2#n16 along with the device_info variable in the device dictionary.
In the host, a "fastboot devices" command returns the id of the
device.
I haven't faced this. But on the other hand when the host runs adb daemon, then it takes control of all the devices and the devices will not be visible from within the containers (LXC), even when the udev rule is applied. So care should be taken that 'adb' daemon is not running on the host. It is good, not to run any operation with fastboot too on the host, when the device is accessed via a container within the same host.
Thank You.
Senthil Kumaran S http://www.stylesen.org/ http://www.sasenthilkumaran.com/
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
Hi Karsten,
Thank you for your email,
I also added the fastboot serial number in my device definition file, so that information was available to LAVA during the job process in the LXC. However I did not write a static info in my dictionnary. Maybe that is the point. I will add the static info and see what happens.
According to LAVA documentation <<
- If the attached device re-enumerates on the worker each time that the DUT https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-dut is rebooted then device_info can be used. >>
So the static info should not have been needed in my case.
Regards,
Le jeu. 12 avr. 2018 à 09:34, Karsten Tausche karsten@fairphone.com a écrit :
Hi Conrad,
one of the devices in our setup is a nexus4, which will be most useful for reference.
It has this device dictionary jinja: {% extends 'nexus4.jinja2' %} {% set adb_serial_number = 'someserialnumber' %} {% set fastboot_serial_number = 'someserialnumber' %} {% set device_info = [{'board_id': 'someserialnumber'}] %} {% set static_info = [{'board_id': 'someserialnumber'}] %}
Maybe the fastboot_serial_number is the critical part here? I think some parts in the device type definition expected this value to be defined.
The device type is the nexus4 definition that is included in LAVA. It runs with the health check from the LAVA repos [1], expect that Debian Sid is replaced by Stretch for LXC (seems that the scripts are not compatible with the current Sid). Adding the following test demonstrates some fastboot commands that work here:
- test: namespace: tlxc timeout: minutes: 5 definitions:
- from: inline name: some-fastboot-commands path: inline/some-fastboot-commands.yaml repository: metadata: format: Lava-Test Test Definition 1.0 name: some-fastboot-commands description: "some-fastboot-commands" run: steps: - adb start-server || true - adb wait-for-device - adb reboot bootloader - sleep 60 - fastboot devices -l - fastboot reboot - sleep 10 - adb wait-for-device
The LAVA master+dispatcher are running on Debian Buster. LAVA version is 2018.2-1 (Debian packages).
[1] https://git.linaro.org/lava-team/refactoring.git/tree/health-checks/nexus4.y...
Regards, Karsten
On Wed, Apr 11, 2018 at 8:42 PM, Conrad Djedjebi < conrad.djedjebi@linaro.org> wrote:
Hi Karsten,
Thank you for your answer,
In the device dictionnary, I wrote the board_id number but neither vendor_id nor product_id. I did the same thing as you. My adb serial number is the same as my fastboot serial number. The board_id was set to adb/fastboot serial number.
It is really strange that the device is not being discovered in fastboot mode.
Can you share with me the configuration you used while testing fastboot? (Is it a debian LXC?, which versions of fastboot/adb packages did you use? If you runned a LAVA Test Job Definition, can you share it with me?). There must be a detail I missed.
Thanks
Regards,
Le mer. 11 avr. 2018 à 19:58, Karsten Tausche karsten@fairphone.com a écrit :
Hi,
out of curiosity I tried using fastboot on our setup. It works here without any issues. Could your problem be related to different USB meta data reported in adb and fastboot mode? The documentation here [1] suggests to add usb_vendor_id/usb_product_id to the device dictionary. However, these can be different in different boot stages. That's why I'm only setting board_id, which is for our devices the Android serial number and equal to iSerial reported by lsusb in fastboot and adb modes.
Regards, Karsten
[1] https://staging.validation.linaro.org/static/docs/v2/admin-lxc-deploy.html#a...
On Wed, Apr 11, 2018 at 4:31 PM, Conrad Djedjebi < conrad.djedjebi@linaro.org> wrote:
Hi Senthil, Chris,
Thank you for your answers,
Senthil, the udev rule is triggered each time my device switch from fastboot to adb mode or from adb to fastboot mode. I tried the process of switching from adb to fastboot mode and vice versa in the container. Before that, I uninstalled fastboot and adb packages from the host so there is no way the adb and fastboot daemons of the host are creating conflicts with the fastboot and adb deamons of the container.
Each time the device enters adb mode, the udev rule is triggered and I can find the device with the command adb devices. But each time the device switchs to fastboot mode, I can 't see it with the command fastboot devices. I can see that the udev rule is triggered in the logs but the device is still not appearing. *I even did a "lxc-device -n myLxcName add /dev/bus/usb/001/056" manually to add the device to the container in fastboot mode*. The add process was done properly but there was still no fastboot device visible.
Chris, my container is successfully adding the usb device each time it is plugged. In adb mode, I can easily run Android CTS or Android VTS test suites on the device. So I think the container have access to "/dev/bus/usb" and also to the host's network stack.
Someone told me he had to add an additional mount entry into /usr/share/lxc/config/debian.common.conf otherwise fastboot could not see his device from the container. I will explore that option.
*I am still looking for a way to fix my issue anyway.*
regards,
On 8 April 2018 at 14:47, Senthil Kumaran S <senthil.kumaran@linaro.org
wrote:
Hi Conrad,
On Sunday 08 April 2018 06:39 PM, Conrad Djedjebi wrote:
I am currently running jobs on a device through adb without issues.
LAVA
is adding udev rules which make it possible for the LXC container to successfully attach the target.
However, when the device turns into fastboot mode, a "fastboot
devices"
command in the LXC returns nothing. In fastboot mode, the USB link of the device is added whereas the device is not listed among the
fastboot
devices.
The udev rules gets applied only when the device gets re-enumerated / restarted ie., on an udev add event. Otherwise the udev rule will not get applied to a device. For devices that are attached already when the job starts or if the device will not get re-enumerated, then use static_info as seen here -
https://git-us.linaro.org/lava/lava-lab.git/tree/staging.validation.linaro.o... along with the device_info variable in the device dictionary.
In the host, a "fastboot devices" command returns the id of the
device.
I haven't faced this. But on the other hand when the host runs adb daemon, then it takes control of all the devices and the devices will not be visible from within the containers (LXC), even when the udev rule is applied. So care should be taken that 'adb' daemon is not running on the host. It is good, not to run any operation with fastboot too on the host, when the device is accessed via a container within the same host.
Thank You.
Senthil Kumaran S http://www.stylesen.org/ http://www.sasenthilkumaran.com/
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
Hi Karsten,
*I fixed the fastboot issue,*
While comparing the Job definition in the following file you provided me https://git.linaro.org/lava-team/refactoring.git/tree/ health-checks/nexus4.yaml with my LAVA Job Definition, I noticed the debian release used for LXC in your link was release stretch. In my case, I was deploying debian jessie LXCs. So I gave a try to LXC based on debian stretch and that solved the issue.
I must conclude there are some incompatibilities with LXC based on debian jessie while using fastboot.
Thank you for your help,
regards,
On 12 April 2018 at 09:45, Conrad Djedjebi conrad.djedjebi@linaro.org wrote:
Hi Karsten,
Thank you for your email,
I also added the fastboot serial number in my device definition file, so that information was available to LAVA during the job process in the LXC. However I did not write a static info in my dictionnary. Maybe that is the point. I will add the static info and see what happens.
According to LAVA documentation <<
- If the attached device re-enumerates on the worker each time that
the DUT https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-dut is rebooted then device_info can be used. >>
So the static info should not have been needed in my case.
Regards,
Le jeu. 12 avr. 2018 à 09:34, Karsten Tausche karsten@fairphone.com a écrit :
Hi Conrad,
one of the devices in our setup is a nexus4, which will be most useful for reference.
It has this device dictionary jinja: {% extends 'nexus4.jinja2' %} {% set adb_serial_number = 'someserialnumber' %} {% set fastboot_serial_number = 'someserialnumber' %} {% set device_info = [{'board_id': 'someserialnumber'}] %} {% set static_info = [{'board_id': 'someserialnumber'}] %}
Maybe the fastboot_serial_number is the critical part here? I think some parts in the device type definition expected this value to be defined.
The device type is the nexus4 definition that is included in LAVA. It runs with the health check from the LAVA repos [1], expect that Debian Sid is replaced by Stretch for LXC (seems that the scripts are not compatible with the current Sid). Adding the following test demonstrates some fastboot commands that work here:
- test: namespace: tlxc timeout: minutes: 5 definitions:
- from: inline name: some-fastboot-commands path: inline/some-fastboot-commands.yaml repository: metadata: format: Lava-Test Test Definition 1.0 name: some-fastboot-commands description: "some-fastboot-commands" run: steps: - adb start-server || true - adb wait-for-device - adb reboot bootloader - sleep 60 - fastboot devices -l - fastboot reboot - sleep 10 - adb wait-for-device
The LAVA master+dispatcher are running on Debian Buster. LAVA version is 2018.2-1 (Debian packages).
[1] https://git.linaro.org/lava-team/refactoring.git/tree/ health-checks/nexus4.yaml
Regards, Karsten
On Wed, Apr 11, 2018 at 8:42 PM, Conrad Djedjebi < conrad.djedjebi@linaro.org> wrote:
Hi Karsten,
Thank you for your answer,
In the device dictionnary, I wrote the board_id number but neither vendor_id nor product_id. I did the same thing as you. My adb serial number is the same as my fastboot serial number. The board_id was set to adb/fastboot serial number.
It is really strange that the device is not being discovered in fastboot mode.
Can you share with me the configuration you used while testing fastboot? (Is it a debian LXC?, which versions of fastboot/adb packages did you use? If you runned a LAVA Test Job Definition, can you share it with me?). There must be a detail I missed.
Thanks
Regards,
Le mer. 11 avr. 2018 à 19:58, Karsten Tausche karsten@fairphone.com a écrit :
Hi,
out of curiosity I tried using fastboot on our setup. It works here without any issues. Could your problem be related to different USB meta data reported in adb and fastboot mode? The documentation here [1] suggests to add usb_vendor_id/usb_product_id to the device dictionary. However, these can be different in different boot stages. That's why I'm only setting board_id, which is for our devices the Android serial number and equal to iSerial reported by lsusb in fastboot and adb modes.
Regards, Karsten
[1] https://staging.validation.linaro.org/static/docs/v2/ admin-lxc-deploy.html#android-testing-with-lxc-support
On Wed, Apr 11, 2018 at 4:31 PM, Conrad Djedjebi < conrad.djedjebi@linaro.org> wrote:
Hi Senthil, Chris,
Thank you for your answers,
Senthil, the udev rule is triggered each time my device switch from fastboot to adb mode or from adb to fastboot mode. I tried the process of switching from adb to fastboot mode and vice versa in the container. Before that, I uninstalled fastboot and adb packages from the host so there is no way the adb and fastboot daemons of the host are creating conflicts with the fastboot and adb deamons of the container.
Each time the device enters adb mode, the udev rule is triggered and I can find the device with the command adb devices. But each time the device switchs to fastboot mode, I can 't see it with the command fastboot devices. I can see that the udev rule is triggered in the logs but the device is still not appearing. *I even did a "lxc-device -n myLxcName add /dev/bus/usb/001/056" manually to add the device to the container in fastboot mode*. The add process was done properly but there was still no fastboot device visible.
Chris, my container is successfully adding the usb device each time it is plugged. In adb mode, I can easily run Android CTS or Android VTS test suites on the device. So I think the container have access to "/dev/bus/usb" and also to the host's network stack.
Someone told me he had to add an additional mount entry into /usr/share/lxc/config/debian.common.conf otherwise fastboot could not see his device from the container. I will explore that option.
*I am still looking for a way to fix my issue anyway.*
regards,
On 8 April 2018 at 14:47, Senthil Kumaran S < senthil.kumaran@linaro.org> wrote:
Hi Conrad,
On Sunday 08 April 2018 06:39 PM, Conrad Djedjebi wrote: > I am currently running jobs on a device through adb without issues. LAVA > is adding udev rules which make it possible for the LXC container to > successfully attach the target. > > However, when the device turns into fastboot mode, a "fastboot devices" > command in the LXC returns nothing. In fastboot mode, the USB link of > the device is added whereas the device is not listed among the fastboot > devices.
The udev rules gets applied only when the device gets re-enumerated / restarted ie., on an udev add event. Otherwise the udev rule will not get applied to a device. For devices that are attached already when the job starts or if the device will not get re-enumerated, then use static_info as seen here - https://git-us.linaro.org/lava/lava-lab.git/tree/ staging.validation.linaro.org/master-configs/staging-master. lavalab/lava-server/dispatcher-config/devices/ staging-hi6220-hikey-r2-02.jinja2#n16 along with the device_info variable in the device dictionary.
> In the host, a "fastboot devices" command returns the id of the device.
I haven't faced this. But on the other hand when the host runs adb daemon, then it takes control of all the devices and the devices will not be visible from within the containers (LXC), even when the udev rule is applied. So care should be taken that 'adb' daemon is not running on the host. It is good, not to run any operation with fastboot too on the host, when the device is accessed via a container within the same host.
Thank You.
Senthil Kumaran S http://www.stylesen.org/ http://www.sasenthilkumaran.com/
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
lava-users@lists.lavasoftware.org
-
Conrad Djedjebi -
Karsten Tausche