lava-users

lava-users@lists.lavasoftware.org

4 participants
935 discussions

Execute script while running ssh device type

by sweta.ghosh＠nagarro.com

Hello, I have multiple machines over which I test using LAVA job using primary ssh connection. As my devices OS gets installed every now and then I have to manually update the ssh public key before executing the job so that LAVA can connect to DUT over passwordless SSH. Is there a way I can include a script in device dictionary to copy the keys automatically before requesting a ssh connection? As I understand password option is not there. Kindly suggest.

1 year, 1 month

How to execute preboot command in qemu

by sweta.ghosh＠nagarro.com

Hello, I want to spin up an image with tpm enabled using qemu, and I need to execute swtpm socket command before image boot-ups via qemu. Please suggest if I could execute this command or script in qemu.jinja2 file or any other file. Thanks, Sweta

1 year, 1 month

Not able to set variable

by sweta.ghosh＠nagarro.com

Hi, I want clone a gitlab repo with id and token during job execution. To hide the token I am passing the value in my job. How can I export the value of GIT_TOKEN in environment file of LAVA? So that whenever job is executed it will read the value from its environment file. I tried to use export and tried to add "GIT_TOKEN=abcd" in env.yaml file. But I guess its not correct format. I couldn't find what kind of values we can add in env.yaml in documents. I also added GIT_TOKEN value in /etc/profile of the LAVA server still the job didn't pick it. Could you please suggest how can we clone the repo in LAVA job without exposing its password. Also I understand that ssh key of root will work but I want to avoid using ssh key of root. Kindly suggest - test: timeout: minutes: 15 definitions: - repository: https://gitid:$GIT_TOKEN@gitlab.com/lava-tests.git from: git path: tests/cisscan/cis.yaml branch: pipeline name: cis-benchmark

1 year, 1 month

Confusion about job IDs reported by lavacli for multi node tests

by Florian Bezdeka

Hi all, I run into some unexpected behavior when it comes to LAVA job IDs reported by the "lavacli jobs sumit" command for multi node tests. What I get is a list of newline separated job IDs like: lavacli jobs submit <my-job-description> 132.0 132.1 To my understanding this tries to express that 132.1 is a sub job of 132. OK, but this is a problem if I now try to download the junit report for the second job (=132.1). It seems 132.1 is not a valid job ID (API wise), it has to be translated to 133 to work properly. This is still doable, but I'm unsure if I can relay on 133 really being the 132.1 job in case there are several job submissions at the same time. Is that a bug of lavacli? What is the reasoning for returning a sub job ID which seems to be invisible to the rest of the LAVA infrastructure / API? I'm currently running lavacli 1.2-1, as shipped by Debian 12. Any input welcome... Best regards, Florian

1 year, 1 month

bootup a server and deploy debian bookworm over serial connection

by sweta.ghosh＠nagarro.com

Hello, I am new to LAVA, I want to boot up my hardware(NET-I System)which is a x86_64 and install debian bookworm image over it and execute test cases. My h/w is connected to my LAVA server via a serial device.Below is the high level job that I am planning to use. But where should I specify the serial device information and other information?Could please share any example job and device .jija2 that I can refer regarding what all information needs to be provided for LAVA server to properly connect to H/W and also is u-boot correct for my usecase? or if there is any other suggestions : device_type: your_device_type job_name: debian_boot_test timeouts: job: minutes: 15 action: minutes: 5 connection: minutes: 2 actions: - deploy: timeout: minutes: 10 to: tftp images: rootfs: url: <Debian Image> - boot: method: u-boot commands: your_device_boot_commands prompts: - 'login:' parameters: boot_options: root=/dev/ram0 - test: timeout: minutes: 5 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: debian-check-test description: "Test to verify Debian OS" os: - debian run: steps: - echo 'Checking if OS is Debian' - 'if [ "$(lsb_release -is)" = "Debian" ]; then echo "OS is Debian"; else echo "OS is not Debian"; fi' from: inline name: debian-check-test path: inline/debian-check-test.yaml

1 year, 2 months

Change path of lava_test_results_dir and lava_test_dir

by sweta.ghosh＠nagarro.com

Hello, I would like to change path to /mnt from below: "lava_test_dir": "/lava-%s", "lava_test_results_dir": "/lava-%s", I am using an immutable image and due to which don't have permission to write, so cannot create directory eg /lava-34 due to which cannot execute test. We have partition /mnt which we can mount and run the test cases over our os. But for that to work I need to change path. I tried changing it in /usr/lib/python3/dist-packages/lava_dispatcher/deployment_data.py , but jobs fails once I change it. I have only changed the debian section as the image we are using is a debian image. Could you please help me if there is any option to make these changes while executing job or any other file for devices. Thanks, Sweta

1 year, 3 months

RecursionError: maximum recursion depth exceeded on lava-scheduler service

by sweta.ghosh＠nagarro.com

Hi , I am trying to setup LAVA on Single Master Worker node. When i am trying to submit job it is running but no device is getting selected nor I am getting any output on UI. When I checked the lava-scheduler it is failing with below error: root@debian:/etc/apache2/sites-available# systemctl status lava-scheduler × lava-scheduler.service - LAVA scheduler Loaded: loaded (/lib/systemd/system/lava-scheduler.service; enabled; preset: enabled) Active: failed (Result: start-limit-hit) since Tue 2024-07-02 18:52:36 IST; 7min ago Duration: 1.472s Process: 10345 ExecStart=/usr/bin/lava-server manage lava-scheduler --level $LOGLEVEL --log-file $LOGFILE $EVENT_URL $IPV6 (code=exited, status=0/SUCCES> Main PID: 10345 (code=exited, status=0/SUCCESS) CPU: 1.431s Jul 02 18:52:35 debian systemd[1]: lava-scheduler.service: Deactivated successfully. Jul 02 18:52:35 debian systemd[1]: lava-scheduler.service: Consumed 1.431s CPU time. Jul 02 18:52:36 debian systemd[1]: lava-scheduler.service: Scheduled restart job, restart counter is at 5. Jul 02 18:52:36 debian systemd[1]: Stopped lava-scheduler.service - LAVA scheduler. Jul 02 18:52:36 debian systemd[1]: lava-scheduler.service: Consumed 1.431s CPU time. Jul 02 18:52:36 debian systemd[1]: lava-scheduler.service: Start request repeated too quickly. Jul 02 18:52:36 debian systemd[1]: lava-scheduler.service: Failed with result 'start-limit-hit'. Jul 02 18:52:36 debian systemd[1]: Failed to start lava-scheduler.service - LAVA scheduler. root@debian:/etc/apache2/sites-available# tail -f /var/log/lava-server/lava-scheduler.log {% extends 'qemu.jinja2' %} ^^^^^^^^^^^^^^^^^^^^^^^^^ [Previous line repeated 977 more times] File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1494, in is_up_to_date return self._uptodate() ^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/jinja2/loaders.py", line 212, in uptodate return os.path.getmtime(filename) == mtime ^^^^^^^^^^^^^^^^^^^^^^^^^^ RecursionError: maximum recursion depth exceeded Also when I am accessing /admin/lava_scheduler_app/device/ I am getting " 500 Internal Server Error maximum recursion depth exceeded" I have registered my worker node as debian,hostname as debian and device type is qemu. Could you please what I am missing.

1 year, 3 months

lava test doesn't wait for command to finish running

by Michael Peddie

Just as the subject says. I am using lava-test-case to confirm whether this particular command is done running and is successful or not, because the test has previously always ended prematurely and not done what I needed it to do. When I run the command manually outside of a lava test job it works just fine, no errors and doesn't end early. It does take a while to complete, but I don't think that's the issue as I use wget to download some large files and those have taken several minutes longer than this one command is supposed to. How do I get lava to wait for this command to end? Or to change how it checks for command failure? I get "Received signal: <ENDTC>" almost immediately after running the command, and subsequently the result=fail signal. I really don't know why it won't work, so if there is a change I can make to the files or a config somewhere I would like to know. Best regards, Michael

1 year, 3 months

MultiNode to run script->reboot->test

by Michael Peddie

Hi, I was wondering if it is possible to write a multinode test to boot a device, run a script to do some stuff then have it reboot one way or another, then run tests. There is intention for pipeline integration down the line, so if it isn't possible to do that with multinode I have considered the idea of setting it up so one regular test runs and runs the script, turns DUT off, then another test runs to boot and actually test the device. This (obviously) has its drawbacks, but it's something of a backup. If I understand correctly, where certain actions are placed in a multinode test actually matters, so it (in my mind) is possible to have a boot->test to boot a DUT then use test commands to run a script, and then after that another boot->test to boot the device or just login again and then actually run tests. So the final sort of action set up would be boot->test->boot->test, where the first two are for running the script and rebooting, and the latter two are actually testing. If there are other ideas that are better or equally viable, then Im open to those too, but multinode was the first that came to mind cos of secondary connections and the like. Best regards, Michael

1 year, 4 months

lavasoftware.org is unaccessible from gandi.net Paris SD6 datacenter

by Jacopo Mondi

Hello I am experiencing troubles connecting to apt.lavasoftware.org from a VPS located in the "Paris France SD6" datacenter hosted by gandi.net, The problematic VPS IP address is 46.226.105.174. Testing from another VPS, still hosted at gandi.net but located in a different datacenter (Luxembourg) presents no issues. Both VPS runs Debian 12 Bookworm. The symptoms I'm experiencing seems to suggest the TLS handshake gets truncated as suggested by the 'gnutls-cli' output below reported ------------------------------------------------------------------------------- # gnutls-cli -d9999 -p 443 apt.lavasoftware.org ... |<5>| REC[0x56498f5d7740]: Sent Packet[1] Handshake(22) in epoch 0 and length: 402 |<11>| HWRITE: wrote 1 bytes, 0 bytes left. |<11>| WRITE FLUSH: 402 bytes in buffer. |<11>| WRITE: wrote 402 bytes, 0 bytes left. |<3>| ASSERT: ../../lib/buffers.c[get_last_packet]:1185 |<10>| READ: Got 0 bytes from 0x3 |<10>| READ: read 0 bytes from 0x3 |<3>| ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:593 |<3>| ASSERT: ../../lib/record.c[recv_headers]:1195 |<3>| ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1321 |<3>| ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1467 |<3>| ASSERT: ../../lib/handshake.c[_gnutls_recv_handshake]:1600 |<3>| ASSERT: ../../lib/handshake.c[handshake_client]:3075 |<13>| BUF[HSK]: Emptied buffer *** Fatal error: The TLS connection was non-properly terminated. ------------------------------------------------------------------------------- Could you kindly check if my VPS is maybe in a range of IP addresses blacklisted by the service provider that hosts lavasoftware.org ? Thanks j

1 year, 5 months

← Newer
1
2
3
4
5
6
7
...
94
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users