lava-users November 2019

lava-users@lists.lavasoftware.org

16 participants
30 discussions

by dhanu msys

Hi Team, Now I have experienced by running some of test jobs on LAVA Setup , really lava-mailing-lists helps a lot to solve problems & providing suggestions at earliest. Now We are planning to have LAVA Lab Setup with minimum 30 to 40 devices connected to the PDU to run automation test jobs. So , at initial we wants to know the LAVA Server Specifications more in detail , like RAM etc.. to setup the LAVA Lab. Regards, Dhanunjaya. P

5 years, 1 month

LAVA Web Interface access in intranet

by dhanu msys

Hi Team, I am able to access the web interface(WEB GUI) through localhost. Is there any specific configuration required to access the web ui within the intranet. Here I have shared the server.conf & instance.conf ( /etc/lava-server/ )files, please let me know the configuration changes if required? Dhanunjaya. P

5 years, 1 month

Re: [Lava-users] [Automated-testing] ELC followup / Search for a testing framework for small distribution tests on device

by Milosz Wasilewski

On Tue, 12 Nov 2019 at 16:49, Westermann, Oliver <Oliver.Westermann(a)cognex.com> wrote: > > Hey everyone, > > I recently joined the ELC in Lyon and had a good chat with a few who may read this list. Only during the ELC I leaned about the automated testing summit and if I had not planned the next days already, I would probably have joined. During the interesting talks and some networking I also learned about this list, so I now have to ask a bunch of questions in the hope for answers ;-) > > We (as in the company I work for) moved to linux for our embedded devices quite some time ago, but our testing hasn't. We have a test system for our full product, but due to the nature of the product ("cameras with intelligence"), there is a lot of implied requirements on the state of the device, which makes testing expensive (in terms of device- and setuptime), which results in only one, but very thorough test loop a day. > > We're now trying to check our options to setup a smaller on-device test-stage before this setup. We would like to test features we would consider "distribution features": Network connectivity, IO features, updates and more. Most devs have their small scripts to do one thing or another, but we would prefer to distribute something that allows us to share all this and run it as part of the CI chain. > > So I've looked into some of the pages on the Automated_Testing page of the elinux wiki and dove into a few of the frameworks, but actually I'm even more confused by LAVA, fuego and all the other tools than before. We already have a build system, we already have a CI system controlling build system. So I'm writing to you in an attempt to get a feeling for whats there and where we can contribute, and I will try to list some of our goal and ideas so maybe someone can throw me some good links (and hopefully, we can > > What we would like: > We would like to run simple tests (execute eg python & bash script) and validate the outputs > We would like to bring devices into a certain state, eg by an upgrade (we use sth with swupdate beneath) As LAVA co-maintainer I'm obviously biased but I think this tool can do what you need. LAVA doesn't do any building it expects build artifacts to be available for download. It can deliver software to your device (aka deployment step) and drive your device to run some tests. If you could give some more details about the device (how to deploy software to it, how to connect to console, etc.) I can probably suggest next step with LAVA. milosz > > Since I assume a lot of you have a better overview about whats out there, what sounds like our needs and where you think we could contribute, let me know :-) > > Best regards and thanks to all of those who gave talks at OSS and ELC, it was a very cool (and overwhelming) time :-) > > - Olli > > > -- > _______________________________________________ > automated-testing mailing list > automated-testing(a)yoctoproject.org > https://lists.yoctoproject.org/listinfo/automated-testing

5 years, 1 month

Re: [Lava-users] dispatcher_config not parsed

by Remi Duraffort

Hello, I said "lava-master" and not "lava-server". Le mar. 19 nov. 2019 à 11:56, Klaas Schulze-Dieckhoff < K.Schulze-Dieckhoff(a)sonnen.de> a écrit : > Hello Remi, > > > > yes it is visible, the first command-line output I showed in the original > message was from inside the lava-server container. I also played around > with the ownership of the file since it is a problem for devices/* and > health-check/* files (they must be lavaserver:lavaserver). But this didn’t > help… > > > > Thanks > > Klaas > > > > *Von:* Remi Duraffort <remi.duraffort(a)linaro.org> > *Gesendet:* Dienstag, 19. November 2019 11:09 > *An:* Klaas Schulze-Dieckhoff <K.Schulze-Dieckhoff(a)sonnen.de> > *Cc:* lava-users(a)lists.lavasoftware.org > *Betreff:* Re: [Lava-users] dispatcher_config not parsed > > > > Hello, > > > > is the configuration file > (/etc/lava-server/dispatcher.d/<hostname>/dispatcher.yaml) visible from the > master container? > > > > In the docker-compose setup, each service is running in a specific > container so the configuration files should be set carefully. > > > > > > Rgds > > > > Le mar. 19 nov. 2019 à 09:25, Klaas Schulze-Dieckhoff < > K.Schulze-Dieckhoff(a)sonnen.de> a écrit : > > Hi all, > > > > I am running lava using docker-compose. Additional to the official > docker-compose.yaml I added and FTP and NFS container. For testing my setup > I am trying to test a beaglebone black. > > In order to load dtb and kernel uboot needs to know the IP of the FTP / > NFS server. I added the IP in the following two ways: > > > > server: > > root@1a010c2f736b:/# cat > /etc/lava-server/dispatcher.d/lava-dispatcher.yaml > > dispatcher_ip: <server ip addr> > > > > dispatcher: > > root@075e2deb4c34:/# cat /etc/lava-dispatcher/lava-slave > > [....] > > NFS_SERVER_IP="<server-ip-addr> " > > > > The hostname of the dispatcher is `lava-dispatcher`. But, when the > health-check is running it will always run `setenv serverip > <ip-of-docker-container>. > > I also tried various variants of setting the dispatcher configuration > (./dispatcher.d/<hostname>/dispatcher.yaml, > ./dispatcher.d/<hostname>/env.yaml). No matter what I do lava persists to > take the IP of the docker-container. > > > > According to ` server/management/commands/lava-master.py` line 465 at > least one of the variants should word, > > > > I would appreciate some hints how to fix this! > > > > Thanks > Klaas > > > > Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen > Schneider, Hermann Schweizer, Tim Ulbricht. > Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer > 127/137/50792, USt.-IdNr. DE272208908 > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > > -- > > Rémi Duraffort > > LAVA Architect > > Linaro > > Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen > Schneider, Hermann Schweizer, Tim Ulbricht. > Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer > 127/137/50792, USt.-IdNr. DE272208908 > -- Rémi Duraffort LAVA Architect Linaro

5 years, 1 month

dispatcher_config not parsed

by Klaas Schulze-Dieckhoff

Hi all, I am running lava using docker-compose. Additional to the official docker-compose.yaml I added and FTP and NFS container. For testing my setup I am trying to test a beaglebone black. In order to load dtb and kernel uboot needs to know the IP of the FTP / NFS server. I added the IP in the following two ways: server: root@1a010c2f736b:/# cat /etc/lava-server/dispatcher.d/lava-dispatcher.yaml dispatcher_ip: <server ip addr> dispatcher: root@075e2deb4c34:/# cat /etc/lava-dispatcher/lava-slave [....] NFS_SERVER_IP="<server-ip-addr> " The hostname of the dispatcher is `lava-dispatcher`. But, when the health-check is running it will always run `setenv serverip <ip-of-docker-container>. I also tried various variants of setting the dispatcher configuration (./dispatcher.d/<hostname>/dispatcher.yaml, ./dispatcher.d/<hostname>/env.yaml). No matter what I do lava persists to take the IP of the docker-container. According to ` server/management/commands/lava-master.py` line 465 at least one of the variants should word, I would appreciate some hints how to fix this! Thanks Klaas Gesch?ftsf?hrer: Christoph Ostermann (CEO), Oliver Koch, Steffen Schneider, Hermann Schweizer, Tim Ulbricht. Amtsgericht Kempten/Allg?u, Registernummer: 10655, Steuernummer 127/137/50792, USt.-IdNr. DE272208908

5 years, 1 month

docker-compose: libguestfs failing

by Klaas Schulze-Dieckhoff

Hi all, I am trying to run a lava-lab with the official docker-compose.yml. When running a health-check on a qemu-device it fails because libguestfs can't find a kernel inside /boot. (There is already a discussion running on the libguestfs-mailing list). But I think the underlying problem is, that there is really no kernel inside /boot of my lava-dispatcher container: #:~/linaro_lava/docker-compose$ docker-compose exec lava-dispatcher bash root@8b5507bd355a:/# ls -al /boot total 4124 drwxr-xr-x 6 root root 129 Oct 1 10:35 . drwxr-xr-x 57 root root 4096 Nov 5 06:04 .. drwxr-xr-x 2 root root 3 Oct 1 10:34 androidboot drwxr-xr-x 2 root root 3 Apr 25 2018 efi drwxr-xr-x 2 root root 3 Oct 1 10:34 grub lrwxrwxrwx 1 root root 28 Oct 1 10:34 initrd.img-core -> initrd.img-core-0.7.43+ppa27 -rw-r--r-- 1 root root 4218483 Oct 1 10:34 initrd.img-core-0.7.43+ppa27 drwxr-xr-x 2 root root 3 Oct 1 10:34 uboot Since /boot is mounted into the docker-container inside docker-compose.yml I would expect it to have the same content the on my host, which is not the case: #:~/linaro_lava/docker-compose$ ls -al /boot total 68300 drwxr-xr-x 4 root root 4096 Oct 30 08:17 . drwxr-xr-x 24 root root 4096 Oct 30 08:14 .. -rw------- 1 root root 4064684 Oct 1 03:02 System.map-4.15.0-66-generic -rw-r--r-- 1 root root 217362 Oct 1 03:02 config-4.15.0-66-generic drwxr-xr-x 3 root root 4096 Jan 1 1970 efi drwxr-xr-x 5 root root 4096 Nov 4 15:26 grub -rw-r--r-- 1 root root 57266820 Oct 30 08:17 initrd.img-4.15.0-66-generic -rw------- 1 root root 8363672 Oct 1 03:05 vmlinuz-4.15.0-66-generic Why can these both directories be different? I would really appreciate if somebody can help me out here! Thanks Klaas Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen Schneider, Hermann Schweizer, Tim Ulbricht. Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer 127/137/50792, USt.-IdNr. DE272208908

5 years, 1 month

RPi3 and uboot 2019.10

by Diego Russo

Hello, We are using RPi3 B/B+ in our infrastructure and the latest uboot changed his behaviour in case of error. In our case we have a kernel and DTB but we don’t have the ramdisk. Despite this, LAVA tries the tftp command for the RAMDISK but the 2 versions have different errors. With uboot 2019.07 this is what happens: tftp - {RAMDISK} U-Boot> tftp - {RAMDISK} bootloader-commands: Wait for prompt ['U-Boot>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'Retry time exceeded; starting again', 'ERROR: The remote end did not respond in time.', 'Bad Linux ARM64 Image magic!', 'Wrong Ramdisk Image Format', 'Ramdisk image is corrupt or invalid', 'ERROR: Failed to allocate', 'TFTP error: trying to overwrite reserved memory'] (timeout 00:04:08) tftp - {RAMDISK} lan78xx_eth Waiting for PHY auto negotiation to complete...... done Using lan78xx_eth device TFTP from server 192.168.130.111; our IP address is 192.168.130.138 Filename '{RAMDISK}'. Load address: 0x0 Loading: * TFTP error: 'File not found' (1) Not retrying... Uboot 2019.10 has a different behaviour and throws a different error: tftp - {RAMDISK} U-Boot> tftp - {RAMDISK} bootloader-commands: Wait for prompt ['U-Boot>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'Retry time exceeded; starting again', 'ERROR: The remote end did not respond in time.', 'Bad Linux ARM64 Image magic!', 'Wrong Ramdisk Image Format', 'Ramdisk image is corrupt or invalid', 'ERROR: Failed to allocate', 'TFTP error: trying to overwrite reserved memory'] (timeout 00:04:12) tftp - {RAMDISK} lan78xx_eth Waiting for PHY auto negotiation to complete...... done Using lan78xx_eth device TFTP from server 192.168.130.111; our IP address is 192.168.130.138 Filename '{RAMDISK}'. TFTP error: trying to overwrite reserved memory... matched a bootloader error message: 'TFTP error: trying to overwrite reserved memory' (11) At this point LAVA fails the job because it matches the error message. What's the best way to solve the issue. How can I tell LAVA not to deal with the RAMDISK at all? Thanks -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/docs/mbed-linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 1 month

Flasher action and pre power command

by Ilya Fedusiv

Hello! I'm trying to flash via special tool, which is not implemented in lava. I did it successfully by editing device dictionary. Next want to use pre power command. That's why I use lxc. But how trigger protocol to use it? It doesnt work: - deploy: namespace: target timeout: minutes: 20 to: flasher images: flash_dir: url: file:///opt/image.zip os: oe protocols: lava-lxc: - action: flasher-deploy request: pre-power-command Ilya

5 years, 1 month

Re: [Lava-users] None of the deployment strategies accepted your deployment parameters

by dhanu msys

Hi Milosz, Thanks for the reply. I will try to get the eth008 if possible , otherwise i will try to make use of TFTP or u-boot methods to run the test job on STM32mp157c-dk2. Thanks & Regards, Dhanunjaya. P On Mon, Nov 11, 2019 at 4:57 PM Milosz Wasilewski < milosz.wasilewski(a)linaro.org> wrote: > On Mon, 11 Nov 2019 at 11:07, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > > > > Hi Milosz, > > > > Really Thanks for sharing the Information. > > > > I have basic question, we can't able to run any test job for the STM32 > without external hardware(PDU) ? > > > > Can you please share the device configuration , which helps to run the > test jobs without "ethernet controlled relay" for the STM32. > > > https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts/eth008_con… > > > > > As I requested earlier , is there any possibility to run the STM32 > specific jobs with any other deployment methods(tmpfs , tftp..etc). > > Our boards use EFI for booting and I never tried tftp with that. You > might need grub EFI application for that. Alternatively you might use > u-boot. I didn't try that either. > > milosz > > > > > Thanks & Regards, > > Dhanunjaya. P > > > > > > On Mon, Nov 11, 2019 at 4:19 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >> > >> Well, LAVA will try to switch the device into DFU mode for deployment > >> step. These lines in the device dict do it: > >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 1 -s on', > >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 2 -s on', > >> Then it will power on the board: > >> '/usr/local/lab-scripts/snmp_pdu_control --hostname lngpdu01 --command > >> on --port 3 --delay 20', > >> After that it will try to flash it using the STM32_Programmer_CLI: > >> '/usr/local/bin/STM32_Programmer_CLI -c port=usb1 -w {LAYOUT} -q', > >> Lastly it will power the board down and flip the dip switches back: > >> '/usr/local/lab-scripts/snmp_pdu_control --hostname lngpdu01 --command > >> off --port 3', > >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 1 -s off', > >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 2 -s off', > >> > >> So if you don't have HW moded board, this device dict won't work for > >> you. Sources for the scripts are here: > >> https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts > >> We're using pretty expensive HW in the LAB: > >> - managed APC PDUs: > >> > https://www.apc.com/shop/uk/en/products/Rack-PDU-Switched-1U-16A-208-230V-8… > >> (I couldn't find the exact models we have, they're discontinued) > >> - ETH008 relay board: > https://www.robot-electronics.co.uk/htm/eth008tech.htm > >> > >> milosz > >> > >> On Mon, 11 Nov 2019 at 10:42, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> > > >> > Hi Milosz, > >> > > >> > No. > >> > Through Manual Setup , we are able to switch between the modes. > >> > > >> > Here I have attached the kernel & dtb image for your reference. PFA. > >> > > >> > Dhanunjaya. P > >> > > >> > > >> > On Mon, Nov 11, 2019 at 3:40 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >> >> > >> >> I think I forgot to ask key question when it comes to this device: > did > >> >> you do the HW mod to be able to switch between DFU and OS boot modes > >> >> without manual step? > >> >> > >> >> milosz > >> >> > >> >> On Mon, 11 Nov 2019 at 10:01, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> >> > > >> >> > Hi Milosz, > >> >> > > >> >> > Thanks for reply. > >> >> > > >> >> > I am new to the LAVA usage. > >> >> > > >> >> > I have taken reference from the below link. > >> >> > > https://staging.validation.linaro.org/scheduler/device/staging-stm32mp157-0… > >> >> > > >> >> > Here I have attached the device_dictionary & device configurations > files, PFA. > >> >> > > >> >> > Note : I am not able to see the "lab-scripts" to have power > controlled commands in my local repository , is there any specific package > need to install in my localhost , can you please share the lab-scripts to > have pdu control and also please share the pdu device details if required > to connect with the hardware. > >> >> > > >> >> > Can you please share some references , which i can run some jobs > through any other deploy methods like "tmpfs , tftp " for "STM32MP157C-DK2". > >> >> > > >> >> > Thanks & Regards, > >> >> > Dhanunjaya. P > >> >> > > >> >> > > >> >> > On Mon, Nov 11, 2019 at 2:59 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >> >> >> > >> >> >> Could you share your device dictionary? You might be missing > >> >> >> flasher_deploy_commands. > >> >> >> > >> >> >> Please check here for reference: > >> >> >> > https://ledge.validation.linaro.org/scheduler/device/lng-stm32mp157-01/devi… > >> >> >> > >> >> >> milosz > >> >> >> > >> >> >> On Thu, 7 Nov 2019 at 07:48, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >> >> >> > > >> >> >> > Hi Team, > >> >> >> > > >> >> >> > I am trying to run the test_jobs on the specific device type > "stm32mp1157c-dk2" , but its throwing an error message to deploy "flasher" > method in the deployment parameters. > >> >> >> > > >> >> >> > Here I have attached the screenshots for reference. PFA. > >> >> >> > > >> >> >> > Thanks & Regards, > >> >> >> > Dhanunjaya. P > >> >> >> > _______________________________________________ > >> >> >> > Lava-users mailing list > >> >> >> > Lava-users(a)lists.lavasoftware.org > >> >> >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users >

5 years, 1 month

Fork option is disabled

by Suram Suram

Hi, I want to submit a change to device-type file and when I tried from the webGUI after logging in, the fork option is disabled. After clicking on the forks count number, the fork option appears to be enabled on that page. Clicked it to select namespace, when hovered the mouse over the namespace, it shows the following error "You have reached your project limit" Can some one help me on this please? Regards Suram

5 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users November 2019