Hi ,
I deploy the device with grub(uefi) method. Now it can interrupt to grub>, and run the boot cmd and auto login. I use the pxe iso installation boot or the sata boot, not the nfs boot.
But the lava-overlay file only add into ramdisk(initrd.img), it will disappear when os bootup. So I use the transfer_overlay in my job , but it do nothing, the test shell can't be find .
Please give me some help!
Job.yaml:
actions:
- deploy:
to: tftp
kernel:
url: http://swlab004/1680141/vmlinuz-4.11.0-7.1.hxt.aarch64
type: zimage
ramdisk:
url: http://swlab004/1680141/initramfs-4.11.0-7.1.hxt.aarch64.img
compression: gz
install_overlay: false
preseed:
url: http://swlab004/centos7/anaconda-ks_1026.cfg
os: centos
timeout:
minutes: 5
- boot:
timeout:
minutes: 200
connection: serial
method: uefi-menu
commands: ramdisk_boot
auto_login:
login_prompt: ".* login:"
username: root
password_prompt: 'Password:'
password: root
transfer_overlay:
download_command: ifconfig;wget -S --progress=dot:giga
unpack_command: tar -C / -xzf
prompts:
- 'Last login: .*'
- '[root@.* .*]#'
parameters:
shutdown-message: "reboot: Restarting system"
- test:
timeout:
minutes: 50
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: smoke-tests-basic
description: "Basic system test command for Linaro Ubuntu images. The test runs basic commands like pwd, uname, vmstat, ifconfig, lscpu, lsusb and lsb_release."
maintainer:
- hongyu.xu(a)hxt-semitech.com
os:
- centos
scope:
- functional
run:
steps:
- echo "test1a:" "pass"
from: inline
name: smoke-tests1
path: inline/smoke-tests.yaml
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.
Greetings,
my embedded system is using Mender for over-the-air updates.
The way Mender works is that the embedded system needs to have to rootfs
partitions, where one is actively being used, and the other is written to
when a over-the-air update is initiated. After the new rootfs is written,
Mender will change a variable in the bootloader environment and reboot, so
that the system boots into the new rootfs. If there is a problem booting
into the new rootfs, the bootloader will be set to boot into the old one
again.
Has anyone here written LAVA tests for systems that use Mender? If so, have
you experienced that Mender has complicated the test automation?
Any Mender boot test templates would also be appreciated.
--
Kind regards,
Arnstein Kleven
Hi dear all,
I boot my device with nfs in lava, but it can't auto login the os , I put the logs to attachment !
Please give me some idear.
And I can boot and auto login successful with sata boot, use the same job.yaml file!
My job 454 :
device_type: amberwing_rep1
job_name: amberwing_rep_nfs
priority: medium
visibility: public
metadata:
docs-filename: amberwing_rep_nfs
timeouts:
job:
minutes: 300
action:
minutes: 200
connection:
minutes: 100
actions:
- deploy:
to: tftp
kernel:
url: http://swlab004/centos7/iso20171026-0/images/pxeboot/vmlinuz
type: zimage
ramdisk:
url: http://swlab004/centos7/iso20171026-0/images/pxeboot/initrd.img
compression: xz
install_overlay: false
nfsrootfs:
url: http://autotest002/tmp/rootfs_centos.tar.gz
install_overlay: true
preseed:
url: http://swlab004/centos7/anaconda-ks_1026.cfg
os: centos
timeout:
minutes: 5
- boot:
timeout:
minutes: 200
connection: serial
method: uefi-menu
auto_login:
login_prompt: '.* login:'
username: root
password_prompt: 'Password:'
password: root
commands: nfs_boot
prompts:
- 'Last login: .*'
- '[root@.* .*]#'
parameters:
shutdown-message: "reboot: Restarting system"
- test:
timeout:
minutes: 50
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: smoke-tests-basic
description: "Basic system test command for Linaro Ubuntu images. The test runs basic commands like pwd, uname, vmstat, ifconfig, lscpu, lsusb and lsb_release."
maintainer:
- hongyu.xu(a)hxt-semitech.com
os:
- centos
scope:
- functional
devices:
- amberwing_rep-022
run:
steps:
- echo "test1a:" "pass"
from: inline
name: smoke-tests1
path: inline/smoke-tests.yaml
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.
LAVA requires a range of singleton daemon processes to schedule, organise,
publish and log the test job operations. 2017.12 will be retiring the
lava-server daemon and the /var/log/lava-server/lava-scheduler.log, moving
those operations into the lava-master daemon and the
/var/log/lava-server/lava-master.log. This is one of the steps in the
removal of V1.
This leads a substantial change to how admins approach an instance running
2017.12 or later.
When jobs don't appear to be running for some reason, the default action is
to check /var/log/lava-server/lava-scheduler.log - once the instance is
running 2017.12 or later, admins need to remember that it is correct for:
* /var/log/lava-server/lava-scheduler.log to be empty
* the status of the lava-server daemon to be active (exited)
* the lava-server service to not restart
At some point after 2017.12 has been running, admins can choose to archive
or purge /var/log/lava-server/lava-scheduler.log* and / or disable the
lava-server service using systemctl.
The scheduler from 2017.12 onwards will consist of:
* /var/log/lava-server/lava-master.log
* /var/log/lava-server/lava-logs.log
* the status of the lava-master daemon will be active (running)
* the lava-master service will restart when admins request it.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
[ Related-ish to the discussion in the "Fastboot - Android boot image
apply-overlay" thread, but also slightly different so I'm starting a
new discussion here... ]
Hi folks,
We were just discussing in IRC about potential problems with Android
images in LAVA, in terms of fitting the overlay.
Ideally, the Android builds would have a rootfs configured to be as
small as possible - it's automatically resized to fit the available
space at first boot, and leaving space otherwise is
inefficient. However, if we're going to add the LAVA test overlay into
the rootfs, space needs to be left for it to fit. That's not
*necessarily* a problem, except that at build time the Android builds
don't know how much space we're going to need! This leads to a bit of
a chicken-and-eff problem.
Anibal has already hacked around this a little bit as a workaround in
a job definition - see
https://validation.linaro.org/scheduler/job/1652299/definition#defline92
In the lxc, he's converting and expanding the rootfs image to make
more space, then converting back ready for flashing. This is still
quite hacky - there's still no information available there about the
size of the LAVA overlay. It might fit now, but what happens if
there's a new LAVA version next month with (hypothetically) a much
bigger overlay?
So, I'm thinking about a better way to do things here, in 2 parts:
1 .At the point when we apply the overlay, we know roughly how big it
is and we could do the resizing of the image to fit directly
without needing this guesswork. It's a relatively easy thing to
do.
2. [Optionally] If we end up growing the rootfs image ourselves, it
*might* end up overflowing the size available when we come to
flash things, but "fastboot flash" will check this and abort. I
even suggested that (to fail more quickly) we could parse the GPT
partition table for size ourselves, but Nicolas pointed out that
not all jobs will necessarily have such a partition table.
Instead, *maybe* we could include a "maximum rootfs size"
parameter somewhere if we care. Otherwise, just rely on fastboot
doing the right thing.
Does this sound sensible?
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hello Lava team,
We have implemented new scripts to support flashing in our "power on" script.
This script manage the PDU, boot pins configuration of the board and an external ST flasher.
At the beginning of the job, the "power on" script is launched.
Then I got the following error message <line way too long ...> .
This cause the execution script to be interrupted, but the job is not interrupted and can continue without flashing the board.
I do not have any additional logs regarding this error on the LAVA web interface.
Our power on script is composed of several scripts that are "chained", script power on call another script,
that call another one.
Do you have an idea about this error ?
Details concerning our configuration :
* we use LAVA V2 ( version 06/2017 ).
* our jobs are pipelined jobs ( LAVA V2)
* Lava server // dispatcher are installed through dockers.
BR
Philippe
LAVA, until now, has packaged SysVinit files to manage the various daemons
but there have been longstanding problems with log rotation and the need to
carry redundant code to manage the daemonize process for python scripts.
This has allowed instances to support both SysVinit and systemd because
systemd automatically converts the SysVinit files to systemd service files.
Now that V1 has been removed, it has become possible and advantageous to
drop SysVinit support and move to only systemd support. This is expected to
mean that lava-dispatcher (and therefore lava-server) will depend on
systemd-sysv, i.e. systemd needs to be the init system to be able to start
the daemons upon which LAVA relies.
A default install of Debian Jessie and Stretch already defaults to using
systemd as the init system, so this does not necessarily involve any
changes.
If there are questions or issues with this, please reply to the lava-users
mailing list.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi all,
We are planning implementing a test that uses QDL (https://git.linaro.org/landing-teams/working/qualcomm/qdl.git/) for DragonBoard flashing.
Scenario:
after we flashed the binaries with QDL we want to check in the serial log if the boot sequence is correct.
Can we develop this test in LAVA?
If not, please recommend a test framework that can.
Thank you,
Alfred
