[bcc’d to everyone to ensure we get full coverage. Please ignore if you have no interest in LAVA and the Lab]
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 <http://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.
For future reference, for announcements about Lab availability, you should join the lava-users mailing list.
Thanks
Dave
----------------
Dave Pigott
LAVA Lab Lead
Linaro Ltd
t: (+44) (0) 1223 400063
Good morning everyone!
While running some tests using our Linux distro and a SuperMicro Intel D1521 board, we encounter a situation where a very long line (shown as a "broken line" in LAVA's logs - in the WEB UI) seems to interfere with the job run, in a sense that the job eventually ends in a timeout.
This does not happen when that particular set of tests is not run and I am wondering if this might be a LAVA issue.
--------------------
A bit of context, first.
SuperMicro boards "make sure" your board connection options are limited to using SoL (serial-over-lan), IPMI and a serial port (but in a very limited manner).
One is not able to do a "typical" image load, since you may not specify hardware addresses or properly interact with the bootloader.
This led to an approach which is best illustrated in the attached diagram.
For short: LAVA instantiates an LXC container, from where we run a series of scripts to prepare the board (copy some images & files on an already available Linux instance, altering the Grub menu and then rebooting the board, making it start the image we wish to test) and then run remote commands via SSH.
So, basically, the LXC container runs each and every command on the board, acting as the middleman.
-------------------
Now, we have the following:
* https://paste.debian.net/993516/ -> plain log excerpt that contains the very long line I was talking about (please see line no. 90)
* https://paste.debian.net/993517/ -> job definition
* https://paste.debian.net/993518/ -> test definition
Is there a way to further investigate if this type of output is "giving LAVA a hard time"? Is there a setting that limits interpreted output, somehow?
May it be that this is a LAVA issue?
Kind regards!
--
/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