Hi Michael,
I'm writing the test cases but now I have no idea how to make a test result
judgement in our LAVA system. You may receive my previous email about the
test case definition file (YAML) format, and according to my experiments, I
can only write the command line likes this:
lava-test-case botao-panda-es-ubuntu-test-uname --shell "ifconfig -a" ||
true
And then no matter what happened after the test command ran, above
expression will always return "True". So, in this condition, how to know it
actually passed or failed?
Thanks.
Best Regards
Botao Sun
Hi all,
http://validation.linaro.org/lava-server/scheduler/job/45124
This is on panda-es02. First of all, it ran out of space on root when trying to mv uInitrd to a tmp directory. It *then* reported that deploy-linaro-android-image had failed, and proceeded to try to boot android *anyway*. Looks like we've got a logic break there.
Looking on the board, it has indeed run out of space on the rootfs. Has anyone any idea why? Michael H-D this is the board you were doing audio testing on. Is this maybe a result of that?
Thanks
Dave
All,
I just got some shocking news that a good friend of mine died last night, and it's completely banjaxed me. As a consequence I'm a bit of a mess so this is a heads up that I won't be very effective today. Currently I'm the only one in the office, so I'll stay and do the things that have to be done, but I will be leaving early.
Arwen, can you let any delivery companies know?
Thanks
Dave
Hi all,
Looks like we have a requirement for a software controllable relay to physically press a reset switch on a board. I've been doing some hunting but so far have come up with nothing that looks likely.
Requirements:
Dimensions: At present unknown until we have a physical board in our hands
Mountable: It must be something we can attach to the shelf next to the board
Controllable: Must have some sort of standard interface for operation. USB would be a preference, but at a push we could use another board's GPIO pins.
Anyone know of such a product?
Thanks
Dave
Apologies if this mail is a little incomprehensible. I'm brain dumping
in a hurry :-)
The lava dispatcher currently communicates where the results it has
uploaded to the dashboard have ended up to the scheduler by having an
extra file descriptor open to the scheduler monitor process -- both
stdout and stderr are pretty messy and I didn't want to take the risk of
e.g. a boot message being mis-interpreted as structured data.
As well as being silly and over-engineered, this is implicated in my
debugging of the "jobs don't always exit properly" bug. So let's stop
using it.
What I'd like to do instead is add an --output-dir option to the
dispatcher, pass it from the scheduler, have the scheduler write the
location of the uploaded results to a known location in this output
directory. In fact, I've done this:
http://bazaar.launchpad.net/~mwhudson/lava-dispatcher/output-dir/revision/5…http://bazaar.launchpad.net/~mwhudson/lava-scheduler/use-dispatcher-output-…
Doesn't seem so bad really.
This fixed the immediate problem, but I want to go further: I want to
store more structured log output (filtering boot logs away, for example)
in this output directory and gradually teach the scheduler web bits how
to interpret this structured data.
Thoughts?
Cheers,
mwh
----------------
snowball07
----------------
http://validation.linaro.org/lava-server/scheduler/job/45171
Have annotated, but just want to report that something very odd happened. It looks like the test image was corrupted in some way. I went on the board and rebooted the test image, and it still had all the errors, although it did actually get to a command prompt. I've put it back on to re-test. If it isn't a dead sd card, then a re-attempt at booting may have fixed it, or possibly going back to deployment.
Thanks
Dave
Morning all,
Woke up this morning feeling worse than yesterday, and now my son has woken up feeling the same so I'll be at home today. Depending on how I feel I'll try and get some work done later.
Thanks
Dave
Sent from my Aldis Lamp
Hi all,
I'm going to have another go at upgrading LAVA to postgres 9.1 in about
43 hours time. Again, should be less than 10 minutes total downtime.
Let me know if this time will be super inconvenient for you.
Cheers,
mwh
PS: timezone cheat sheet as before:
* 10:00 on Thursday 17th in NZ
* 02:30 on Thursday 17th in Bangalore
* 21:00 on Wednesday 16th in the UK
* 16:00 on Wednesday 16th in Boston
* 13:00 on Wednesday 16th in California
