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
Hi Everyone,
I have a co-worker who wants to use our Kernel CI & Lava Virtual
Machine. He says he wants to boot the VM, log in, and run a command that
downloads a kernel and then tests multiple defconfig's and multiple
versions of the Linux kernel. What is the best tool to do this (lava-ci,
lava-tool, or a different tool)?
Can you point me to some examples of the tool you recommend?
Any help you can offer would be greatly appreciated.
--
Don Brown
Codethink, Ltd.
Software Engineering Consultant
Indianapolis, IN USA
Email: don.brown(a)codethink.co.uk
Mobile: +1 317-560-0513
Hello,
I'm trying to set one timeout per test in a job. To do so I'm declaring one test block per test.
Unfortunately, it seems that only the first timeout declaration is taken into account. Did I miss something in my job definition?
Best regards,
Denis
Dear all,
This is my first post on the mailing list, I hope I'm at the right place.
Using Lava V2, I'm trying to install packages in the DUT following the guidelines from
https://validation.linaro.org/static/docs/v2/writing-tests.html#test-defini…
My job looks like this:
metadata:
(...)
install:
sources:
- http://<local_network_package_server>/sti
- http:// <local_network_package_server>/all
- http:// <local_network_package_server>/cortexa9hf-neon
deps:
- python-pytest
- python-lxml
- packagegroup-core-buildessential*
run:
steps:
- step1
- step2
parse:
pattern: "^(?P<test_case_id>\\w+) RESULT:(?P<result>(pass|fail|unknown))"
fixupdict:
FAILED: fail
SUCCESS: pass
ABORTED: unknown
Running this test, I get the following error:
<LAVA_TEST_RUNNER>: started<LAVA_TEST_RUNNER>: looking for work in /lava-3715/0/lava-test-runner.conf-1484266027
<LAVA_TEST_RUNNER>: running 0_TC_BENCH_DISK_AIO_STRESS under lava-test-shell...
<LAVA_TEST_RUNNER>: running 0_TC_BENCH_DISK_AIO_STRESS installer ...
/lava-3715/0/tests/0_TC_BENCH_DISK_AIO_STRESS/install.sh: line 5: lava-add-sources: command not found
/lava-3715/0/tests/0_TC_BENCH_DISK_AIO_STRESS/install.sh: line 6: lava-add-sources: command not found
/lava-3715/0/tests/0_TC_BENCH_DISK_AIO_STRESS/install.sh: line 7: lava-add-sources: command not found
Error: OPKG package manager not found in the path.
It seems lava-add-sources is not copied to the target. Do I understand the log correctly?
Best regards,
Denis
Hello Team,
My name is guru. i am very new to lava and i am very much interested using
lava concept for embedded linux boards for auto deployment and testing
concepts.
I tried to setup the lava for bbb device. i have followed below steps for
that.
> 1. installed debian on vm machine and lava-server and its component
(jessie-backport) 2016.
> 2. just for understanding purpose i tried to add kvm job it was loaded
successfully.
> 3. Now i am trying to add the BBB device on lava.
> 4. For that i have added the bbb device to dispatcher. find the conf file
below
> name: beaglebone-black01.conf
> content :
> device_type = beaglebone-black
> hostname = beaglebone-black01
> connection_command = telnet localhost 2003
> hard_reset: /usr/bin/reset.sh
> power_off: /usr/bin/off.sh
> power_on: /usr/bin/on.sh
> Note : i am not using pduclient. i am using my own script for control
commands
> but it is not working while executing the hard_reset command on lava..
find
the log for more details.
>
> 5. My current setup is like i am controlling the bbb using serial
controlled
relay from VM host machine(debian).
>
> for that i made my own custom script to on.off,reset serial python code
for
controlling the relay.
> 6. after that i tried to submit the below json test job. Find My
definition
job attached.
> I have taken the below json for reference.
> https://git.linaro.org/lava-team/lava-functional-tests.
git/tree/lava-test-shell/single-node/armmp-bbb-daily.json
> 7. after that i have submitted the job . find the job log for more
details.
> 8. i have no idea what is going on and what went wrong on my setup.
> Help me out to boot the BBB using lava.
Regards,
Guru
On 27 March 2017 at 14:54, Ковалёв Сергей <SKovalev(a)ptsecurity.com> wrote:
> Thank you Neil for you reply.
Please keep the list in CC:
>
>> Compare with: https://staging.validation.linaro.org/scheduler/job/168802
>
> I have tried https://staging.validation.linaro.org/scheduler/job/168802/definition but iPXE stuck on it. I have amd64 machine with UEFI.
"stuck" ? This is a standard amd64 Debian kernel with modules and
initramfs. It is already UEFI-aware. Does the machine run Debian
natively? Is there a Debian kernel you can use in your LAVA
submissions (with modules and ramdisk)?
>> First step is to replace these files with images which work on the x86 DUT on staging.validation.linaro.org
>
> I perform kernel development with my colleagues so I have to load our kernels.
Yes, however, to debug what is going on, you should switch to known
working files so that you have a valid comparison with known working
test jobs. Once debugging has produced some results, then switch back
to the locally built kernels. Change one thing at a time.
>> That just isn't going to work. The initrd needs to come via TFTP but this is an absolute path.
>
> 'initrd' is come via TFTP. In context I supply additional kernel boot options.
Your original email quoted:
context:
extra_kernel_args: initrd=/rootfs.cpio.gz root=/dev/ram0
rootfs.cpio.gz does not exist when the machine boots. The initramfs
will have been downloaded by TFTP and loaded directly into memory, it
simply does not exist as a cpio.gz any longer. /dev/ram0 shouldn't be
needed with modern kernels. At best, it would seem that these options
are ignored.
Debian initramfs log:
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Warning: fsck not present, so skipping unknown file system
mount: can't find /root in /etc/fstab
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... mount: mounting /dev on
/root/dev failed: No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
done.
mount: mounting /run on /root/run failed: No such file or directory
run-init: current directory on the same filesystem as the root: error 0
Target filesystem doesn't have requested /sbin/init.
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
No init found. Try passing init= bootarg.
BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Matched prompt #5: \(initramfs\)
> This boot option have been detected before effort to automate the process with LAVA. Without it we could see kernel panic. With it we successfully load kernel and rootfs (from Buildroot). May be in Linaro you embed that boot options in compile time?
No, we do not embed anything in V2 (it's one of the key changes from
V1, we don't hid magic like that anymore.)
The files were prepared with:
https://git.linaro.org/lava-team/refactoring.git/tree/scripts/x86_64-nfs.sh
You can also see the build log for the original Debian kernel package
if relevant.
https://tracker.debian.org/pkg/linux-signedhttps://buildd.debian.org/status/fetch.php?pkg=linux-signed&arch=amd64&ver=…
Running x86_64-nfs.sh in an empty directory will provide access to the
config of the kernel itself as well as the initramfs and supporting
tools.
It's possible these context arguments are hiding some other problem in
the kernel but, as described so far, the options seem to make no
sense.
The command line used in our tests is simply: Command line: ip=dhcp
console=ttyS0,115200n8 lava_mac={LAVA_MAC}
(where LAVA_MAC does not need to be defined for these devices.)
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
