lava-users March 2024

lava-users@lists.lavasoftware.org

6 participants
4 discussions

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, 1 week

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

"Proxy Error" message while loading more size log from LAVA jobs

by koti

Hi, We are seeing below the "Proxy Error" message while loading log size logs from the LAVA job . Is there any solution to load a long size log file from a LAVA job ? [image: image.png]

6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users March 2024