Hi,
I have an impression that we can have test image "dummy" deployed once I am
sure the image in the device is bootable.
That will save time for downloading and flashing to the device.
Does it still be supported in LAVA v2?
Thanks,
Arthur
Hermanth,
You were able to install on stretch?
I was attempting to do so, but the python3-django-auth-ldap package
wasn't available on anything but sid.
Did you run into the same issue?
Regards,
Chris
> Date: Tue, 27 Feb 2018 14:10:46 +0530
> From: Hemanth K V <kv.hemanth.mys(a)gmail.com>
> To: Lava Users Mailman list <lava-users(a)lists.linaro.org>
> Subject: [Lava-users] set up issue
> Message-ID:
> <CAEua01SDZE6=7+rgnr6+1WA-j3Z3g2ECywP0qtT0xR8Z9GE9Gw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Lava-Users,
>
> After following the setup of LAVA on Debian 9 stretch and when we try to
> login from UI we face the following error Ref
> https://validation.linaro.org/static/docs/v2/installing_on_debian.html
>
> $ sudo apt install postgresql
> $ sudo apt install lava-server
>
> If the default Apache configuration from LAVA is suitable, you can enable
> it immediately:
>
> $ sudo a2dissite 000-default
> $ sudo a2enmod proxy
> $ sudo a2enmod proxy_http
> $ sudo a2ensite lava-server.conf
> $ sudo service apache2 restart
>
> Forbidden (403)
>
> CSRF verification failed. Request aborted.
>
> You are seeing this message because this site requires a CSRF cookie when
> submitting forms. This cookie is required for security reasons, to ensure
> that your browser is not being hijacked by third parties.
>
> If you have configured your browser to disable cookies, please re-enable
> them, at least for this site, or for 'same-origin' requests.
>
>
> Is there anything missing from the setup.
>
>
> Thanks,
>
> Hemanth.
Hi all,
Why I can't receive the email when I use the 'User notifications' in LAVA ?
notify:
criteria:
status: canceled
verbosity: quiet
recipients:
- to:
method: email
email: hongyu.xu(a)hxt-semitech.com<mailto:hongyu.xu@hxt-semitech.com>
or
notify:
criteria:
status: complete
verbosity: quiet
recipients:
- to:
user: '1680141'
method: email
[cid:image001.png@01D3AFE4.37D7A500]
Best Regards
XuHongyu
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.
This is a django configuration issue. I don’t understand why this case (it is very common, obviously) is not handled in the LAVA documentation explicitly. There is a short hint, though, here:
https://validation.linaro.org/static/docs/v2/pipeline-debug.html#using-loca…
You have to add these two variables to /etc/lava-server/settings.conf:
"CSRF_COOKIE_SECURE": false,
"SESSION_COOKIE_SECURE": false
I achieved this using the following commands:
sudo apt-get install jq
jq '.CSRF_COOKIE_SECURE=false | .SESSION_COOKIE_SECURE=false' /etc/lava-server/settings.conf > /tmp/settings.conf && mv /tmp/settings.conf /etc/lava-server/settings.conf
sudo chown root:root /etc/lava-server/settings.conf
sudo service lava-server-gunicorn restart
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
Hello Lava-Users,
After following the setup of LAVA on Debian 9 stretch and when we try to
login from UI we face the following error Ref
https://validation.linaro.org/static/docs/v2/installing_on_debian.html
$ sudo apt install postgresql
$ sudo apt install lava-server
If the default Apache configuration from LAVA is suitable, you can enable
it immediately:
$ sudo a2dissite 000-default
$ sudo a2enmod proxy
$ sudo a2enmod proxy_http
$ sudo a2ensite lava-server.conf
$ sudo service apache2 restart
Forbidden (403)
CSRF verification failed. Request aborted.
You are seeing this message because this site requires a CSRF cookie when
submitting forms. This cookie is required for security reasons, to ensure
that your browser is not being hijacked by third parties.
If you have configured your browser to disable cookies, please re-enable
them, at least for this site, or for 'same-origin' requests.
Is there anything missing from the setup.
Thanks,
Hemanth.
Hello Lava Users,
Trying to setup the x86 based board to our local lava farm to execute tests.
Want to boot the target with pxe based mechanism .Trying to follow the
job definition https://staging.validation.linaro.org/scheduler/job/210084/definition
.With this facing the following error when running the job.Let me know
if i am missing anything with job defination or device defination .
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py",
line 563, in validate
self.internal_pipeline.validate_actions()
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py",
line 201, in validate_actions
action.validate()
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/boot/ipxe.py",
line 221, in validate
elif self.parameters['commands'] not in
device_methods[self.parameters['method']]:
TypeError: unhashable type: 'list'
Device dictionary defination is
Device dictionary yaml:
connection_command: telnet localhost 8021
extends: x86.jinja2
Thanks,
Hemanth.
Hello,
I am bringing now the target Beaglebone Black, as DUT in Lava.
Here is my BBB01.jinja2 device definition:
{% extends 'beaglebone-black.jinja2' %}
{% set connection_command = '/vagrant/scripts/connectBBB.sh localhost
8020 root ""' %}
{% set power_on_command = '/usr/bin/egctl egenie on left left left' %}
{% set power_off_command = '/usr/bin/egctl egenie off left left left' %}
{% set hard_reset_command = '/usr/bin/egctl egenie on left left left' %}
Where the line: "vagrant/scripts/connectBBB.sh localhost 8020 root ""'
represents as $@ the following: 127.0.0.1 8020 root and "" (""
represents empty password, actually <cr>).
It seems that this part works correctly:
end: 2.4.1 reset-device (duration 00:00:00)
start: 2.4.2 u-boot-interrupt (timeout 00:03:00)
Changing prompt to 'Press SPACE to abort autoboot'
u-boot-interrupt: Wait for prompt Press SPACE to abort autoboot
(timeout 00:03:00)
spawn telnet localhost 8020
Trying ::1...
Connected to localhost.
Escape character is '^]'.
ser2net port 8020 device /dev/ttyUSB0 [115200 N81] (Debian GNU/Linux)
end: 2.4.2 u-boot-interrupt (duration 00:00:02)
start: 2.4.3 bootloader-commands (timeout 00:02:58)
Changing prompt to start interaction: U-Boot
bootloader-commands: Wait for prompt U-Boot (timeout 00:03:00)
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unable to read file boot.scr **
** Unable to read file uEnv.txt **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unable to read file boot.scr **
** Unable to read file uEnv.txt **
4161168 bytes read in 293 ms (13.5 MiB/s)
35016 bytes read in 23 ms (1.5 MiB/s)
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Device Tree to 8fff4000, end 8ffff8c7 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.13.8-jumpnow (oe-user@oe-host) (gcc
version 7.2.0 (GCC)) #1 Fri Jan 12 13:27:03 CET 2018
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] cma: Reserved 16 MiB at 0x9f000000
[ 0.000000] CPU: All CPU(s) started in SVC mode.
But when it comes to login to kernel login, it fails!
Starting OpenBSD Secure Shell server: sshd
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_rsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_dsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_ed25519_key
sshd: no hostkeys available -- exiting.
Starting rpcbind daemon...done.
starting statd: done
exportfs: can't open /etc/exports for reading
modprobe: can't change directory to '/lib/modules': No such file or directory
NFS daemon support not enabled in kernel
Starting syslogd/klogd: done
Poky (Yocto Project Reference Distro) 2.3.2 beaglebone /dev/ttyO0
beaglebone login: [ 170.488770] random: crng init done
bootloader-commands timed out after 178 seconds
end: 2.4.3 bootloader-commands (duration 00:02:58)
uboot-retry failed: 1 of 1 attempts. 'bootloader-commands timed out
after 178 seconds'
bootloader-commands timed out after 178 seconds
end: 2.4 uboot-retry (duration 00:03:00)
uboot-action failed: 1 of 1 attempts. 'bootloader-commands timed out
after 178 seconds'
bootloader-commands timed out after 178 seconds
end: 2 uboot-action (duration 00:03:00)
Cleaning after the job
Cleaning up download directory:
/var/lib/lava/dispatcher/tmp/84/tftp-deploy-a0ZzPD/ramdisk
Cleaning up download directory:
/var/lib/lava/dispatcher/tmp/84/tftp-deploy-a0ZzPD/kernel
Cleaning up download directory:
/var/lib/lava/dispatcher/tmp/84/tftp-deploy-a0ZzPD/dtb
Cleaning up download directory:
/var/lib/lava/dispatcher/tmp/84/tftp-deploy-a0ZzPD/modules
start: 4.1 power-off (timeout 00:00:05)
nice /usr/bin/egctl egenie off left left left
command output socket 1 - off
socket 2 - off
socket 3 - off
socket 4 - off
It seems that empty character as "" in jinja2 is noit well represented
(or maybe I need to have somehow <CR>)?!
Any advise too this problem?
Thank you,
Zoran
zo
Hi Neil, thanks for your reply.
>Why do you need an in-house bootloader? (Hint: Just because you can / have
>is the worst possible reason.) Honestly, just find some other way to do it
>- it will likely be much quicker.
We have developed our own bootloader for our hardware, for various reasons, and want our OS to be tested in combination with it. Our devices do not support any other bootloader except our own anyway, so there is no other possibility. This is what we have, and we need to automate testing somehow. So I am trying to figure out whether LAVA is suitable for this task.
>Supporting a new bootloader is a very complex and time-consuming process
>for any test framework. It typically takes several months. Once done, there
>is an ongoing maintenance burden as the code for the supported bootloaders
>continues to advance.
This is not a problem generally. We are planning long-term and want a future-proof solution.
>You need a new Strategy Class, as per the documentation. You must not
>overload the "method: u-boot" support for anything except U-Boot. You must
>create a new boot method.
Why? What is wrong with using the u-boot method for a bootloader which works similarly? As far as I can see right now, I would only remove stuff from the u-boot method and set a bunch of already existing variables to new values. I do not see the need for a completely new boot method. Is there any hard reason for this, except that it would be neater?
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
