Hi,
I have some questions about the fastboot/adb in docker support I hope you can help with.
Use case is for android 10 aosp testing with LAVA 2020.05.
Thanks to Antonio's presentation and draft documentation I have simple fastboot host to
DUT communication working for a u-boot based arm64 board. I am now trying to apply an
existing flash process, which uses a script on the host to send fastboot cmds, into a LAVA job.
I can see how fastboot --set-active, reboot and flash commands all have equivalent controls
in a 'deploy to fastboot docker' LAVA job section. Do equivalents exist for the fastboot
oem format, oem erase, format and erase commands or is there a way to insert them
in the deploy?
Expecting that will take some engineering work, in parallel I wanted as a stop gap to try
running the flash script from a LAVA job. So people could work on the testing side whilst
I resolved the deploy section. Antonio suggested trying to do that from the test section
I recall.
To do that I face two issues:
1) The build artifacts are on a local volume rather than an artifact server so I need to
get them into the docker container in an automated way. Is there a way to either mount
a local volume or file list into the container without asking LAVA to deploy them?
As an experiment I tried using the docker image manipulation added in 2020.04 to do
this. There I hit a problem with the current implementation. It seems the 'deploy to
downloads' implementation does not check for a local image first, as the other docker
support does, before trying to pull the image. So I get an error when the pull fails:
https://lava.genivi.org/scheduler/job/961#L24
2) The job needs to be able to boot the DUT, interrupt u-boot and start fastboot
so the host has something to communicate with once the test section is reached.
I can achieve that in a horrible hacky way by having a deploy section with a simple
single flash image (dtbo say) and using the reboot controls to get the board to reboot into
fastboot to await the flash script being run from the test section, but I expect there
is a better way. Any ideas?
Regards
Steve
Dear lava-users,
I'm intern at /e/ foundation and working on using LAVA to test our OS updates. We are trying to configure our system in order to use the recent feature allowing the use of docker instead of LXC containers. On this point we are grateful to the developpers for adding this possibility because we were having problems with LXC.
Now we are having issues because we can't flash our OS through fastboot, we have to use adb sideload with .zip archives. By the way, we can't do it through the classic deploy section. We came with the idea of just flashing a twrp recovery partition via the deploy section using fastboot, and then trying to run shell commands in the test section to be able to use adb sideload and install our ROM.
For the moment as you can see in the job we didn't add all the shell commands because we already have some problems with this simple try. The objective would be to pass this booting into recovery step and then try to continue with adb sideload. I've also joined the logs and the device and device type dictionaries. I would like to have your opinion and advices on what we are trying to achieve.
Best regards,
Baptiste and the /e/ team
Hello everyone,
I would like to integrate the u-boot tests suite (pytest) in lava. ( https://github.com/u-boot/u-boot/tree/master/test/py)
We are now executing the test suite manually, using a host machine and the DUT.
The u-boot tests suite is installed on a host computer and the DUT is "stopped" in uboot environment.
The host computer execute the "u-boot pytest" framework, commands are sent to the DUT and tests results are collected to the host computer.
It is a "semi automatic" tests and I would like to do a full automation using LAVA.
I plan to use multinode jobs, one job instances for the DUT and another one for the remote host computer.
So, I would like to know if such tests have already been craeted in LAVA, and if someone could give me advice on this tests implementation.
My Lava version is: 2020.06
Best regards
Philippe Begnic
STMicroelectronics
Hello,
We are wanting to update to a more recent LAVA docker release, we've been at 2019.12 since it was released. Our configuration relies on lxc, and after moving to 2020.01 all of our test jobs hit the error "lxc container 'lxc-test-17071' already exists" very early on (17071 is the test job number). I've pasted our device configuration, test job, and log output in the below pastebin. What should we do to keep our LAVA jobs working with the 2020.01 release and beyond?
https://pastebin.com/UQixc6RS
Thanks,
Alex
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hi,
For imx armv7 series board, tee is default not built in, there is a separate file there to play the role.
I'm not sure for next scenario, if LAVA could handle it with "method: u-boot commands: nfs"? Could you give some guide?
setenv autoload no
setenv initrd_high 0xffffffff
setenv fdt_high 0xffffffff
dhcp
setenv serverip 10.192.244.84
tftp 0x12000000 trial/zImage-imx6qsabresd.bin
tftp 0x18000000 trial/zImage-imx6q-sabresd.dtb
tftp 0x20000000 trial/uTee-6qsdb
tftp 0x12C00000 trial/ramdisk.cpio.gz.uboot
bootm 0x20000000 0x12C00000 0x18000000
If not, if you have buffer to add the support? Or we can submit a MR for review?
Thanks Antonio for the clarify.
A side question:
For docker test shell, if possible add more docker options for user? E.g. bind mount, etc.
A scenario is:
If we have some code needed when test, currently, we could just inject it into docker image when do docker build, or when test git clone the code from network.
You know docker test shell use `--rm`, means every time, we need to git clone it, or if a small changes we need to build the image.
A bind mount there to mount our code may make things easier for us?
-----Original Message-----
From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of lava-users-request(a)lists.lavasoftware.org
Sent: Saturday, June 6, 2020 8:00 PM
To: lava-users(a)lists.lavasoftware.org
Subject: [EXT] Lava-users Digest, Vol 22, Issue 7
Caution: EXT Email
Send Lava-users mailing list submissions to
lava-users(a)lists.lavasoftware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…
or, via email, send a message with subject or body 'help' to
lava-users-request(a)lists.lavasoftware.org
You can reach the person managing the list at
lava-users-owner(a)lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..."
Today's Topics:
1. Re: [EXT] Re: docker shell cannot handle adbd. (Antonio Terceiro)
----------------------------------------------------------------------
Message: 1
Date: Fri, 5 Jun 2020 09:26:18 -0300
From: Antonio Terceiro <antonio.terceiro(a)linaro.org>
To: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] [EXT] Re: docker shell cannot handle adbd.
Message-ID: <20200605122618.GA359587(a)linaro.org>
Content-Type: text/plain; charset="us-ascii"
On Fri, Jun 05, 2020 at 07:06:16AM +0000, Larry Shen wrote:
> Hi, Milosz,
>
> Maybe I understand wrong, but I already see there is code like next to
> add dynamic device node to docker container.
>
> I tried it in manual, adb find devices after a new device node added
> with next code. But I don't see the docker shell try to call it with
> some way. What's the aim of next code if you did not want to use it?
> Could you double confirm internal maybe some guys is handling it, but
> just in process? Could you do me a favor inform me your plan if my
> guess is true?
>
> I don't think people could switch from lxc to docker on android if
> this not support, maybe my environment wrong or anything else?
Yes, you are right. The way the docker test shell currently works won't support such a use case.
First, there was an issue with the udev rules being too strict, which was recently fixed and will be in the next release:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…
This issue that you mention also needs to be fixed; I created an issue to track and I will work on it:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…
