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,
Hey,
Not sure where to report LAVA bugs, https://wiki.linaro.org/LAVA (https://wiki.linaro.org/LAVA) indicates I should use the Linaro bugzilla but it seems to be closed? Anyway, I think there's an issue with the CSV result export in LAVA 2018.2, can anyone confirm?
Example CSV: https://validation.linaro.org/results/1686046/csv (https://validation.linaro.org/results/1686046/csv)
The first line of the CSV file is:
[u'job', u'suite', u'result', u'measurement', u'unit', u'duration', u'timeout', u'logged', u'level', u'metadata', u'url', u'name', u'id']1686046,12_bootchart-stop,pass,None,,,,2018-02-28 05:01:35.935783+00:00,,"{'case': 'generate-bootchart-graphic', 'definition': '12_bootchart-stop', 'result': 'pass'}",/results/testcase/2871860,generate-bootchart-graphic,2871860
.. when it probably should've been two lines:
job,suite,result,measurement,unit,duration,timeout,logged,level,metadata,url,name,id
1686046,12_bootchart-stop,pass,None,,,,2018-02-28 05:01:35.935783+00:00,,"{'case': 'generate-bootchart-graphic', 'definition': '12_bootchart-stop', 'result': 'pass'}",/results/testcase/2871860,generate-bootchart-graphic,2871860
I believe the issue is 1) a missing linebreak after the header-line and 2) the formatting of the header line (drop the Python repr stuff).
I have the same problem trying to login to admin on localhost. For me it's
independent of browser and browser cookie configuration. I assume it's an
issue with Django configuration.
Regards
Bill
--
EMEA Field Engineering
Linaro Ltd
Harston Mill CB22 7GG
Cambridge UK
+44 7833 498336 <+44%207833%20498336>
