lava-users

lava-users@lists.lavasoftware.org

4 participants
907 discussions

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

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

4 months, 1 week

Boot with serial test with ssh

by Michael Peddie

Hi all, I have been having issues doing solely boot and test with serial (specific issue(s) not diagnosed, but presumably something to do with telnet), but that's not the discussion here. I want to be try booting the device with the serial method then deploying/running tests using ssh, since it seems like ssh can't power on and power off the DUT. If that is wrong then please let me know so I can try that. I have two proposed ideas: 1) boot with serial -> deploy test (however works) -> run test with serial -> power off 2) boot with serial -> deploy test (however works) -> run test with ssh -> power off I started with a multinode job (I still don't quite understand multinode yet) and this is my current job definition, if you could please help point out issues with it as it doesn't work: #multinode job for controller deployment job_name: controller deploy test protocols: lava-multinode: roles: host: context: lava_test_results_dir: /tmp/lava-%s device_type: controller timeout: minutes: 10 count: 1 guest: context: lava_test_results_dir: /tmp/lava-%s request: lava-start count: 3 expect_role: host timeout: minutes: 10 connection: ssh host_role: host timeouts: job: minutes: 15 action: minutes: 5 connection: minutes: 2 priority: medium visibility: public actions: - deploy: role: - host timeout: minutes: 10 to: tftp authorize: ssh kernel: url: file:///kernel.img type: uimage ramdisk: url: file:///ramdisk.gz compression: gz dtb: url: file:///u-boot.dtb - deploy: role: - guest timeout: minutes: 10 to: ssh protocols: lava-multinode: - action: prepare-scp-overlay request: lava-wait messageID: ipv4 message: ipaddr: $ipaddr - boot: role: - host timeout: minutes: 5 method: minimal prompts: ["# "] auto_login: login_prompt: "login: " username: root - boot: role: - guest timeout: minutes: 5 prompts: ["# $"] parameters: hostID: ipv4 # messageID host_key: ipaddr # message key method: ssh connection: ssh - test: role: - host timeout: minutes: 15 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: install-ssh description: "install step" scope: - functional run: steps: # messageID matches, message_key as the key. - lava-send ipv4 ipaddr=$(lava-echo-ipv4 eth0) - lava-send lava_start - lava-sync clients from: inline name: ssh-inline path: inline/ssh-install.yaml - test: role: - guest timeout: minutes: 5 definitions: - repository: https://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@github.com/MichaelPed/lava… from: git path: smoke-tests/smoke.yaml name: smoke-tests # run the inline last as the host is waiting for this final sync. - repository: metadata: format: Lava-Test Test Definition 1.0 name: client-ssh description: "client complete" scope: - functional run: steps: - df -h - free - lava-sync clients from: inline name: ssh-client path: inline/ssh-client.yaml And this is my device dictionary, if you could please let me know what needs changing: {% extends 'controller.jinja2' %} {% set power_off_command = 'python /power.py 12 off' %} {% set soft_reboot_command = 'reboot'%} {% set hard_reset_command = 'python /power.py 12 reboot' %} {% set power_on_command = 'python /power.py 12 on' %} {% set connection_list = ['uart0'] %} {% set connection_commands = {'uart0': 'telnet 10.60.2.209 7001'} %} {% set connection_tags = {'uart0': ['primary', 'telnet']} %} {% set bootm_kernel_addr = '/kernel.img' %} If you guys have any questions please ask away! Also, if there is somehow something other than a multinode job that will do what I want then please let me know! Best regards, Michael

5 months, 1 week

How to run QEMU in DUT and gdb the QEMU in another console

by 叶轩杨

Hello! I want to run QEMU in DUT and gdb the QEMU in another console to simulate something like a bit flip in memory. What should I do? I just need the new console to run some gdb scripts, like `rust-gdb vmlinux -ex 'target remote /tmp/gdb_socket' -ex 'set *0x40001000 ^= (1<<5)' -ex `c` `, so the new console can not be interactive, live to run some command is enough. Thanks!

5 months, 1 week

Run pytest suite on DUT using LAVA

by Singamsetty Nagendra

Hello everyone, I would like to integrate & run a bare metal custom tests suite(pytest) on lava. Currently I am executing manually from Host Machine(where pytest is configured and pytest suite will execute) and these commands are sent to DUT and results are collected on Host Machine. I am familiar with lava-interactive method but it looks like it will not suit this requirement(Run pytest on Host and collect logs from DUT). Does lava suits for this requirement? if someone could give me advice on this that would be great support. Regards Nagendra S

5 months, 1 week

How to loop test reboot

by irreallich＠126.com

Hi, I hope to be able to test whether the system can boot normally after multiple restarts (10,000 times) Because every boot requires the auto_login of the boot action, it seems that a loop needs to be implemented in yaml, and this loop needs to include the boot action. Are there any relevant examples that you can refer to? There are roughly two types of test logic 1: while (a<10000) { -boot auto_login - test basic io test software reboot in target board a=a+1 } 2: while (a<10000) { -boot auto_login - test basic io test a=a+1 hardware reboot in worker } Thanks

5 months, 2 weeks

transfer_overlay wget wont work on DUT

by Michael Peddie

Hi, I am trying to use transfer_overlay as the fs on my DUT is read-only, but the /data/ and /tmp/ directories are writeable to some extent. I have a working method to use wget, and it works when I use it manually to download the overlay tarball over http, both on my DUT and on the worker device. However, the LAVA test itself always returns the error 'Network Unreachable' What are the possible reasons for this? Best regards, Michael

5 months, 2 weeks

Request to change status of failure retry option:

by pawanKumar

5 months, 2 weeks

Lava Test/Dev Environment Setup Best Practices

by Swapnil Tilaye

Hi Team Currently for the developing and running of the lava tests, we always run on the Lava master machine through lavacli. But we would like to skip the part of the running the tests from the lava master machine while developing, testing and triaging the tests written in the lava. We only want to run tests which are tested correctly to be run on through ci/cd on the lava master and for development, triaging we want to only use the lava-worker and board. We only want to use the lava master only through CI/CD. [cid:86e0132a-a975-4d04-9f31-9a89237339d8] Is there any way to run tests directly from the lava worker instead of going through lava master. I tried "lava-test-shell" and "lava-dispatcher" but it didnt work for me. Can I use the lava api for developing and triaging the test scripts? Can you please recommend the best practice or setup for developing, testing and triaging the tests written in the lava? so that anyone can run, develop or modify tests quickly and make sure its successful and then only it can run through the lava master machine. Regards, Swapnil Tilaye

6 months

Possible regression: LAVA breaks initrds/ramsisks with attached microcode

by Florian Bezdeka

Hi all, over the last days I was trying to bring up a setup where we simply try to boot up a kernel and initrd combination that is provided by Debian "as is". Sounds trivial at first but I ran into a problem with the initrd: The initrd contains some microcode, shipped as prepended uncompressed archive. The microcode is added because the intel-microcode package was installed during image generation. When such an initrd enters the LAVA machinery, where the initrd is first unpacked and later re-packed the file gets corrupted in a way that the kernel is unable to unpack/use it. The end result was that NFS boot did not work as the mounting of the rootfs did not take place. Interestingly there is no error message, not within the unpack/repack step in LAVA and the kernel does not complain later during the boot sequence either. To disable the LAVA unpack/repack sequence I had to modify my deploy action. Setting install_overlay and install_modules [2] to false seems to qualify as workaround: - deploy: timeout: minutes: 15 to: tftp kernel: url: <kernel-url> ramdisk: url: <initrd-url> install_overlay: false install_modules: false Looking at the initramfs-tools implementation [1] I think that something similar is missing in LAVA. Does that make sense? Ideas / comments? Best regards, Florian [1] https://gitlab.com/lava/lava/-/blob/master/lava_dispatcher/actions/deploy/a… [2] https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/unmkinit… -- Siemens AG, Technology Linux Expert Center

6 months, 1 week

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users