Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Thanks,
Josue
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa53123dc4f7d...
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?section=dep...
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
My NFS root does in fact have /bin/bash.
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa53123dc4f7d...
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?section=dep...
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job - without alterations - and *then* make one change at a time. That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa53123dc4f7d...
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?section=dep...
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
- Extracted nfsroot to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
- Preparing overlay tarball in /tmp/tmp4M64ls
Could this be the reason it is not finding the "/lava-<jobid>/bin/lava-test-runner " file.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job - without alterations - and *then* make one change at a time. That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa53123 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data.py#l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?secti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
On Tue, 19 Jul 2016 16:09:34 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
Extracted nfsroot to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
Preparing overlay tarball in /tmp/tmp4M64ls
The overlay tarball is built there but then unpacked later, into the NFS.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
If the NFS did not work, the test would not have got as far as starting the lava-test-shell.
If there is no ramdisk specified in the job, it is still part of the uboot commands, so may show file not found for that particular file.
As I've mentioned before, *please* start with the standard test job - without alterations - and *then* make one change at a time. That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job - without alterations - and *then* make one change at a time. That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa53123 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data.py#l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?secti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
--
Neil Williams
Alright, yes I saw that it unpacked successfully to the NFS root during a running job.
The only way I got it to work as far as starting the lava-test-shell was by using my u-boot commands to use my local NFS server. Now I reverted the base.jinja2 and beaglebone-black.jinja2 to the default and I'm trying to boot the board with the default nfs commands and it's giving me that error (TFTP error: file not found) with the zImage and dtb (I didn't specify any ramdisk). Any configuration I need to make outside of lava for the nfs and tftp servers? They are currently set up to work with the DHCP server I set up.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 1:26 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 16:09:34 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
Extracted nfsroot to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
Preparing overlay tarball in /tmp/tmp4M64ls
The overlay tarball is built there but then unpacked later, into the NFS.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
If the NFS did not work, the test would not have got as far as starting the lava-test-shell.
If there is no ramdisk specified in the job, it is still part of the uboot commands, so may show file not found for that particular file.
As I've mentioned before, *please* start with the standard test job - without alterations - and *then* make one change at a time. That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job - without alterations - and *then* make one change at a time. That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa531 23 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data.py #l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?sec ti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
--
Neil Williams
On Tue, 19 Jul 2016 19:02:26 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Alright, yes I saw that it unpacked successfully to the NFS root during a running job.
The only way I got it to work as far as starting the lava-test-shell was by using my u-boot commands to use my local NFS server. Now I reverted the base.jinja2 and beaglebone-black.jinja2 to the default and I'm trying to boot the board with the default nfs commands and it's giving me that error (TFTP error: file not found) with the zImage and dtb (I didn't specify any ramdisk). Any configuration I need to make outside of lava for the nfs and tftp servers? They are currently set up to work with the DHCP server I set up.
lava-dispatcher installs the necessary NFS support.
/etc/exports.d/lava-dispatcher-nfs.exports
tftp uses the configured root from /etc/default/tftpd-hpa
The dispatcher downloads the relevant files to the tftpd root.
From your log: 1.1.1-file_download.log downloading {'url': 'file:///tftpboot/zImage', 'yaml_line': 4} as /var/lib/lava/dispatcher/tmp/tmpWEWsTN/zImage
Check the configuration of tftpd-hpa - TFTP_DIRECTORY value.
Also check the status of tftpd-hpa itself. You may need to restart the tftpd-hpa daemon.
$ sudo service tftpd-hpa status
(If it's not running, you'll usually see TTTT in the output rather than file not found.)
If you're getting errors during boot, please pastebin the boot log too.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 1:26 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 16:09:34 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
- Extracted nfsroot
to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
- Preparing overlay tarball in /tmp/tmp4M64ls
The overlay tarball is built there but then unpacked later, into the NFS.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
If the NFS did not work, the test would not have got as far as starting the lava-test-shell.
If there is no ramdisk specified in the job, it is still part of the uboot commands, so may show file not found for that particular file.
As I've mentioned before, *please* start with the standard test job - without alterations - and *then* make one change at a time. That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa531 23 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data.py #l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?sec ti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
--
Neil Williams
--
Neil Williams
Thanks for the information, I think it helped a lot.
When I check the status as you said I get a failed error message:
jalbarran@debian:~$ sudo service tftpd-hpa status ● tftpd-hpa.service - LSB: HPA's tftp server Loaded: loaded (/etc/init.d/tftpd-hpa) Active: failed (Result: exit-code) since Tue 2016-07-19 14:50:17 CDT; 1min 2s ago Process: 10722 ExecStart=/etc/init.d/tftpd-hpa start (code=exited, status=1/FAILURE)
Jul 19 14:50:17 debian tftpd-hpa[10722]: Starting HPA's tftpd: in.tftpd Jul 19 14:50:17 debian systemd[1]: tftpd-hpa.service: control process exited, code=exited status=1 Jul 19 14:50:17 debian systemd[1]: Failed to start LSB: HPA's tftp server. Jul 19 14:50:17 debian systemd[1]: Unit tftpd-hpa.service entered failed state.
I have "/var/lib/lava/dispatcher/tmp/" in both the TFTP_DIRECTORY value of the tftpd-hpa configuration and in the "/etc/exports.d/lava-dispatcher-nfs.exports".
My boot log is as follows: http://pastebin.ubuntu.com/20079411/
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 2:36 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 19:02:26 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Alright, yes I saw that it unpacked successfully to the NFS root during a running job.
The only way I got it to work as far as starting the lava-test-shell was by using my u-boot commands to use my local NFS server. Now I reverted the base.jinja2 and beaglebone-black.jinja2 to the default and I'm trying to boot the board with the default nfs commands and it's giving me that error (TFTP error: file not found) with the zImage and dtb (I didn't specify any ramdisk). Any configuration I need to make outside of lava for the nfs and tftp servers? They are currently set up to work with the DHCP server I set up.
lava-dispatcher installs the necessary NFS support.
/etc/exports.d/lava-dispatcher-nfs.exports
tftp uses the configured root from /etc/default/tftpd-hpa
The dispatcher downloads the relevant files to the tftpd root.
From your log:
1.1.1-file_download.log downloading {'url': 'file:///tftpboot/zImage', 'yaml_line': 4} as /var/lib/lava/dispatcher/tmp/tmpWEWsTN/zImage
Check the configuration of tftpd-hpa - TFTP_DIRECTORY value.
Also check the status of tftpd-hpa itself. You may need to restart the tftpd-hpa daemon.
$ sudo service tftpd-hpa status
(If it's not running, you'll usually see TTTT in the output rather than file not found.)
If you're getting errors during boot, please pastebin the boot log too.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 1:26 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 16:09:34 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
- Extracted nfsroot
to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
- Preparing overlay tarball in /tmp/tmp4M64ls
The overlay tarball is built there but then unpacked later, into the NFS.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
If the NFS did not work, the test would not have got as far as starting the lava-test-shell.
If there is no ramdisk specified in the job, it is still part of the uboot commands, so may show file not found for that particular file.
As I've mentioned before, *please* start with the standard test job - without alterations - and *then* make one change at a time. That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa5 31 23 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data. py #l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?s ec ti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
--
Neil Williams
--
Neil Williams
On Tue, 19 Jul 2016 19:56:22 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Thanks for the information, I think it helped a lot.
When I check the status as you said I get a failed error message:
jalbarran@debian:~$ sudo service tftpd-hpa status ● tftpd-hpa.service - LSB: HPA's tftp server Loaded: loaded (/etc/init.d/tftpd-hpa) Active: failed (Result: exit-code) since Tue 2016-07-19 14:50:17 CDT; 1min 2s ago Process: 10722 ExecStart=/etc/init.d/tftpd-hpa start (code=exited, status=1/FAILURE)
OK, looks like we need to add a check that the service is running.
It can fail on my laptop when I lose network connectivity, something like that may be the problem on your system.
You should find something in /var/log/syslog
Jul 19 14:50:17 debian tftpd-hpa[10722]: Starting HPA's tftpd: in.tftpd Jul 19 14:50:17 debian systemd[1]: tftpd-hpa.service: control process exited, code=exited status=1 Jul 19 14:50:17 debian systemd[1]: Failed to start LSB: HPA's tftp server. Jul 19 14:50:17 debian systemd[1]: Unit tftpd-hpa.service entered failed state.
If you restart the service with 'sudo service tftpd-hpa restart', does the status show it as running? If so, the job should likely then work.
I have "/var/lib/lava/dispatcher/tmp/" in both the TFTP_DIRECTORY value of the tftpd-hpa configuration and in the "/etc/exports.d/lava-dispatcher-nfs.exports".
My boot log is as follows: http://pastebin.ubuntu.com/20079411/
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 2:36 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 19:02:26 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Alright, yes I saw that it unpacked successfully to the NFS root during a running job.
The only way I got it to work as far as starting the lava-test-shell was by using my u-boot commands to use my local NFS server. Now I reverted the base.jinja2 and beaglebone-black.jinja2 to the default and I'm trying to boot the board with the default nfs commands and it's giving me that error (TFTP error: file not found) with the zImage and dtb (I didn't specify any ramdisk). Any configuration I need to make outside of lava for the nfs and tftp servers? They are currently set up to work with the DHCP server I set up.
lava-dispatcher installs the necessary NFS support.
/etc/exports.d/lava-dispatcher-nfs.exports
tftp uses the configured root from /etc/default/tftpd-hpa
The dispatcher downloads the relevant files to the tftpd root.
From your log: 1.1.1-file_download.log downloading {'url': 'file:///tftpboot/zImage', 'yaml_line': 4} as /var/lib/lava/dispatcher/tmp/tmpWEWsTN/zImage
Check the configuration of tftpd-hpa - TFTP_DIRECTORY value.
Also check the status of tftpd-hpa itself. You may need to restart the tftpd-hpa daemon.
$ sudo service tftpd-hpa status
(If it's not running, you'll usually see TTTT in the output rather than file not found.)
If you're getting errors during boot, please pastebin the boot log too.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 1:26 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 16:09:34 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
- Extracted nfsroot
to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
- Preparing overlay tarball in /tmp/tmp4M64ls
The overlay tarball is built there but then unpacked later, into the NFS.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
If the NFS did not work, the test would not have got as far as starting the lava-test-shell.
If there is no ramdisk specified in the job, it is still part of the uboot commands, so may show file not found for that particular file.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ffa5 31 23 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data. py #l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log?s ec ti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
--
Neil Williams
--
Neil Williams
--
Neil Williams
OK, so I checked and I had tftpd installed and not tftpd-hpa. I went ahead and installed and now the status command returns the daemon as active and running.
I don't have the "TFTP error: file not found" error anymore but I now have the "T T T T T" error you said.
May this be because I'm behind a firewall?
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 3:15 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 19:56:22 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Thanks for the information, I think it helped a lot.
When I check the status as you said I get a failed error message:
jalbarran@debian:~$ sudo service tftpd-hpa status ● tftpd-hpa.service
- LSB: HPA's tftp server Loaded: loaded (/etc/init.d/tftpd-hpa) Active: failed (Result: exit-code) since Tue 2016-07-19 14:50:17
CDT; 1min 2s ago Process: 10722 ExecStart=/etc/init.d/tftpd-hpa start (code=exited, status=1/FAILURE)
OK, looks like we need to add a check that the service is running.
It can fail on my laptop when I lose network connectivity, something like that may be the problem on your system.
You should find something in /var/log/syslog
Jul 19 14:50:17 debian tftpd-hpa[10722]: Starting HPA's tftpd: in.tftpd Jul 19 14:50:17 debian systemd[1]: tftpd-hpa.service: control process exited, code=exited status=1 Jul 19 14:50:17 debian systemd[1]: Failed to start LSB: HPA's tftp server. Jul 19 14:50:17 debian systemd[1]: Unit tftpd-hpa.service entered failed state.
If you restart the service with 'sudo service tftpd-hpa restart', does the status show it as running? If so, the job should likely then work.
I have "/var/lib/lava/dispatcher/tmp/" in both the TFTP_DIRECTORY value of the tftpd-hpa configuration and in the "/etc/exports.d/lava-dispatcher-nfs.exports".
My boot log is as follows: http://pastebin.ubuntu.com/20079411/
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 2:36 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 19:02:26 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Alright, yes I saw that it unpacked successfully to the NFS root during a running job.
The only way I got it to work as far as starting the lava-test-shell was by using my u-boot commands to use my local NFS server. Now I reverted the base.jinja2 and beaglebone-black.jinja2 to the default and I'm trying to boot the board with the default nfs commands and it's giving me that error (TFTP error: file not found) with the zImage and dtb (I didn't specify any ramdisk). Any configuration I need to make outside of lava for the nfs and tftp servers? They are currently set up to work with the DHCP server I set up.
lava-dispatcher installs the necessary NFS support.
/etc/exports.d/lava-dispatcher-nfs.exports
tftp uses the configured root from /etc/default/tftpd-hpa
The dispatcher downloads the relevant files to the tftpd root.
From your log: 1.1.1-file_download.log downloading {'url': 'file:///tftpboot/zImage', 'yaml_line': 4} as /var/lib/lava/dispatcher/tmp/tmpWEWsTN/zImage
Check the configuration of tftpd-hpa - TFTP_DIRECTORY value.
Also check the status of tftpd-hpa itself. You may need to restart the tftpd-hpa daemon.
$ sudo service tftpd-hpa status
(If it's not running, you'll usually see TTTT in the output rather than file not found.)
If you're getting errors during boot, please pastebin the boot log too.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 1:26 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 16:09:34 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
- Extracted nfsroot
to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
- Preparing overlay tarball in /tmp/tmp4M64ls
The overlay tarball is built there but then unpacked later, into the NFS.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
If the NFS did not work, the test would not have got as far as starting the lava-test-shell.
If there is no ramdisk specified in the job, it is still part of the uboot commands, so may show file not found for that particular file.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ff a5 31 23 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data. py #l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log ?s ec ti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
--
Neil Williams
--
Neil Williams
--
Neil Williams
On Tue, 19 Jul 2016 20:39:04 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
OK, so I checked and I had tftpd installed and not tftpd-hpa. I went ahead and installed and now the status command returns the daemon as active and running.
That only happens if you have chosen not to install Recommended packages. Otherwise, lava-dispatcher will bring in tftpd-hpa.
I don't have the "TFTP error: file not found" error anymore but I now have the "T T T T T" error you said.
May this be because I'm behind a firewall?
tftp is local, it's just between the board and the dispatcher. There should not be any firewalls involved there.
You need to work out what is happening with tftpd-hpa here, there is little that LAVA can do from this point (at least for jobs which rely on tftp).
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 3:15 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 19:56:22 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Thanks for the information, I think it helped a lot.
When I check the status as you said I get a failed error message:
jalbarran@debian:~$ sudo service tftpd-hpa status ● tftpd-hpa.service
- LSB: HPA's tftp server Loaded: loaded (/etc/init.d/tftpd-hpa) Active: failed (Result: exit-code) since Tue 2016-07-19 14:50:17
CDT; 1min 2s ago Process: 10722 ExecStart=/etc/init.d/tftpd-hpa start (code=exited, status=1/FAILURE)
OK, looks like we need to add a check that the service is running.
It can fail on my laptop when I lose network connectivity, something like that may be the problem on your system.
You should find something in /var/log/syslog
Jul 19 14:50:17 debian tftpd-hpa[10722]: Starting HPA's tftpd: in.tftpd Jul 19 14:50:17 debian systemd[1]: tftpd-hpa.service: control process exited, code=exited status=1 Jul 19 14:50:17 debian systemd[1]: Failed to start LSB: HPA's tftp server. Jul 19 14:50:17 debian systemd[1]: Unit tftpd-hpa.service entered failed state.
If you restart the service with 'sudo service tftpd-hpa restart', does the status show it as running? If so, the job should likely then work.
I have "/var/lib/lava/dispatcher/tmp/" in both the TFTP_DIRECTORY value of the tftpd-hpa configuration and in the "/etc/exports.d/lava-dispatcher-nfs.exports".
My boot log is as follows: http://pastebin.ubuntu.com/20079411/
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 2:36 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 19:02:26 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Alright, yes I saw that it unpacked successfully to the NFS root during a running job.
The only way I got it to work as far as starting the lava-test-shell was by using my u-boot commands to use my local NFS server. Now I reverted the base.jinja2 and beaglebone-black.jinja2 to the default and I'm trying to boot the board with the default nfs commands and it's giving me that error (TFTP error: file not found) with the zImage and dtb (I didn't specify any ramdisk). Any configuration I need to make outside of lava for the nfs and tftp servers? They are currently set up to work with the DHCP server I set up.
lava-dispatcher installs the necessary NFS support.
/etc/exports.d/lava-dispatcher-nfs.exports
tftp uses the configured root from /etc/default/tftpd-hpa
The dispatcher downloads the relevant files to the tftpd root.
From your log: 1.1.1-file_download.log downloading {'url': 'file:///tftpboot/zImage', 'yaml_line': 4} as /var/lib/lava/dispatcher/tmp/tmpWEWsTN/zImage
Check the configuration of tftpd-hpa - TFTP_DIRECTORY value.
Also check the status of tftpd-hpa itself. You may need to restart the tftpd-hpa daemon.
$ sudo service tftpd-hpa status
(If it's not running, you'll usually see TTTT in the output rather than file not found.)
If you're getting errors during boot, please pastebin the boot log too.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 1:26 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 16:09:34 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
- Extracted nfsroot
to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
- Preparing overlay tarball in /tmp/tmp4M64ls
The overlay tarball is built there but then unpacked later, into the NFS.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
If the NFS did not work, the test would not have got as far as starting the lava-test-shell.
If there is no ramdisk specified in the job, it is still part of the uboot commands, so may show file not found for that particular file.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ff a5 31 23 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data. py #l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log ?s ec ti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
--
Neil Williams
--
Neil Williams
--
Neil Williams
--
Neil Williams
Thanks Neil, I figured it out and it had something to do with the ip's.
You said that to use a script within a test definition I should have this in my test definition:
run: deps: - wget steps: - wget http://example.com/my-script.sh - chmod 755 ./my-script.sh - ./my-script.sh arguments
But this is for inline if I'm correct. How would I do if I have the script in the same git repository where the test definition is?
Thanks,
Josue
-----Original Message----- From: Albarran, Josue Sent: Tuesday, July 19, 2016 3:39 PM To: 'Neil Williams' Cc: linaro-validation@lists.linaro.org Subject: RE: [Linaro-validation] lava-test-case
OK, so I checked and I had tftpd installed and not tftpd-hpa. I went ahead and installed and now the status command returns the daemon as active and running.
I don't have the "TFTP error: file not found" error anymore but I now have the "T T T T T" error you said.
May this be because I'm behind a firewall?
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 3:15 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 19:56:22 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Thanks for the information, I think it helped a lot.
When I check the status as you said I get a failed error message:
jalbarran@debian:~$ sudo service tftpd-hpa status ● tftpd-hpa.service
- LSB: HPA's tftp server Loaded: loaded (/etc/init.d/tftpd-hpa) Active: failed (Result: exit-code) since Tue 2016-07-19 14:50:17
CDT; 1min 2s ago Process: 10722 ExecStart=/etc/init.d/tftpd-hpa start (code=exited, status=1/FAILURE)
OK, looks like we need to add a check that the service is running.
It can fail on my laptop when I lose network connectivity, something like that may be the problem on your system.
You should find something in /var/log/syslog
Jul 19 14:50:17 debian tftpd-hpa[10722]: Starting HPA's tftpd: in.tftpd Jul 19 14:50:17 debian systemd[1]: tftpd-hpa.service: control process exited, code=exited status=1 Jul 19 14:50:17 debian systemd[1]: Failed to start LSB: HPA's tftp server. Jul 19 14:50:17 debian systemd[1]: Unit tftpd-hpa.service entered failed state.
If you restart the service with 'sudo service tftpd-hpa restart', does the status show it as running? If so, the job should likely then work.
I have "/var/lib/lava/dispatcher/tmp/" in both the TFTP_DIRECTORY value of the tftpd-hpa configuration and in the "/etc/exports.d/lava-dispatcher-nfs.exports".
My boot log is as follows: http://pastebin.ubuntu.com/20079411/
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 2:36 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 19:02:26 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Alright, yes I saw that it unpacked successfully to the NFS root during a running job.
The only way I got it to work as far as starting the lava-test-shell was by using my u-boot commands to use my local NFS server. Now I reverted the base.jinja2 and beaglebone-black.jinja2 to the default and I'm trying to boot the board with the default nfs commands and it's giving me that error (TFTP error: file not found) with the zImage and dtb (I didn't specify any ramdisk). Any configuration I need to make outside of lava for the nfs and tftp servers? They are currently set up to work with the DHCP server I set up.
lava-dispatcher installs the necessary NFS support.
/etc/exports.d/lava-dispatcher-nfs.exports
tftp uses the configured root from /etc/default/tftpd-hpa
The dispatcher downloads the relevant files to the tftpd root.
From your log: 1.1.1-file_download.log downloading {'url': 'file:///tftpboot/zImage', 'yaml_line': 4} as /var/lib/lava/dispatcher/tmp/tmpWEWsTN/zImage
Check the configuration of tftpd-hpa - TFTP_DIRECTORY value.
Also check the status of tftpd-hpa itself. You may need to restart the tftpd-hpa daemon.
$ sudo service tftpd-hpa status
(If it's not running, you'll usually see TTTT in the output rather than file not found.)
If you're getting errors during boot, please pastebin the boot log too.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Tuesday, July 19, 2016 1:26 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Tue, 19 Jul 2016 16:09:34 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Ok, thanks.
So the overlay goes into the directory /lava-<jobid> inside the NFS root, but in my log it shows it's going elsewhere.
I have this from the deploy section in the job log:
- zImage downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/zImage
- dtb downloads
to: /var/lib/lava/dispatcher/tmp/tmpAdhvGl/am335x-boneblack.dtb
- Extracted nfsroot
to /var/lib/lava/dispatcher/tmp/tmpUXT6LB
- Preparing overlay tarball in /tmp/tmp4M64ls
The overlay tarball is built there but then unpacked later, into the NFS.
I also see that my nfs root server ip is the one on my network. Should it be the DHCP server ip address instead?
I get TFTP error: 'File not found' that's why I'm asking about the server ip because I find it strange.
If the NFS did not work, the test would not have got as far as starting the lava-test-shell.
If there is no ramdisk specified in the job, it is still part of the uboot commands, so may show file not found for that particular file.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
Regards,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 2:44 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 19:22:31 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
My NFS root does in fact have /bin/bash.
OK, that should be fine - as long as unpacking the NFS using tar -xzf does produce ./bin/bash, not ./somedirectory/bin/bash
Could you please clarify the lava test running process? Lava is sending this command "/lava-188/bin/lava-test-runner /lava-188" to the board shell itself.
Exactly. LAVA is using the serial console to issue commands.
The overlay is put into a directory called /lava-<jobid> inside the NFS root.
The overlay contains a lava-test-runner script which takes the directory as the argument.
The script is built from the data in the overlay.
The overlay itself will exist (temporarily) in your /tmp/ location. e.g. for job 9999 /tmp/lava-dispatcher/slave/9999/logs/
You can see the files in that using tar -tzf.
There's also an err file in the directory above.
As I've mentioned before, *please* start with the standard test job
- without alterations - and *then* make one change at a time.
That's why we've prepared standard jobs like this. e.g. use the standard kernel, modules & dtb with your NFS and your kernel & dtb with the standard NFS. Do each of those changes with the standard test definition, then substitute in your own. You can also sign up for a linaro account and request permission to submit jobs to staging.validation.linaro.org which is running the release candidate for 2016.7 and may be easier to follow in the logs. Using staging also means that others can check the actual files you are using and everyone is looking at the same log files.
This http://pastebin.ubuntu.com/19938573/ is the deploy stage of the complete log.
Thanks,
Josue
-----Original Message----- From: Neil Williams [mailto:codehelp@debian.org] Sent: Monday, July 18, 2016 1:53 PM To: Albarran, Josue Cc: linaro-validation@lists.linaro.org Subject: Re: [Linaro-validation] lava-test-case
On Mon, 18 Jul 2016 15:33:33 +0000 "Albarran, Josue" j-albarran@ti.com wrote:
Hi,
I'm trying to run a simple lava-test-case from a test definition I defined and I get the "lava-test-shell timed out" error message.
This is just a message showing the length of the current timeout: lava-test-shell.log test shell timeout: 300 seconds
So, it's not a timeout, there is a missing file:
/lava-188/bin/lava-test-runner: No such file or directory
Shell can be awkward with these errors - is it possible that your NFS root lacks /bin/bash ?
The interpreter to use is dictated by the deployment_data: https://git.linaro.org/lava/lava-dispatcher.git/blob/3377ef1c8ff a5 31 23 dc4f7d7cdf1a5582c0d0797:/lava_dispatcher/pipeline/deployment_data. py #l 107
You've specified debian, so /bin/bash needs to exist. If your image is not actually debian, you should specify oe for OpenEmbedded which looks for /bin/sh
Is there something I'm missing here? I'm attaching the job definition, test definition, and test log.
Job definition: http://pastebin.ubuntu.com/19906000/ Test definition: http://pastebin.ubuntu.com/19906153/ Test log: http://pastebin.ubuntu.com/19904627/
Is that just the summary log? There will be more information in the Complete Log, especially the deploy stage.
Compare with this job: https://validation.linaro.org/scheduler/job/1019247/complete_log ?s ec ti on=deploy
Test definition: http://pastebin.ubuntu.com/19906153/
The quotes are unnecessary in the first line.
--
Neil Williams
--
Neil Williams
--
Neil Williams
--
Neil Williams
linaro-validation@lists.linaro.org
-
Albarran, Josue -
Neil Williams