Hi,
message:
Add sudo so that the ifconfig command do not fail when
"lava-deployment-tool setup" is executed as non-privileged user.
I must not push because: I am not member of your team, I do not know what your
patch policy is and I am not sure the patch is right. That is because I am
sending the patch via email.
I will look at the rest of LAVA projects code in the next eight days. If you
have some task which you want to work out, please let me know it. I will carry
out it.
Regards
---
$ bzr diff -r209..208
=== modified file 'lava-deployment-tool'
--- lava-deployment-tool 2012-10-02 14:32:21 +0000
+++ lava-deployment-tool 2012-09-14 21:11:54 +0000
@@ -759,7 +759,7 @@
echo ""
echo "Here is the list of network device on this host"
- sudo ifconfig | grep 'Ethernet\|inet addr'
+ ifconfig | grep 'Ethernet\|inet addr'
while true; do
If you don't follow dispatcher commit or review mail, you might not be
aware than Andy and I have been working an implementation of the "black
box" tests we've been talking about for a while. This mail is just a
summary of the things that have been mentioned in review that would be
good to fix "in the next branch" so that we don't forget about them.
The list probably doesn't make a great deal of sense if you haven't read
the review mail, sorry about that.
In no particular order:
* explode if an android test has deps rather than trying to install
via apt-get
* need to have lava-test-runner be a proper service on android
* make power_off() == 'in the master image' consistently
* make cmd_android_install_binaries work for !master deployments
* think about suppressing the root shell on console on ubuntu
* remove separation between LavaClient and TargetBasedClient,
consider slimming (and renaming?) interface
* fix retreive_results return interface
* rename download_image
* look at how boot_options works
* define common target superclass for FastModelTarget and QEMUTarget
* set up automated dispatcher validation
I've just thought of one more thing, which is that running a
lava_test_shell action followed by a lava_test_run action in the same
job will likely not work well because the lava test shell test will be
run again when the lava_test_run action boots the image -- maybe the
lava-test-runner should clean up after itself so that the tests only run
on *the* next boot rather than every following boot? If we do do the
"disable auto-login-shell" action, then it should probably reenable that
too...
Cheers,
mwh
Hi again all,
Zen are still running tests and now I have to run more tests from our side. Because I'm off site tomorrow this won't happen until Wednesday. I'll keep you posted.
Thanks
Dave
Sent from my Aldis Lamp
Hi,
I've forgotten the status of this. We want to be able to do ad-hoc
testing of lava branches on a 'dogfood' server. "ssh dogfood" works in
the lab but the resulting instance does not appear to have LAVA
installed on it. Is this just waiting to be set up?
IIRC, the goal was not to have this host accessible from the internet,
rather we would use ssh port forwarding so we could point our local
browser at the remote hosts. In this case, there is not much point in
having dogfood.validation.linaro.org set up in the DNS (as there
currently is...).
If this is just stalled for lack of time, I can finish setting up the
instance.
Cheers,
mwh
Just when you thought things were going smoothly...
Since I got a connection to the leased line, I've been running occasional tests to see how it's performing, and the answer is "patchy". Download speed is mostly consistent, but I see drop offs once in a while, while upload speed is variable. Anything from 2Mbps to 9Mbps, and I see the odd dip where it cuts out completely.
I contacted Zen support yesterday morning and they've been having me run various tests which have now concluded in the fault being on their side of the router. They just this minute opened a support ticket for this, and will be trying to fix the problem remotely, hopefully before Monday. In the event that they can't, they will have to send an engineer out.
The upshot of this is that I may have to delay the switch over to the leased line until this is resolved.
Thanks
Dave
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi all,
Origen07 took itself offline because its ethernet interface appears to have died. I've looked at it, and it really does seem to be dead. This is the second such failure (Origen06 for the same reason). I'll investigate on this one, but we might be seeing a trend.
I'll let you know.
Dave
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
I noticed in the reports view, several jobs which have been stuck for a while:
http://validation.linaro.org/lava-server/scheduler/job/33203
-------------------------------------------------------------------------------
origen02
------------
A health check running for 4 days. Nothing in the log. I cancelled it, but it was stuck in cancelling. So I went into admin, put it offline, and then online to run a health check again. The job itself is still showing as not finished. How do I track it down on control so that we can kill it properly?
http://validation.linaro.org/lava-server/scheduler/job/33382
-------------------------------------------------------------------------------
origen04
------------
A regular job that failed, pushed its result bundle and then never quite stopped running. Same deal as 33203, but I can't get it to run its health check. Any clues?
http://validation.linaro.org/lava-server/scheduler/job/33372
-------------------------------------------------------------------------------
panda09
------------
Same as origen04 - can't get health check to run.
Dave
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On 09/27/2012 05:38 AM, Dave Pigott wrote:
> Hi Andy,
>
> I swapped out the two broken snowballs and put in two new ones and
> they've come up just fine. However, when I go to staging and try to run
> a health check on 10, Conmux gives a "Connection refused" message, which
> is really odd, since I can conmux-console snowball10 on control and
> everything is fine. The really weird thing is that I moved it over to
> production, and the test ran fine. Has something changed subtly on
> staging in the last 24 hours or so?
Ah - I should have warned you. I was worried the connection command I
configured wasn't permanent. I'll look into fixing this for good.
Sorry: I should have mentioned that in my first email
-andy
Hi all,
I Thought I'd let you know that we now have 5 more ST-Ericsson Snowball V11 PDKs in LAVA. They went live yesterday afternoon. In total we now have 10 snowballs but only 8 are available because one of them has been sidelined for staging, and another is not playing ball. I'm working on trying to understand if the board is just dead, or if there there is some other issue. At the moment it's not talking to the outside world at all. I'll keep you posted.
Thanks
Dave
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
----------------------------------------------------------------------
rtsm_ve-a15x4-a7x4_01 & rtsm_ve-a15x4-a7x4_02
----------------------------------------------------------------------
http://validation.linaro.org/lava-server/scheduler/job/33484/log_file
Classic problem, that I also had with the tc2s yesterday. The health check references a snapshot that no longer exists because it's fallen off the bottom.
Andy: I'll look and see if I can find a release that will work on FM. I'll let you know if I succeed (although it should be obvious by the "board" state).
Thanks
Dave
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
