I currently have an issue with starting lava-publisher. Whenever I run python manage.py lava-publisher I get output log:
2017-05-22 20:10:28,061 INFO publisher Dropping priviledges
2017-05-22 20:10:28,061 ERROR publisher Unable to lookup the user or the group
2017-05-22 20:10:28,062 ERROR publisher Unable to drop priviledges
I currently Have the same binaries in my own workstation and I am able to successfully connected to lava-publisher my output log gets:
2017-03-27 19:34:43,909 INFO publisher Dropping priviledges
2017-03-27 19:34:43,909 DEBUG publisher Switching to (lavaserver(126), lavaserver(133))
2017-03-27 19:34:43,909 INFO publisher Creating the input socket at ipc:///tmp/lava.events
2017-03-27 19:34:43,910 INFO publisher Creating the publication socket at tcp://*:5500
2017-03-27 19:34:43,910 INFO publisher Creating the additional sockets:
2017-03-27 19:34:43,910 INFO publisher Starting the proxy
I followed same steps to install from same repository on both machines. I somehow think this has to do with user or group not stored in database but I am not sure.
BTW: lava server/dispatcher both work well on both machines I just want to have an event notification client working on my second machine.
Thank you.
- Randy
Hello,
I am trying to setup Android tests on a B2260 board using LAVA V2 (
version 2017-05 ).
I have read LAVA documentation about Android tests and investigate about
existing Android jobs
and devices that have developed Android tests.
My questions:
* Is it essential to use linux container to perform Androids tests ?
* Do you have device-type, devices and jobs that would help me to
achieve my android tests ?
Best regards
Philippe
Hello,
Until then I've installed extra test packages from embedded test scripts.
Using the latest V2 version, I'm trying to manage this in my test jobs.
e.g.:
install:
deps:
- python-pytest
- python-lxml
- packagegroup-core-buildessential
- phoronix-test-suite
At execution time, I get a Error: OPKG package manager not found in the path.
Does this mean that OPKG is the only installer supported? Or is this the default one meaning that I can select DPKG or aptitude instead?
Best regards,
Denis
Hello Team,
This is just the request as a lava user.
It would be better if lava supports static ip configuration to deploy and
etc stuff with target board.
The user who dont have dhcp setup means this will be very useful to work
with target locally.
I hope you will consider this request and will support static ip also for
lava users.
Regards,
Guru
Hi Everyone,
In the Beaglebone-Black Health Check, `bbb_debian_ramdisk_test.yaml`,
located in the Linaro master repository
(https://git.linaro.org/lava-team/refactoring.git), there are the
following lines in the "action:" block:
---
kernel:
url:
http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/…
ramdisk:
url:
http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/…
compression: gz
# the bootloader needs a u-boot header on the modified ramdisk
add-header: u-boot
modules:
url:
http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/…
compression: gz
---
How is the `initramfs.cpio.gz` generated? KernelCI's build.py script
doesn't generate it. None of the Lava scripts generate it, yet it is
required to perform the boot test of a kernel on the Beaglebone Black. I
can't find it mentioned anywhere in the documentation either.
How did you generate this so it is compatible with the BBB? We want to
follow Linaro's standards, guidelines and recommendations as close as we
can, but this particular part seems to be missing.
Any help you can offer would be greatly appreciated.
Thank you!
--
Don Brown
Codethink, Ltd.
Software Engineering Consultant
Indianapolis, IN USA
Email: don.brown(a)codethink.co.uk
Mobile: +1 317-560-0513
Hi Everyone,
This week one of my teammates discovered that storage was very low on
our LAVA Server. After he investigated, he found that
/var/lib/lava/dispatcher gradually increases in size. He realized that
when a test is run, the files are accumulated in
/var/lib/lava/dispatcher/slave/tmp for each job. However, they are never
removed.
Does LAVA have a setting or does it have some kind of automation that
will remove tests, say, after X days or by some other criteria or, do we
need to remove them manually?
I appreciate any guidance you can offer.
Thank you!
--
Don Brown
Codethink, Ltd.
Software Engineering Consultant
Indianapolis, IN USA
Email: don.brown(a)codethink.co.uk
Mobile: +1 317-560-0513
Feature request:
Please add an option to "lava-server manage device-types" to add an
alias. Currently this can be done from the django interface, but the
command-line interface is much more automation friendly and
administrator friendly.
Thanks,
Kevin
Hi , we're attempting to use lava-ci to submit a test to lava, I've
cloned it from
https://github.com/kernelci/lava-ci.git
But when I attempt to submit a simple test
../lava-job-runner.py --username lavauser --token ... --server http://localhost:8080/RPC2
I get
Connecting to Server...
Connection Successful!
connect-to-server : pass
Gathering Devices...
Gathered Devices Successfully!
Gathering Device Types...
Gathered Device Types Successfully!
Submitting Jobs to Server...
but I don't see any submitted jobs in the lava2 web interface, is there
anything obvious elsewhere I should be checking? - or does the absence
of a 'Submitted Jobs successfully', if there should be one, means nothing
has been submitted?
Robert
Hi,
In LAVA v1, one could declare login commands to be run after logging in and
before starting any of the tests. For example:
"actions": [
{
"command": "deploy_image",
"parameters": {
"image": "https://some-url-to-a-rootfs.ext4.img.gz",
"bootfstype": "ext2",
"login_commands": [
"sudo su"
],
"login_prompt": "login:",
"username": "username",
"password_prompt": "Password:",
"password": "password"
}
},
In this case, "sudo su" is needed to open a regular user session and inherit
the user's environment while also having root privileges.
In LAVA v2, there isn't the possibility to do anything like this directly. One
could define a test with inline commands, but this is not ideal. The login
commands are not a test but part of how the job sets up the environment in
which the tests are run - i.e. it's part of the initial conditions. Also it's
quite a convoluted and lengthy way of running some commands, and it relies on
the side effects of that "login commands test" to persist when running
subsequent tests.
So I've made a couple of patches to see how this could be implemented in LAVA
v2 with an extra parameter in auto_login:
https://review.linaro.org/#/q/topic:T5703-login-commands
For example:
- boot:
method: qemu
auto_login:
login_prompt: 'login:'
username: user
password_prompt: 'Password:'
password: password
login_commands:
- sudo su
Essentially, this makes auto_login more flexible. At the moment, after logging
in auto_login sets the shell prompt: this is already some kind of hard-coded
login command. Some jobs need to run other things such as "sudo su" to stick
to the same example.
Another login command we've used is "systemctl --failed" to show if any systemd
units (services) failed to load during boot.
Notes from the Gerrit reviews:
* The login commands can't be part of a device definition as they are not
related to the device hardware or the boot configuration. For example, when
running Android, one would not want to run "sudo su" but maybe "setprop ..."
or something else - to be defined in each job.
* The login commands should not be fixed in a given distro / userspace
configuration as each job may need to set up a different initial environment.
For example, some jobs may need to be run with a regular user and would not
use the "sudo su" login command.
* Some documentation and unit tests would need to be added for this to be
merged. This is to first discuss the idea and review the code changes.
Any thoughts? Would it make sense to add this feature or maybe implement it
differently?
Best wishes,
Guillaume
