Hi
I have a locally built initramfs which worked with a beaglebone black health check in LAVA 2016-12 but with version 2017-7 the health check is failing. I've tried using an initramfs from http://images.validation.linaro.org/snapshots.linaro.org/components/lava/sta... with 2017-7 and that works ok.
The various sections of the yaml file are as below and a comparison of the 2 boots are at http://paste.baserock.org/iyuzakogez , a lot more noise from the local one but 2016-12 was happy with that. Is there something I'm missing with the update that I need to change in this case?
ramdisk: # url: http://images.validation.linaro.org/snapshots.linaro.org/components/lava/sta... # locally built version url: http://localhost:8010/initramfs/initramfs-local.cpio.gz compression: gz add-header: u-boot
....
# BOOT_BLOCK - boot: method: u-boot commands: ramdisk prompts: - '(initramfs)' timeout: minutes: 2
On 6 September 2017 at 14:20, Robert Marshall robert.marshall@codethink.co.uk wrote:
Hi
I have a locally built initramfs which worked with a beaglebone black health check in LAVA 2016-12 but with version 2017-7 the health check is failing. I've tried using an initramfs from http://images.validation.linaro.org/snapshots.linaro.org/components/lava/sta... with 2017-7 and that works ok.
reboot comes from the soft-reboot support which is only active if you have no remote power control for the device. This support is only really useful for developers with devices on the desk, not for a CI instance of LAVA. It should certainly never be used for a health check. You need commands like https://staging.validation.linaro.org/scheduler/device/staging-black04/devic...
If you are going to use a device which is already running at the start of the job, you need to already login on the console which will be used by the test job itself. In your working version, you should never have seen beaglebone login: or "The programs included with the Debian GNU/Linux system are free software" within the test job.
Best solution here is to implement remote power control and then you'll get the behaviour on staging:
https://staging.validation.linaro.org/scheduler/job/187593
https://staging.validation.linaro.org/scheduler/job/187593#action_2-4
Also, it is generally much more useful to attach the complete logs with the device configuration instead of doing the comparison offline as that loses a lot of context.
Neil Williams neil.williams@linaro.org writes:
On 6 September 2017 at 14:20, Robert Marshall robert.marshall@codethink.co.uk wrote:
Hi
I have a locally built initramfs which worked with a beaglebone black health check in LAVA 2016-12 but with version 2017-7 the health check is failing. I've tried using an initramfs from http://images.validation.linaro.org/snapshots.linaro.org/components/lava/sta... with 2017-7 and that works ok.
reboot comes from the soft-reboot support which is only active if you have no remote power control for the device. This support is only really useful for developers with devices on the desk, not for a CI instance of LAVA.
We are using it for a device on desk installation of LAVA so maybe health check is the wrong term
It should certainly never be used for a health check. You need commands like https://staging.validation.linaro.org/scheduler/device/staging-black04/devic...
If you are going to use a device which is already running at the start of the job, you need to already login on the console which will be used by the test job itself. In your working version, you should never have seen beaglebone login: or "The programs included with the Debian GNU/Linux system are free software" within the test job.
We're using a device dictionary looking like
{% extends 'beaglebone-black.jinja2' %} {% set connection_command = '/vagrant/scripts/connectBBB.sh 10.24.3.102 8020 root password' %} {% set poweron_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command on' %} {% set poweroff_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command off' %} {% set reboot_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command reboot' %}
where connectBBB.sh scripts a login using expect
Best solution here is to implement remote power control and then you'll get the behaviour on staging:
https://staging.validation.linaro.org/scheduler/job/187593
https://staging.validation.linaro.org/scheduler/job/187593#action_2-4
Also, it is generally much more useful to attach the complete logs with the device configuration instead of doing the comparison offline as that loses a lot of context.
Apologies, here's the full output
http://paste.baserock.org/zikevanugi
Robert
On 6 September 2017 at 15:52, Robert Marshall robert.marshall@codethink.co.uk wrote:
Neil Williams neil.williams@linaro.org writes:
On 6 September 2017 at 14:20, Robert Marshall robert.marshall@codethink.co.uk wrote:
Hi
I have a locally built initramfs which worked with a beaglebone black health check in LAVA 2016-12 but with version 2017-7 the health check is failing. I've tried using an initramfs from http://images.validation.linaro.org/snapshots.linaro.org/components/lava/sta... with 2017-7 and that works ok.
reboot comes from the soft-reboot support which is only active if you have no remote power control for the device. This support is only really useful for developers with devices on the desk, not for a CI instance of LAVA.
We are using it for a device on desk installation of LAVA so maybe health check is the wrong term
It should certainly never be used for a health check. You need commands like https://staging.validation.linaro.org/scheduler/device/staging-black04/devic...
If you are going to use a device which is already running at the start of the job, you need to already login on the console which will be used by the test job itself. In your working version, you should never have seen beaglebone login: or "The programs included with the Debian GNU/Linux system are free software" within the test job.
We're using a device dictionary looking like
{% extends 'beaglebone-black.jinja2' %} {% set connection_command = '/vagrant/scripts/connectBBB.sh 10.24.3.102 8020 root password' %} {% set poweron_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command on' %} {% set poweroff_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command off' %} {% set reboot_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command reboot' %}
https://git.linaro.org/lava/lava-lab.git/plain/staging.validation.linaro.org...
It looks like you have typos in that device dictionary:
{% set hard_reset_command =
{% set power_off_command =
{% set power_on_command =
poweron_command and poweroff_command are meaningless.
where connectBBB.sh scripts a login using expect
Best solution here is to implement remote power control and then you'll get the behaviour on staging:
https://staging.validation.linaro.org/scheduler/job/187593
https://staging.validation.linaro.org/scheduler/job/187593#action_2-4
Also, it is generally much more useful to attach the complete logs with the device configuration instead of doing the comparison offline as that loses a lot of context.
Apologies, here's the full output
http://paste.baserock.org/zikevanugi
Robert _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
Neil Williams neil.williams@linaro.org writes:
On 6 September 2017 at 15:52, Robert Marshall robert.marshall@codethink.co.uk wrote:
Neil Williams neil.williams@linaro.org writes:
On 6 September 2017 at 14:20, Robert Marshall robert.marshall@codethink.co.uk wrote:
Hi
I have a locally built initramfs which worked with a beaglebone black health check in LAVA 2016-12 but with version 2017-7 the health check is failing. I've tried using an initramfs from http://images.validation.linaro.org/snapshots.linaro.org/components/lava/sta... with 2017-7 and that works ok.
reboot comes from the soft-reboot support which is only active if you have no remote power control for the device. This support is only really useful for developers with devices on the desk, not for a CI instance of LAVA.
We are using it for a device on desk installation of LAVA so maybe health check is the wrong term
It should certainly never be used for a health check. You need commands like https://staging.validation.linaro.org/scheduler/device/staging-black04/devic...
If you are going to use a device which is already running at the start of the job, you need to already login on the console which will be used by the test job itself. In your working version, you should never have seen beaglebone login: or "The programs included with the Debian GNU/Linux system are free software" within the test job.
We're using a device dictionary looking like
{% extends 'beaglebone-black.jinja2' %} {% set connection_command = '/vagrant/scripts/connectBBB.sh 10.24.3.102 8020 root password' %} {% set poweron_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command on' %} {% set poweroff_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command off' %} {% set reboot_command = 'pduclient --daemon 10.24.3.102 --hostname 127.0.0.1 --port 3 --command reboot' %}
https://git.linaro.org/lava/lava-lab.git/plain/staging.validation.linaro.org...
It looks like you have typos in that device dictionary:
{% set hard_reset_command =
{% set power_off_command =
{% set power_on_command =
poweron_command and poweroff_command are meaningless.
We've had those typos in the project for some time - thanks for pointing them out! I've now purged the device dictionary down to
{% extends 'beaglebone-black.jinja2' %} {% set connection_command = '/vagrant/scripts/connectBBB.sh 10.24.3.102 8020 root password' %}
which still exhibits the same issue - an initramfs downloaded from http://images.validation.linaro.org/snapshots.linaro.org runs ok but our locally built version again causes the same test to fail, I'll try allowing auto login with no password
where connectBBB.sh scripts a login using expect
Best solution here is to implement remote power control and then you'll get the behaviour on staging:
https://staging.validation.linaro.org/scheduler/job/187593
https://staging.validation.linaro.org/scheduler/job/187593#action_2-4
Also, it is generally much more useful to attach the complete logs with the device configuration instead of doing the comparison offline as that loses a lot of context.
Apologies, here's the full output
http://paste.baserock.org/zikevanugi
Robert _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
-
Neil Williams -
Robert Marshall