- lava-devel - op-lists.linaro.org

by Вова Богословский

Hello, I am a user of the lava software package. For one of the use cases, I need an ipxe bootloader, I tried to use the one you collected from here https://docs.lavasoftware.org/lava/ipxe.html, but it does not have download via nfs. I tried to build a regular ipxe loader, but it is not compatible with lava due to text colorization. Can you please tell me if it is possible to find somewhere a patch that was used in the build of the bootloader to remove the text colorization? Best regards, Volga Bogoslovskiy

4 years, 2 months

1
0
0 0

How to retrieve the prompt content with Uboot

by Roselyne MAZIERES

Hello, We are writing an interactive test for uboot. Here is the command we send: timer start && nand read \${TMPADDR} ${nand_offset} \${TMPSIZE} && timer get || run fail And below is what we get. In the traces, after the "524288 bytes read: OK", there is the timer info: 0.080. We need to be able to catch this value and we need to perform computation on it and some comparison afterwards. Do you have a solution to do that? What would you advise us to do? Thanks a lot for your help! Best regards, Roselyne Mazières [cid:image001.png@01D837B6.3FFE36F0] Internal

4 years, 3 months

1
0
0 0

iso-installer for ubuntu 20.04

by Moein Shafi

Hello everyone, I'm new to LAVA and I have some issue with 'iso-installer' for ubuntu 20.04 . As you know, in ubuntu 20.04 the preseed file would not use 'debian_installer' and use 'subiquity' instead, Also LAVA does not support 'subiquity' for 'iso-installer', so I don't know how can I use 'iso-installer' for testing my ubuntu 20.04.

5 years, 1 month

1
0
0 0

WG: Help with new device integration

by Marcel Trattner

Dear Lava-Team, I contacted you a few weeks ago for some help with the integration of a new device. We got a bit further thanks to you but we're faceing some new issues and we hoped that you could help us with this. We are using the official Docker-Compose<https://git.lavasoftware.org/lava/pkg/docker-compose> repository and specified a new device dictionary on the server container. As a device type we use a newly created device type that extends base-fastboot device-type, which looks like this: {% extends 'rse22.jinja2' %} {% set power_on_command = 'python ./root/power-control/ppson.py' %} {% set power_off_command = 'python ./root/power-control/ppsoff.py' %} {% soft_reboot_command = 'reboot' %} {% hard_reset_command = 'python ./root/power-control/ppsoff.py && sleep 5 && python ./root/power-control/ppson.py' %} {% set connection_list = [uart0] %} {% set connection_commands = {uart0: telnet <ip_host_machine> 7101} %} {% set connection_tags = {uart0: [primary, 'telnet']} %} But with this we received the following error: [cid:image001.png@01D6EE7C.31C35A90] The error disappeared however when we removed the following lines: {% set power_on_command = 'python ./root/power-control/ppson.py' %} {% set power_off_command = 'python ./root/power-control/ppsoff.py' %} {% soft_reboot_command = 'reboot' %} {% hard_reset_command = 'python ./root/power-control/ppsoff.py && sleep 5 && python ./root/power-control/ppson.py' %} With those lines we are trying to trigger the scripts, which control our power supply directly. Do we have to pay attention to the python dependencies in the scripts or could the error be in the definition itself? We thought, that we had at least configured the device dictionary sufficiently to have a connection to the device and start a very basic health check. Our device runs Linux, which is running Android on top. The Ser2Net connection has been configured according to the instructions on the repo as well (using the telnet command by itself worked fine). So we specified the health check like this: device_type: rsu job_name: Health Check for RSU timeouts: job: minutes: 30 action: minutes: 5 connection: minutes: 2 priority: medium visibility: public actions: - deploy: namespace: tlxc timeout: minutes: 5 to: lxc packages: - android-tools-adb - android-tools-fastboot - boot: method: lxc prompts: - 'root@(.*):/#' timeout: minutes: 5 - test: timeout: minutes: 4 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: hello-world description: "say hello" os: - android scope: - functional run: steps: - apt -q update - pwd - echo "echo hello" # remember to use -y to allow apt to proceed without interaction # -q simplifies the apt output for logging. from: inline name: hello-world path: inline/hello-world.yaml When executing, we got the following error: [cid:image002.png@01D6EE7E.9CED3690] Could you please give us some advice, on how to define a test job/health check for a device, which uses fast-boot and Android? Your help would be greatly appreciated. Best regards, Marcel _________________________________________________________ EMAIL LEGAL MENTION / DISCLAIMER This message contains information that may be privileged or confidential and is the property of the Expleo Services SAS, RCS Versailles 831 178 348, located, 3 avenue des Pr?s, 78180 Montigny Le Bretonneux - France. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. Ce message contient des informations qui peuvent ?tre privil?gi?es ou confidentielles et elles sont de la propri?t? d'Expleo Services SAS, RCS Versailles 831 178 348, situ?, 3 avenue des Pr?s, 78180 Montigny le Bretonneux-France. Il est destin? uniquement ? la personne ? qui est adress?. Si vous n'?tes pas le destinataire vis?, vous n'?tes pas autoris? ? lire, imprimer, conserver, copier, diffuser, distribuer ou utiliser ce message ou toute partie de celui-ci. Si vous recevez ce message par erreur, veuillez en avertir imm?diatement l'exp?diteur et supprimer toutes les copies de ce message.

5 years, 5 months

2
1
0 0

Integration of a new device

by Marcel Trattner

Dear LAVA-Team, We have only recently started to use LAVA in a new project and we are now at the point of integrating a new device. As I have read in the documentation that this is the hardest part I would like to ask for some advice where to start and what to especially look out for. The current state is that LAVA, as a master and one slave is running in two Docker containers by using the example of the following Github repository: https://github.com/kernelci/lava-docker After reading the documentary extensively and trying things out with qemu I'd like to try and integrate the following device: https://www.lantronix.com/products/sa8155p-automotive-development-platform/ Our plan so far would be: Since it has a Snapdragon processor, it's running Android and it is using fastboot for flashing, we figured we could use one of the dragonboard Device-Type templates and duplicate it for our device. But as it comes now to configuring the device dictionary and specifying the test jobs we are not so sure as how to proceed and we also don't want to damage the hardware, so we would be grateful for some help. Here some more information: The DUT is connected via USB and its power supply can be turned on and off by using Python scripts (When defining the power_on and power_off commands, should the scripts then be on the master or on the dispatcher? And what are all the necessary parameters for the power on/off and also the values connection_list and connection_commands?). It is running Android with the underlying Linux configured especially for the hardware, so we would like to avoid deploying for the beginning and only run some simple shell tests to see if the connection stands. A very simple health check has been set up here<https://paste.debian.net/1175549>, maybe you could give some feedback if that would be sufficient and how future test jobs should be altered. Hope to hear from you soon Best Regards, _________________________________________________________ EMAIL LEGAL MENTION / DISCLAIMER This message contains information that may be privileged or confidential and is the property of the Expleo Services SAS, RCS Versailles 831 178 348, located, 3 avenue des Pr?s, 78180 Montigny Le Bretonneux - France. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. Ce message contient des informations qui peuvent ?tre privil?gi?es ou confidentielles et elles sont de la propri?t? d'Expleo Services SAS, RCS Versailles 831 178 348, situ?, 3 avenue des Pr?s, 78180 Montigny le Bretonneux-France. Il est destin? uniquement ? la personne ? qui est adress?. Si vous n'?tes pas le destinataire vis?, vous n'?tes pas autoris? ? lire, imprimer, conserver, copier, diffuser, distribuer ou utiliser ce message ou toute partie de celui-ci. Si vous recevez ce message par erreur, veuillez en avertir imm?diatement l'exp?diteur et supprimer toutes les copies de ce message.

5 years, 6 months

2
1
0 0

Re: [Lava-devel] Integration of a new device

by koti koti

++ Lava-users list. Regards, Koti On Fri, 4 Dec 2020 at 17:30, <lava-devel-request(a)lists.lavasoftware.org> wrote: > Send Lava-devel mailing list submissions to > lava-devel(a)lists.lavasoftware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.lavasoftware.org/mailman/listinfo/lava-devel > or, via email, send a message with subject or body 'help' to > lava-devel-request(a)lists.lavasoftware.org > > You can reach the person managing the list at > lava-devel-owner(a)lists.lavasoftware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Lava-devel digest..." > > > Today's Topics: > > 1. Integration of a new device (Marcel Trattner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 4 Dec 2020 10:50:08 +0000 > From: Marcel Trattner <marcel.trattner(a)expleogroup.com> > To: "Lava-devel(a)lists.lavasoftware.org" > <Lava-devel(a)lists.lavasoftware.org> > Cc: Alexander Wyron Wachtberger > <alexander-wyron.wachtberger(a)expleogroup.com>, Vladimir Schmidt > <vladimir.schmidt(a)expleogroup.com> > Subject: [Lava-devel] Integration of a new device > Message-ID: > < > AM9PR10MB4295B7516795BD7B514C2DF7E5F10(a)AM9PR10MB4295.EURPRD10.PROD.OUTLOOK.COM > > > > Content-Type: text/plain; charset="us-ascii" > > Dear LAVA-Team, > > We have only recently started to use LAVA in a new project and we are now > at the point of integrating a new device. As I have read in the > documentation that this is the hardest part I would like to ask for some > advice where to start and what to especially look out for. > > The current state is that LAVA, as a master and one slave is running in > two Docker containers by using the example of the following Github > repository: > > https://github.com/kernelci/lava-docker > > After reading the documentary extensively and trying things out with qemu > I'd like to try and integrate the following device: > > https://www.lantronix.com/products/sa8155p-automotive-development-platform/ > > Our plan so far would be: > Since it has a Snapdragon processor, it's running Android and it is using > fastboot for flashing, we figured we could use one of the dragonboard > Device-Type templates and duplicate it for our device. But as it comes now > to configuring the device dictionary and specifying the test jobs we are > not so sure as how to proceed and we also don't want to damage the > hardware, so we would be grateful for some help. > > Here some more information: > The DUT is connected via USB and its power supply can be turned on and off > by using Python scripts (When defining the power_on and power_off commands, > should the scripts then be on the master or on the dispatcher? And what are > all the necessary parameters for the power on/off and also the values > connection_list and connection_commands?). > It is running Android with the underlying Linux configured especially for > the hardware, so we would like to avoid deploying for the beginning and > only run some simple shell tests to see if the connection stands. > A very simple health check has been set up here< > https://paste.debian.net/1175549>, maybe you could give some feedback if > that would be sufficient and how future test jobs should be altered. > > Hope to hear from you soon > > Best Regards, > > > _________________________________________________________ > > EMAIL LEGAL MENTION / DISCLAIMER > > This message contains information that may be privileged or confidential > and is the property of the Expleo Services SAS, RCS Versailles 831 178 348, > located, 3 avenue des Pr?s, 78180 Montigny Le Bretonneux - France. It is > intended only for the person to whom it is addressed. If you are not the > intended recipient, you are not authorized to read, print, retain, copy, > disseminate, distribute, or use this message or any part thereof. If you > receive this message in error, please notify the sender immediately and > delete all copies of this message. > > Ce message contient des informations qui peuvent ?tre privil?gi?es ou > confidentielles et elles sont de la propri?t? d'Expleo Services SAS, RCS > Versailles 831 178 348, situ?, 3 avenue des Pr?s, 78180 Montigny le > Bretonneux-France. Il est destin? uniquement ? la personne ? qui est > adress?. Si vous n'?tes pas le destinataire vis?, vous n'?tes pas autoris? > ? lire, imprimer, conserver, copier, diffuser, distribuer ou utiliser ce > message ou toute partie de celui-ci. Si vous recevez ce message par erreur, > veuillez en avertir imm?diatement l'exp?diteur et supprimer toutes les > copies de ce message. >

5 years, 6 months

1
0
0 0

Re: [Lava-devel] [Lava-users] LAVA tests execution on already provisioned (boot) begalbone board

by Milosz Wasilewski

On Tue, 17 Mar 2020 at 12:30, koti koti <kotisoftwaretest(a)gmail.com> wrote: > > Hi, > > I have successfully booted the Beagelbone board from "https://github.com/danrue/lava.therub.org" . (corresponding ymal is https://github.com/danrue/lava.therub.org/blob/master/server-overlay/etc/la…) > > But, now I am trying to run one more scenario (may be new scenario and not sure is it supported by LAVA lab?) i.e > > 1. Run the tests on already provisioned (boot) beagelbone board. (Basically I am skipping the booting mentioned and trying to run on the already provisioned/boot board) > a) boot the target > b) Connect Board to LAVA lab > c) Just check the login prompt ("#") is available or not? > c) Run the using below test definition file (Basically this test definition file runs "ls"/"ifconfig" commands in the already provisioned(boot) board). > > " > device_type: beaglebone-black > job_name: beaglebone-black healthcheck > timeouts: > job: > minutes: 10 > action: > minutes: 5 > priority: high > visibility: public > actions: > - test: > interactive: > - name: ls test > prompts: ["#"] > echo: discard > script: > - name: ls > command: ls > successes: > - message: "ls simple test successes" > failures: > - message: "TIMEOUT" > exception: InfrastructureError > error: "ls command failed" > - name: ifconfig > command: ifconfig > - name: wait for the prompt > command: > " > > I have tried to run this. But, my test failed with the error ""Connection closed"" (Attached screenshot) Connection closed is usually not sth wrong with LAVA but with serial. Are you able to connect to the board by telneting to your ser2net port? I assume you use ser2net as in Dan's example. If not, could you explain how do you connect to the BBB's UART? milosz > > Can some one let me know solution to fix this error? > > Regards, > koti > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users

6 years, 3 months

2
1
0 0

Design meeting minutes from 2019-12-18

by Remi Duraffort

Hi folks, I forget to send the last design meeting notes that you can find on https://git.lavasoftware.org/lava/lava/wikis/design-meetings We held our regular design meeting today via Hangout. Summary of brief discussion: # Connect presentations? [Rémi] * Docker deploy/boot/test for adb? * [Antonio] will make this presentation * LAVA rest api? * Some slides in the LAVA USers forum * Remote labs setup? * [milosz] will make this presentation * LAVA users forum * [Rémi] will submit the talk # documentation layout [Rémi] * http://people.linaro.org/~remi.duraffort/site/ Comments? * [Antonio] issues with the menu on smaller screens * Some CSS to change? # read the doc [Milosz] Will ping the admins to get back the lava project # port of lava-coordinator to python3 [Antonio] * [Rémi] Already working under python3 * Antonio will update the packaging to provide the binary from src:lava and drop src:lava-coordinator # Docker support coming up soon [Antonio] * With this patch all three methods works * Bare metal * lxc * Docker * So this is safe to merge and test on staging * Won’t be able to test fastboot_via_uboot locally ============================================================================ The LAVA design meeting is held weekly, every Wednesday at 13:00 to 14:00 UTC using Google Hangouts Meet: https://meet.google.com/usu-aatj-fht Feel free to comment here or join us directly in the meeting. Minutes from this and previous meetings are also stored in the LAVA wiki: https://git.lavasoftware.org/lava/lava/wikis/design-meetings/index Cheers, -- Rémi Duraffort LAVA Architect Linaro

6 years, 6 months

1
0
0 0

Design meeting minutes from 2019-09-11

by Remi Duraffort

Hi folks, We held our regular design meeting today via Hangout. Summary of brief discussion: # 11th September 2019 # Reducing the privilege of lava-slave [Antonio] It’s more or less ok that lava-run requires being run as root. But can we run lava-slave as non-root? Lava-slave needs to cleanup after lava-run if something goes wrong, so there might be stuff owned by root left over and this needs to be handled. Otherwise it’s `go for it`. # Replacing LXC with docker [Antonio] How exactly do we want to do that: See https://git.lavasoftware.org/lava/lava/issues/305 and https://git.lavasoftware.org/lava/lava/issues/286 The goal is to: * simplify the job definition (see the job definition in https://git.lavasoftware.org/lava/lava/issues/305) * allow to use user provided docker container to run adb # Job level privileges [milosz] How does that work compared to device and device-type level privileges? See https://git.lavasoftware.org/lava/lava/merge_requests/693 for more documentation The job level permission are still applied, but the device-type and device permissions are also applied (was not the case before). # LAVA package uploads to Debian? [Steve] I don't have time to do it anymore, and we have RC bugs: * some django2 issues too? patches from Antonio * One more patch https://git.lavasoftware.org/lava/lava/merge_requests/696 * Gunicorn problem? Need to update the dependency * VLANd python3 conversion underway * lava-coordinator debian package depends on python2 # New maintainer for vland [milosz] Since Steve is moving to a new project we’ll need a new maintainer for vland. # SAN19 - all stuff up to date and slides done? [Steve] Any meetings to plan? * lavafed # Moving docker base images to buster? [Rémi] When should we use buster as the base image? Will be the base image for 2019.10 # Hangout meetings links changed [Steve] The documentation should be updated. ============================================================================ The LAVA design meeting is held weekly, every Wednesday at 13:00 to 14:00 UTC using Google Hangouts Meet: https://meet.google.com/usu-aatj-fht Feel free to comment here or join us directly in the meeting. Minutes from this and previous meetings are also stored in the LAVA wiki: https://git.lavasoftware.org/lava/lava/wikis/design-meetings/index Cheers, -- Rémi Duraffort LAVA Team, Linaro

6 years, 9 months

1
0
0 0

LAVA 2019.07 dependencies

by Dave Pigott

Hi Remi, When I was doing the lkft upgrade this morning I noticed that there is a Buster dependency for LAVA. One of the workers had somehow been missed out on the Buster upgrade and was still on Stretch. I discovered the following: lava-dispatcher : Depends: python3-requests (>= 2.20.0) but 2.12.4-1 is to be installed Does this mean we really have to check for Debian version 10.0 or later for remote, bare metal, workers? Thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

6 years, 10 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

lava-devel