Hello everyone,
My targets are available via ssh interface and I don't need to update them
(install kernel, rootfs, etc) before testing.
My test case is: copy test binary at target device, run the test and check
the result.
As a first step I want to check the ssh connection: log into the device and
check the promts.
My LAVA 2018.2 instance failed to check the connection with "KeyError:
'deployment_data'" traceback: https://pastebin.com/2rsgBvx3
Job definition: https://pastebin.com/GJymcx3z
device dictionary: https://pastebin.com/x08HgSqQ
Is it the LAVA bug or lack of my job definition and device dictionary?
Best Regards, Ivan Arishchenko
I am currently evaluating if LAVA is the right tool for testing our custom flavour of a Raspbian Linux distro. The DUT is going to be a Raspberry Pi3 and I was trying to set it up in a minimal way using another Raspbi3 as a Server & Dispatcher (although first it seemed to work fine, when I followed the LAVA documentation and added the stretch backports sources in the apt list, my whole system crashed because of the depedencies).
What is the best way to get a minimal setup running? I am also interested to know the hardware process (ideally everything we want to be automated). So, should the DUT be connected via a USB2serial cable?
https://goo.gl/D5ZwxU
Other than that should that be connected to an SD multiplexer that burns the resulting .img after Jenkins finishes checking and generating it?
Documentation is a bit tricky to go through as it covers many cases and there's not a simpler minimal tutorial. Also all the online blogs/posts seem to work for LAVA V1 only as a few things have changed.
So it will look something like this:
Linux .img (to be tested) -> SD Multiplexer(?) - DUT - USB2Serial -> LAVA Server & Dispatcher
|
LCD Screen
Are there anywhere some sample tests so I can get an idea of what I will be able to do? (Had already a look at the linaro .git but those seem 'too' basic; probably I've missed smth).
Thank you all for your help.
Thanks again, Neil.
>Future proofing means keeping up with upstream and, hopefully, contributing
>the support back to upstream. A new Strategy class is a requirement for
>inclusion upstream, to be able to isolate this bootloader from future
>changes to better support U-Boot in ways that your bootloader cannot manage.
I get your point and agree with you on that. So does this mean you would accept contributions for a new bootloader, even if it is a proprietary one?
However, for a quick check how LAVA works I was able to go the hacky way and abuse the uboot class to send commands to our own bootloader. This led me to further questions:
1. The TFTP deployment strategy does not seem to support deploying a rootfs. Is that correct? If yes, why?
2. Our bootloader supports download via HTTP as well, so actually we could get the files from the web to the device directly. The test system would not need to download any files then. LAVA does not seem to support such a scenario. All deployment strategies download the files first, before performing further steps.
How could I handle this case in LAVA? Obviously I could remove the deploy action from the job completely and handle everything in the boot command sequence. Still I would need some possibility to specify the URL of the image within the job, which the boot command sequence then should use. Is there a way to achieve this? I assume the correct way would be to implement a new deployment strategy for this, which does not do anything. However, this seems a bit weird to me. Is there another way? Or would the whole idea work against the general LAVA workflow?
3. As far as I understand, LAVA needs to apply an overlay tarball to the image before executing tests, which is usually performed directly on the image file before it is deployed to the target. This would not work in the case of (2). But I saw there is a boot action "transfer_overlay" to do this after the actual deployment. Is it correct, that I could use this action in such a case?
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
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
I finally tracked down what is going on here:
Here is the point of the problem while running test script:
Press SPACE to abort autoboot in 10 seconds
end: 2.4.2 bootloader-interrupt (duration 00:00:02) [common]
start: 2.4.3 bootloader-commands (timeout 00:01:58) [common]
bootloader-commands: Wait for prompt ['=>'] (timeout 00:01:58)
Script does detect "Press SPACE to abort autoboot in 10 seconds", and
issues a " ". Then it does NOT detect: Wait for prompt ['=>'].
I replaced old prompt ['U-Boot'] with ['=>'], but neither way it
detects U-Boot prompt.
Anyway, I do not understand the jinja2 command:
{% set bootloader_prompt = bootloader_prompt|default('U-Boot') %} ???
Hasn't => been always U-Boot prompt?
Thank you,
Zoran
_______
On Fri, Mar 2, 2018 at 11:44 AM, <magnus(a)minimum.se> wrote:
> I believe your issue is that LAVA doesn't detect your U-boot prompt
> correctly and does not try to issue any commands. Meanwhile, your kernel is
> autobooting and at line 541 of your pastebin, LAVA gives up waiting for a
> U-boot prompt.
>
> You may need to tweak your u-boot prompt settings and/or uboot interrupt
> sequence. I am not sure if LAVA is doing substring matching of the
> interrupt-prompt, so "Press SPACE to abort autoboot" _may_ not match a line
> that reads "Press SPACE to abort autoboot 10 seconds". But I'll leave that
> to the LAVA devs to answer.
>
> BTW, you should avoid making copies of base-uboot.jinja2. Instead you can
> override these things from your device type config, for example to override
> the interrupt-string you can do:
>
> {% set interrupt_prompt = 'Press SPACE to abort autoboot 10 seconds' %}
>
> and it will override the default value specified in base-uboot.jinja2. Same
> goes for your TFTP commands,
>
> {% set uboot_tftp_bootcmd = '- your list of uboot commands here as a
> yaml-list' %}
>
>
>
>
> On Fri, Mar 2, 2018 at 10:58, Zoran S <zoran.stojsavljevic.de(a)gmail.com>
> wrote:
>
> Some additional data to the use case from the initial email. I have
> changed /etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
> (changed u-boot massge before prompt, since I am using U-Boot 2017.12,
> and also hard-coded SERVER_IP since I have two networks inside VM -
> one public - 10.0.2.0/24, second private - 192.168.15.0/24).
>
> https://pastebin.com/T8Q7bhWj
>
> Zoran
> _______
>
> On Thu, Mar 1, 2018 at 4:56 PM, Zoran S
> <zoran.stojsavljevic.de(a)gmail.com> wrote:
>
> Hello,
>
> I have very interesting problem: I would like to do Lava testing of
> BBB01, but I am not suceeding.
>
> Simple and plain, my U-Boot scripts gets somehow rejected, they are
> not executed.
>
> I do download correctly, I have all the correct ingredients in place,
> but the U-Boot scripts are not activated, at the time of U-boot
> prompt.
>
> Here is my output, from the testing:
> https://pastebin.com/hTQQSLU1
>
> Rather, the thing gets executed from SDCard (from /boot on rootfs).
>
> I have no idea why this is not executed.
>
> Help appreciated!
>
> Thank you,
> Zoran
>
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lava-users
Hello,
When attachments were deprecated with v1, that left a hole in how to
easily get test artifacts (e.g. results files, image files, large
logs, etc.) off the DUT and into LAVA results.
I'm aware of tools like Artifactorial[1] which seem to help getting
files off the DUT and into a web service, but I'm not entirely sure
how to add pointers/URLs for those artifacts into the LAVA output,
such that they would be included in the notify callbacks.
Are there examples someplace for how to include links to artifacts
pushed to Artifactorial in LAVA callbacks?
Thanks,
Kevin
[1] https://github.com/ivoire/Artifactorial
Here could be a reference for you guys:
https://github.com/WindRiver-OpenSourceLabs/lava-base
Regards,
-Yang
Message: 3
Date: Thu, 1 Mar 2018 19:29:13 -0500
From: Chris McClellan <ckuhn203(a)gmail.com>
To: Conrad Djedjebi <conrad.djedjebi(a)linaro.org>
Cc: Lava Users Mailman list <lava-users(a)lists.linaro.org>
Subject: Re: [Lava-users] LAVA 2018
Message-ID: <07DC74CF-1EDC-4A20-AB08-F29739C0BCBB(a)gmail.com>
Content-Type: text/plain; charset="utf-8"
We're starting to look into it.
We've only gotten about as far as creating a dockerfile (for sid) that
defines the installation process though.
> On Mar 1, 2018, at 4:49 PM, Conrad Djedjebi <conrad.djedjebi(a)linaro.org>
wrote:
>
> Good morning LAVA users,
>
> I would like to know if there is someone among the LAVA users who
installed his own LAVA 2018 master instance ?
>
> Is everyone here using the LAVA LAB master instance available here :
https://validation.linaro.org ?
>
> Am I the only one who is installing his own LAVA 2018 master instance?
>
Hi Magnus Olsson,
Have you experienced issues regarding CSRF token?
After migrating from LAVA 2016 to LAVA 2018, did your first login into your
server return the following :
Django.png
<https://drive.google.com/a/linaro.org/file/d/0B0v46EqqhhcaVk9zM2N1UHJnM2NXd…>
?
Regards,
Le 2 mars 2018 05:47, "Magnus Olsson" <magnus(a)minimum.se> a écrit :
> We recently upgraded our master from an old 2016.11 to 2018.2. After about
> a week of fixing migration issues things are starting to work again. 2018.2
> is so far a good release, the only open issue we have left is the broken
> csv export that breaks our tools for generating external reports (
> https://projects.linaro.org/browse/LAVA-1253)
>
>
> On Mar 1, 2018 22:49, Conrad Djedjebi <conrad.djedjebi(a)linaro.org> wrote:
> >
> > Good morning LAVA users,
> >
> > I would like to know if there is someone among the LAVA users who
> installed his own LAVA 2018 master instance ?
> >
> > Is everyone here using the LAVA LAB master instance available here :
> https://validation.linaro.org ?
> >
> > Am I the only one who is installing his own LAVA 2018 master instance?
> >
> >
> > Best regards,
We recently upgraded our master from an old 2016.11 to 2018.2. After about a week of fixing migration issues things are starting to work again. 2018.2 is so far a good release, the only open issue we have left is the broken csv export that breaks our tools for generating external reports (https://projects.linaro.org/browse/LAVA-1253)
On Mar 1, 2018 22:49, Conrad Djedjebi <conrad.djedjebi(a)linaro.org> wrote:
>
> Good morning LAVA users,
>
> I would like to know if there is someone among the LAVA users who installed his own LAVA 2018 master instance ?
>
> Is everyone here using the LAVA LAB master instance available here : https://validation.linaro.org ?
>
> Am I the only one who is installing his own LAVA 2018 master instance?
>
>
> Best regards,
Good morning LAVA users,
I would like to know if there is someone among the LAVA users who installed
his own LAVA 2018 master instance ?
Is everyone here using the LAVA LAB master instance available here :
https://validation.linaro.org ?
Am I the only one who is installing his own LAVA 2018 master instance?
Best regards,
