Good morning everyone!
I am trying to "play around" with user queries in LAVA2. After reading about them (https://validation.linaro.org/static/docs/v2/lava-queries-charts.html?highl… ), I downloaded the provided sample script (https://validation.linaro.org/static/docs/v2/examples/source/query-results.… ), made the required updates (user names, query name, hostname & the such) and gave it a try.
The only thing I get stuck on is an XML-RPC lib error: "No such method: u'results.run_query'" (the whole traceback can be seen here: https://paste.debian.net/993833/ )
I have attached the modified script I am trying to run at the moment and a screenshot of the query settings.
The API Help page is not reachable/present at the moment (nor on https://validation.linaro.org/static/api/help or on our own LAVA instance ), so I am unable to check whether or not the method's name has changed since the last doc update.
What am I missing or doing wrong?
Many thanks in advance!
Have a great day!
--
/Dragoş
I have a minnowboard turbot device that I want lava to boot, flash,
reboot to flashed image, and then run tests. I would like to boot the
device via PXE networking to an initramfs where I will flash an image
to permanent storage. I can use efibootmgr within the initramfs image
to set next-boot to the permanent storage device. Once booted from
the permanent storage device, lava tests will run as per normal.
It appears that many of the ipxe examples I have found simply run
tests on the initramfs itself. Is it possible to flash the device
once the initramfs has booted? It seems like it would be simple for
lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda
once the initramfs has reached login. However, I do not know if there
is such a deploy mechanism.
Does anything already exist within lava to help achieve this model?
Is there a better way? Any feedback would be appreciated.
-Kevron
Hi all!
We have been working on integrating a cn8304-based board (uses uboot). We noticed some strange behavior that might be related to LAVA2.
On average, 2 out of 3 job runs end up with errors/timeouts. We use the same job definition and device each and every time.
Looking through LAVA logs, it seems that commands and some output gets truncated, thus malforming the commands being sent or the prompts that LAVA expects.
The prompt we expect is "EBB8304> ", but sometimes it gets truncated to "304>". Also, a command gets mixed up somehow, and instead of "setenv loadinitrd 'tftpboot 0x60000000 358/tftp-deploy-VLCRzw/ramdisk/ramdisk.ext4.gz.uboot'", the board receives "EBB8304> setenv loadkernel 'tftpboot 0x40setenv loadinitrd 'tftpboot 0x60000000 358/tftp-deploy-VLCRzw/ramdisk/ramdisk.ext4.gz.uboot'"
Details:
* The job definition: https://paste.debian.net/993349/
* An excerpt from the LAVA2 job log/output, showing what gets mixed up:
https://paste.debian.net/993350/
* The plain job log is attached to this e-mail
Many thanks in advance!
--
/Dragoş
Hi all,
Starting this week, we are finalising the transition of LAVA main production to LAVA V2. The main update and hopefully minor downtime, will commence at 09:00 UTC on Monday 6th November.
Along with this we will also be upgrading all micro-instances to Debian Stretch and LAVA 2017.11. There will be a brief period on Monday morning, which should be less than an hour, when remote logins will be disabled as we upgrade the gateway server.
Please note, that when validation.linaro.org comes back online, LAVA V1 job submissions will be rejected, so if you have any bots which auto-submit V1 jobs, please work with us to transition them to V2.
Thanks
Dave
----------------
Dave Pigott
LAVA Lab Lead
Linaro Ltd
t: (+44) (0) 1223 400063
Hey does anyone know why i'm getting an Error 503 Service Unavailable after installing LAVA on a new server? I have it installed on another system and i've never gotten this error on that system before. If it helps, i'm working behind a corporate proxy and here are the pertinent lines from lava-server.log in the apache log folder.
[Fri Oct 06 20:01:57.729804 2017] [proxy:error] [pid 2887:tid 140627852187392] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8000 (127.0.0.1) failed
[Fri Oct 06 20:01:57.729851 2017] [proxy_http:error] [pid 2887:tid 140627852187392] [client *IP*:56521] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
Thanks!
Jian Chern
Hi lava users,
We're trying to use lava-tool to automate the job submit process, but
having problem on using "lava-tool auth-add" command.
The error message is ERROR: Username provided but no token found.
I tried the instructions from the following page, but without luck.
https://validation.linaro.org/static/docs/v2/lava-tool-issues.html
I am pretty sure the user name, token, server url are correct since we
tested it with the example python script from above page's second
paragraph, and we can submit job through it.
The version of lava-tool is 0.23-1 and lava-server is 2017.10-1+jessie.
Does anyone have similar issue?
Thank you.
Michael Chen
Hi,
CIP just released Board At Desk v1.0 which is based on LAVAv2 and kernelci.
Link: https://www.cip-project.org/blog/2017/10/18/cip-launches-bd-v1-0
From those involved in this release, thanks to all of you who make
these technologies possible and also to those involved in kernelci.org
project. Thank you also for your support these past months.
Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito(a)codethink.co.uk
On 26 Sep 2017 2:59 am, "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp>
wrote:
Hi Neil,
> -----Original Message-----
> From: Neil Williams [mailto:neil.williams@linaro.org]
> Sent: Tuesday, September 12, 2017 5:49 PM
> To: Daniel Sangorrin
> Cc: Robert Marshall; Lava Users Mailman list
> Subject: Re: [Lava-users] Help running an inline test
>
> On 12 September 2017 at 09:25, Daniel Sangorrin
> <daniel.sangorrin(a)toshiba.co.jp> wrote:
> >
> >> -----Original Message-----
> >> From: Neil Williams [mailto:neil.williams@linaro.org]
> >> Sent: Tuesday, September 12, 2017 4:58 PM
> >> To: Daniel Sangorrin
> >> Cc: Robert Marshall; Lava Users Mailman list
> >> Subject: Re: [Lava-users] Help running an inline test
> >>
> >> On 12 September 2017 at 08:50, Daniel Sangorrin
> >> <daniel.sangorrin(a)toshiba.co.jp> wrote:
> >> > Hi Neil,
> >> >
> >> > Thanks for your reply.
> >> >
> >> >> -----Original Message-----
> >> >> From: Neil Williams [mailto:neil.williams@linaro.org]
> >> >> Sent: Tuesday, September 12, 2017 4:16 PM
> >> >> To: Daniel Sangorrin
> >> >> Cc: Robert Marshall; Lava Users Mailman list
> >> >> Subject: Re: [Lava-users] Help running an inline test
> >> >>
> >> >> On 12 September 2017 at 08:10, Daniel Sangorrin
> >> >> <daniel.sangorrin(a)toshiba.co.jp> wrote:
> >> >> > Robert, Neil:
> >> >> >
> >> >> > I managed to prepare a 2017.7 environment. The boot action still
works fine.
> >> >> > The test action still fails, but in a more 'sane' way I would say.
> >> >> > There are strange things like 'None', no lava-test-runner, etc..
Please check the
> >> >> > log attached.
> >> >>
> >> >> You haven't specified a deploy step, so there is no test shell
> >> >> created. Boot just does the boot - to deploy the test environment
> >> >> there must be a deploy action.
> >> >
> >> > As far as I understand, the deployment action occurs before the
> >> > boot action and consists of preparing a kernel/filesystem in some
> >> > media (e.g.: as a network filesystem).
> >> > Ref: https://validation.linaro.org/static/docs/v2/actions-deploy.html
> >> >
> >> > For now, I wanted to run my tests with the kernel and filesystem
> >> > that is already installed on the Flash memory. Is this impossible
with LAVA?
> >>
> >> Such a system can only be booted, it cannot operate a Lava Test Shell
> >> because there is no way to get the test shell onto the device without
> >> a deploy.
> >>
> >> There is support for primary connections using SSH
> >> https://validation.linaro.org/static/docs/v2/dispatcher-
design.html#primary-connection
> >>
> >> See: Problems with simplistic testing in the documentation.
> >> https://validation.linaro.org/static/docs/v2/simple-admin.
html#problems-with-simplistic-testing
> >
> > Thanks a lot Neil.
> > # I'm not against deployment, I just wanted to prepare the environment
step by step.
> >
> > The primary connection could be a good solution but it looks like I
wouldn't be able to use the PDU,
> > or the autologin features from the u-boot action through the serial
port. I will implement the
> > deploy action instead.
> >
> > By the way, when you talk about "test shell" I am assuming that you
mean a shell script or binary
> > that is copied into the target filesystem and executed. Is that correct?
> > My filesystem is very minimal: basically busybox using the ash shell.
>
> "test shell" == Lava Test Shell as defined by the test action block.
> This relies on POSIX behaviour where the automation drives scripts
> installed onto the system to execute the test operations themselves.
>
> To handle busybox ash compatibility, just set the Operating System as
> Open Embedded.
>
> actions:
> - deploy:
> # ... rest of the deploy
> os: oe
>
> https://validation.linaro.org/static/docs/v2/actions-deploy.html#index-18
Sorry, it took me a while but I finally got it working.
I met several problems. Some of them were a matter of overriding variables.
For example,
I cannot use dhcp for the board so I had to change uboot_ipaddr_cmd and
base_ip_args.
There was one variable (SERVER_IP) I couldn't override, so I had to modify
base-uboot.jinja2 for it.
my jinja2:
{% set uboot_serverip = '192.168.1.66' %}
base-uboot.jinja2
# vi /etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
{% set base_uboot_tftp_bootcmd = uboot_tftp_bootcmd|default(
" - setenv bootcmd '" + uboot_ipaddr_cmd|default('dhcp') + ";
setenv serverip " + uboot_serverip|default('{SERVER_IP}') + "; run
loadkernel; run loadinitrd; " + run_load_fdt +
uboot_bootx_cmd|default('{BOOTX}')
+ "'
- run bootcmd") -%}
Note: I tried modifying LAVA_SERVER_IP and LAVA_NETWORK_IFACE in
/etc/lava-dispatcher/lava-dispatcher.conf as well but it didn't work.
Those settings are only relevant for V1, so V2 tests will ignore these.
Setting the SERVER_IP in the device configuration is the wrong approach.
This IP address is for the dispatcher, so it needs to be added to the
dispatcher configuration. In V2, the dispatcher configuration is sent from
the master.
Setting a fixed IP address for the dispatcher is already supported.
See /usr/share/lava-dispatcher/dispatcher.yaml for an example.
See
https://validation.linaro.org/static/docs/v2/pipeline-admin.html#extra-disp…
You need a file named according to the hostname of the dispatcher as it
appears in the dispatcher-master log file.
If you consider it useful, please consider including it in the mainstream
code.
Thanks for your help,
Daniel
> >> >> >> -----Original Message-----
> >> >> >> From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On
Behalf Of Daniel Sangorrin
> >> >> >> Sent: Monday, September 11, 2017 5:16 PM
> >> >> >> To: 'Robert Marshall'; 'Lava Users Mailman list'
> >> >> >> Subject: Re: [Lava-users] Help running an inline test
> >> >> >>
> >> >> >> > -----Original Message-----
> >> >> >> > From: Lava-users [mailto:lava-users-bounces@lists.linaro.org]
On Behalf Of Robert Marshall
> >> >> >> > Sent: Monday, September 11, 2017 4:47 PM
> >> >> >> > To: 'Lava Users Mailman list'
> >> >> >> > Subject: Re: [Lava-users] Help running an inline test
> >> >> >> >
> >> >> >> > "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp> writes:
> >> >> >> >
> >> >> >> > > Hi Neil,
> >> >> >> > >
> >> >> >> > > Thanks for your quick reply.
> >> >> >> > >
> >> >> >> > >> -----Original Message-----
> >> >> >> > >> From: Neil Williams [mailto:neil.williams@linaro.org]
> >> >> >> > >> Sent: Monday, September 11, 2017 3:23 PM
> >> >> >> > >>
> >> >> >> > >> On 11 September 2017 at 07:06, Daniel Sangorrin
> >> >> >> > >> <daniel.sangorrin(a)toshiba.co.jp> wrote:
> >> >> >> > >> > Hi,
> >> >> >> > >> >
> >> >> >> > >> > I have spent a few days learning LAVA with QEMU and the
Beagle Bone black.
> >> >> >> > >> > Now, I'm trying to setup a Renesas iwg20m board but I
have some strange
> >> >> >> > >> > problem.
> >> >> >> > >> > # I'm using LAVA v2016.12.
> >> >> >> > >>
> >> >> >> > >> Updates are available - you should follow the LAVA
documentation for
> >> >> >> > >> the LAVA repositories and upgrade.
> >> >> >> > >>
> >> >> >> > >> https://staging.validation.linaro.org/static/docs/v2/
installing_on_debian.html#lava-repositories
> >> >> >> > >
> >> >> >> > > Thanks, I will try with the 2017.9 version then.
> >> >> >> > >
> >> >> >> > Daniel
> >> >> >> >
> >> >> >> > If you're doing the test within b@d [1] you should look at my
> >> >> >> > https://gitlab.com/rajm/board-at-desk-single-dev/tree/
lava2017-fixes
> >> >> >> > branch which has various fixes for our use of lava 2017-7,
once that
> >> >> >> > branch is merged - soon now! - it should 'just work'
> >> >> >>
> >> >> >> Wow Robert, just in time! Thanks.
> >> >> >>
> >> >> >> Daniel
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Lava-users mailing list
> >> >> >> Lava-users(a)lists.linaro.org
> >> >> >> https://lists.linaro.org/mailman/listinfo/lava-users
> >> >> >
> >> >> > _______________________________________________
> >> >> > Lava-users mailing list
> >> >> > Lava-users(a)lists.linaro.org
> >> >> > https://lists.linaro.org/mailman/listinfo/lava-users
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Neil Williams
> >> >> =============
> >> >> neil.williams(a)linaro.org
> >> >> http://www.linux.codehelp.co.uk/
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> Neil Williams
> >> =============
> >> neil.williams(a)linaro.org
> >> http://www.linux.codehelp.co.uk/
> >
> >
> >
>
>
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/