Dear Sir/Madam,
could you please help us analyze the problems encountered in recent Lava tests?
Detailed log in the attachment.
lava-dispatcher version: 2018.11+stretch.
The key information is as follows: Bug error: argument of type 'NoneType' is not iterable
Chase Qi preliminary positioning is a lava bug. We look forward to your reply.
Thank you for your assistance.
Best Regards,
Caili Liu
Hi all,
Yesterday, we faced a weird issue with LAVA.
A job was running and returned an error saying "metadata is too long".
Right after that, the worker that was running the job went offline, and the
lava-master
raised an "unknown exception", making it crash.
In attachement, you will find the full job error saying metadata is too
long,
the full job log, and the lava-master.log when the exception occured.
Hope this helps.
Axel
I use next command to start lavadispatcher:
docker run -idt --net=host --privileged -v /dev:/dev -v /var/lib/lava/dispatcher/tmp:/var/lib/lava/dispatcher/tmp -e "DISPATCHER_HOSTNAME=--hostname=myname" -e "LOGGER_URL=tcp://master_ip:5555" -e "MASTER_URL=tcp://master_ip:5556" --name test_lava lavasoftware/lava-dispatcher:2019.01
In container, I start tftp and nfs. But the nfs always cannot be start successfully. I use "service nfs-kernel-server start" to start it, also before that I did "rpcbind".
The start shows below seems ok:
# service nfs-kernel-server start
[ ok ] Exporting directories for NFS kernel daemon....
[ ok ] Starting NFS kernel daemon: nfsd mountd.
But if do next we can see the nfs still not start.
# service nfs-kernel-server status
nfsd not running
Any suggestion?
Hello,
We've been using uboot-ums for WaRP7 but we've been having intermittent failures when it tried to run dd to flash the image.
Provided we need to look better into the root cause of this issue, we'd like to make the flashing phase a little more reliable.
I have few questions, coming from different angles:
* LAVA uses dd command to flash the image. Is there a way to specify the usage of bmap-tools?
* let's say dd times out (this is what usually happen). Is there a mechanism to restart the actions (deploy and boot) in case of timeout?
If you have any other suggestion, let me know!
Cheers
--
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/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.
Hi,
I have a test step that requires user input to a defined prompt.
Is there a way I can automate this in LAVA ?
I can see how we do this for Boot Actions and I've looked at interactive jobs that communicate to U-boot but these don't seem to fit my use case.
Thanks.
Pete
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.
Hi All,
I am new to Android testing, I am using standard board *i.mx6/rpi3* and
flashed Android on it, I can connect with these board using "adb" tool.
I want to do some system test using LAVA framework, and I don't want to
reflash image every time(wants to test on the existing system). Can someone
please let me know how I can do Android testing on existing flashed image?
Thanks,
Ankit
Dear Lava users,
Our embedded SW offers 3 boot modes, selectable from u-boot.
When booting, u-boot offers the possibility to select the boot mode:
Select the boot mode
1: <boot mode 1>
2: <boot mode 2>
3: <boot mode 3>
Enter choice: 1: <boot mode 1>
<boot mode 1> is a default value, used after a counter has expired.
All this is done using the extlinux feature.
We have scripts that allow to select the boot mode, using Kermit. Now, we'd like to integrate this boot mode selection in a Lava job, and our current solution is not compatible.
In Lava we may boot the kernel, modify the extlinux configuration and reboot, but do you know a direct way (with interactive mode maybe) to select the boot mode from u-boot?
Best regards,
Denis
Hello everyone,
I am having problems with timeouts when using the LAVA multinode protocol. Assume the following minimal pipeline with two nodes (device = DUT, remote = some kind of external hardware interfacing with the DUT):
- deploy:
role: device
- boot:
role: device
- deploy:
role: remote
- boot:
role: remote
- test:
role: remote
- test:
role: device
What I would expect: The device is booted first, then the remote is booted. Afterwards, the tests run on both nodes, being able to interact with each other.
The pipeline model seems to be implemented in a way that each node has its own pipeline. This kind of makes sense, because the tests of course have to run simultaneously.
However, in my case booting the device takes a lot more time than booting the remote. This makes the 'test' stage on the remote run a lot earlier than the 'test' stage on the device.
My problem: How do I define a useful timeout value for the 'test' stage on the remote? Obviously I have to take the boot time difference between the two nodes into account. This seems counter-intuitive to me, since the timeout value should affect the actual test only. What happens if I use an image on the device which takes even a lot more time to boot? Or if I insert more testcases on the device which do not need the remote before? In both cases I would have to adjust the timeout value for the remote 'test' stage.
Is this a design compromise? Or are there any possibilities of synchronizing pipeline stages on different nodes? I am thinking of some mechanism like "do not start 'test' stage on remote before 'boot' stage on device has finished".
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hi,
Is there a way to specify an arbitrary parameter, that is board
specific, in device dictionary? The parameter should be available from
test shell. The use case is as follows: DUT is connected to test
supporting hardware (chamelium board in this case). Tests access
supporting hardware using IP address. IP address is 'static' and the
supporting hw is assumed to be always turned on. Supporting hardware
is dedicated to specific DUT and can't be shared (because of HW
connections) between other boards of the same type (similar to energy
probes). Tests run directly on DUT and access supporting hardware from
there.
I found 'exported parameters' in device dictionary docs:
https://master.lavasoftware.org/static/docs/v2/lava-scheduler-device-dictio….
But they only list device_ip, device_mac and storage_info. Is there a
way to extend this list? If not, is there any other way to provide
device specific information to test shells?
milosz
Hi everyone,
I'm writing this email after discussion with Neil.
I'm working at NXP and he told me Linaro wanted to run functional tests on
imx8m
with the new u-boot support.
He told me it requires full open access, no license click-through or
passwords.
Philippe Mazet is more qualified to answer this type of question as I only
use Android atm. He will follow up the discussion.
Here you have the Yocto source code :
https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-l…
You can get the latest GA release with this :
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b
imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml
You can build these sources like this :
DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source ./fsl-setup-release.sh -b
build
But, this will redirect you to a license click-through.
However, you can bypass the license click-through, like "auto accept it"
with this command :
EULA=1 DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source
./fsl-setup-release.sh -b build
We use this bypass to automate builds.
So, let us know if this would be suitable for Linaro's needs.
Best regards,
Axel
