panda-es01 is failing health jobs because uboot seems to have died (it
just starts again and again never getting to the prompt). I guess we
should try in order:
1) reflashing the card
2) trying a new card
3) replacing the board itself
in order?
Cheers,
mwh
This should be set in all our builds. It disables the first boot
wizard and the lockscreen (among other things I'm still looking into).
There also seems to be a nifty little way to do this using the Trade
Federation stuff, which I've just started looking at.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
There will be a short (around 10 minutes) LAVA downtime this weekend to
allow us to upgrade the version of postgresql we are running. During
this time LAVA will be inaccessible and and jobs submitted will
unfortunately be lost. Apologies for any inconvenience this will cause.
Cheers,
mwh
PS: Timezone cheat sheet: the downtime is at:
* 11:00 on Monday 14th in NZ
* 03:30 on Monday 14th in Bangalore
* 22:00 on Sunday 13th in the UK
* 17:00 on Sunday 13th in Boston
* 14:00 on Sunday 13th in California
Hi all,
I'm purchasing a dedicated server for the new dispatcher work, and also getting a USB sound card, as discussed at Connect. I'm looking for guidance as to functionality - a link to amazon would be quite helpful. :)
Any suggestions welcome.
Thanks
Dave
------------
panda04
------------
http://validation.linaro.org/lava-server/scheduler/job/44543
Odd one. Booted Android, tried to bring up eth0, which it seems to have done, and then Android hung. Put back to re-test
Also, I notice that we seem to have added a special case for health jobs so they ignore the home screen not coming up. Is this wise? It means that we don't run normal tests in the same way that we run health checks. The whole point of getting health checks to run to completion is that we have a high level of confidence that when a normal job fails it is because of a problem with the job, not with lava.
----------------
snowball06
----------------
http://validation.linaro.org/lava-server/scheduler/job/44580
Board locked up in test image. Another +1 for doing the reboot logic on test images as well as masters.
Thanks
Dave
Hey Dave,
Spent a little time trying to spin up an instance for fastmodels02 this
evening. I can't get openstack to do it, and don't really know where to
even look to understand why it fails.
I think we should have enough memory and such based on my reading.
Anyway - if you can get a fresh image up it would be great. If you could
do it and pass this text of this pastebin as its "userdata"
http://paste.ubuntu.com/1515709/
I think we'll have one pre-installed with salt. Which would mean, I'd
have very little do to after that to have it completely up and running
in LAVA again.
thanks,
Hello,
This milestone is last in series of 3 to add LAVA integration for
CBuild. In anticipation of delays and waits for deployment,
mid-December we made an optimistic plan to target to request
deployment in the beginning of this milestone. We didn't finish as much
as we wanted, but there're 2 main points: 1) we made all changes in a
way to preserve original CBuild native builds; 2) the core
functionality is done and proved working well on a sandbox.
So, we would like to follow original plan and set on deployment process
for the changes, in anticipation that we may need to do incremental
rollout (another point easy to forget is that TCWG has earlier
deadline, so there's no "good" time for deployment, and starting it
early is good way to avoid procrastination).
So, we would like to propose following plan:
1. Infra stabilizes current changes (level of functionality: manual
scheduling of builds in LAVA). We already started this, as the changes
spread around several bzr repos, we using Launchpad's great Merge
Request functionality. It's Infra-only first stage review though, feel
free to ignore it.
2. We submit 2nd-stage MR for TCWG and LAVA teams to review. ETA is
beginning of the next week.
3. Once review is passed (hopefully within a week or shorter), we
schedule a date for merging and deployment, subject to constraint of
TCWG release schedule.
4. We appoint team which will do deployment, Infra engineers have
access to cbuild.validation.linaro.org, so we can gladly work on that,
making sure we can rollback to the currently running version easily.
5. We invite stakeholders to do manual builds in LAVA.
6. As remaining functionality is developed (UI tweaks, support for
advanced functionality requiring automated access to build logs), they
are deployed in similar manner.
7. Automated builds (dailies, MR CI builds, etc.) are configured to run
on LAVA in parallel to native CBuild.
This last point is what we can realistically and reasonably deliver by
the end of this milestone, which will enable us to review functionality
and stability of LAVA builds, work on resolving remaining
infrastructural issues (like stability of build image), assess LAVA
capacity, and overall prepare plans for migrating to LAVA as the main
build platform for CBuild.
Please let me know how this plan looks.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
