linaro-validation June 2013

linaro-validation@lists.linaro.org

13 participants
10 discussions

Re: [Linaro-validation] "android_install_binaries" failure after "deploy_linaro_android_image"

by Leo Wu

Hi Tyler: Thanks your information, it is useful. For current status, i can pass "android_install_binaries" but getting stuck in "boot_linaro_android_image". I think the problem is still relevant to panda-driver. This web have four files about pandaboard driver you posted( https://developers.google.com/android/nexus/drivers) 20111114 20111216 20120430 20120807 i dont know which one is suitable for my pandaboard so i have tried everyone. There have no one can pass "boot_linaro_android_image". The Log as following... LOG: 20111114: [ 521.131805] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. [4812, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 521.202728] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. [4812, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 521.552642] init: untracked pid 3766 exited [ 521.626464] init: untracked pid 3762 exited LEO COMMENT: PVR_K error. Does this driver not suitable for my pandaboard? 20111216 linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 37.700134] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. [4812, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 38.766967] init: untracked pid 1771 exited [ 41.124938] init: untracked pid 1774 exited LEO COMMENT: It looks like same as 20111114. 20120430: <LAVA_DISPATCHER>2013-03-27 02:30:45 PM DEBUG: expect (1800): '['Displayed com.android.launcher/com.android.launcher2.Launcher:']' logcat -s ActivityManager:I --------- beginning of /dev/log/main --------- beginning of /dev/log/system [ 96.093536] warning: `zygote' uses 32-bit capabilities (legacy support in use) I/ActivityManager( 1776): Memory class: 48 I/ActivityManager( 1776): Enabled StrictMode logging for AThread's Looper LEO COMMENT: No error message on this version. But it hang up and no more message print out. No console command line when i click "enter" key. 20120807: [ 53.677490] PVR_K:(Error): BridgedDispatchKM: Driver initialisation not completed yet. [4836, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 53.737884] PVR_K:(Error): BridgedDispatchKM: Driver initialisation not completed yet. [4836, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 54.163696] init: untracked pid 1781 exited [ 55.792907] init: untracked pid 1784 exited LEO COMMENT: It looks like same as 20111114. One thing need to be mentiond, there have no "pvrsrvinit" but "pvrsrvctl" in version 20120807. Both files are same? LEO On 26 March 2013 20:57, Tyler Baker <tyler.baker(a)linaro.org> wrote: > Hi Leo Wu, > > The "android_install_binaries" dispatcher command will download, unpack, > and deploy proprietary shared objects to the Android file system. > > You can get these binaries from here: > https://developers.google.com/android/nexus/drivers - Choose the correct > binaries based on your Android build target. > > You will then have to create the following directory structure and tgz it: > > ./bin: > pvrsrvinit > > ./vendor: > lib > > ./vendor/lib: > egl hw libglslcompiler.so libIMGegl.so libpvr2d.so > libpvrANDROID_WSEGL.so libPVRScopeServices.so libsrv_init.so > libsrv_um.so libusc.so > > ./vendor/lib/egl: > libEGL_POWERVR_SGX540_120.so libGLESv1_CM_POWERVR_SGX540_120.so > libGLESv2_POWERVR_SGX540_120.so > > ./vendor/lib/hw: > gralloc.omap4.so > > At this point you have created your own panda-driver.tgz > > Now you will need to host it on a web server/file system that your LAVA > server can access. > > For instance, my LAVA server has the following defined: > > android_binary_drivers = http://192.168.1.2/panda-drivers.tgz <-- You > have to host this URL > > Hopefully this clears up any confusion you may have. Thanks. > > > > > > > On 26 March 2013 02:15, Leo Wu <leo.wu(a)linaro.org> wrote: > >> hi: >> Does anyone knows how to use "android_install_binaries" command in json >> file? Please give me some suggestion. >> I am trying to perfome lava android test on pandaboard. Currently, i face >> a problem while json file execute "android_install_binaries". >> The log shows it tries to connect to >> http://192.168.1.21/LAVA_HTTP/android-binaries/panda-drivers.tgz. >> >> log: http://192.168.1.21/LAVA_HTTP/android-binaries/panda-drivers.tgz Connecting >> to 192.168.1.21:80... failed:Connection timed out. >> RuntimeError: Extracting >> http://192.168.1.21/LAVA_HTTP/android-binaries/panda-drivers.tgz on >> target failed >> >> LAVA SERVER IP: 222.222.222.4 >> Board: pandaboard >> Master Image: Linaro PreBuild Image >> Test Image: LEB android >> >> >> 1. My LAVA SERVER ip is 222.222.222.4. i confused that why it tries to >> connect to 192.168.1.21? >> 2. what is panda-drivers.tgz? is it exist in lava server already or i >> need to download panda-drivers.tgz from somewhere by manual and stored it >> in local at first? >> 3. how to configure it? >> >> Thank you >> Leo >> >> _______________________________________________ >> linaro-validation mailing list >> linaro-validation(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-validation >> >> > > > -- > Tyler Baker > Technical Architect, Automation & CI > Linaro.org | Open source software for ARM SoCs > Follow Linaro: http://www.facebook.com/pages/Linaro > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog >

10 years, 7 months

lava-test-shell error preventing results bundle being uploaded to dashboard...

by Basil Eljuse

Hello, Recently we upgraded to latest version of LAVA and initially hit 'deserialisation error' when the bundle was uploaded which was tracked down to mismatched component when the upgrade happened. However currently i am seeing a new problem w.r.t lava test shell. It executes the tests successfully but at the point when it is uploading the results root@master [rc=0]# <LAVA_DISPATCHER>2013-06-27 04:43:51 PM WARNING: [ACTION-E] lava_test_shell is finished with error (ValidationError: Object has incorrect type (expected string) object_expr='object.test_runs[0].testdef_metadata.description', schema_expr='schema.properties.test_runs.items.properties.testdef_metadata.properties.description.type')). <LAVA_DISPATCHER>2013-06-27 04:43:51 PM INFO: Submitting the test result with parameters = {u'token': '<HIDDEN>', u'stream': u'/public/personal/pdsw-power/biglittle/', u'server': u'http://pdsw-power@pdsw-lava.cambridge.arm.com/RPC2/'} <LAVA_DISPATCHER>2013-06-27 04:43:51 PM ERROR: Error adding host result bundle /tmp/tmp3DQ2UQ/lava-test-shelliGO1yb.bundle Traceback (most recent call last): File "/srv/lava/.cache/branch-cache/lava-dispatcher/checkouts/630-tyler.baker@linaro.org-20130621154844-16xazyrnqfl2egzj/lava_dispatcher/actions/launch_control.py", line 159, in _get_results_from_host doc = DocumentIO.load(f)[1] File "/srv/lava/.cache/branch-cache/linaro-dashboard-bundle/checkouts/78-senthil.kumaran(a)linaro.org-20130502132750-h71xwobmsrjuc7gj/linaro_dashboard_bundle/io.py", line 123, in load doc = json.load(stream, parse_float=decimal.Decimal, object_pairs_hook=object_pairs_hook) File "/srv/lava/.cache/eggs/simplejson-2.4.0-py2.7-linux-x86_64.egg/simplejson/__init__.py", line 372, in load use_decimal=use_decimal, **kw) File "/srv/lava/.cache/eggs/simplejson-2.4.0-py2.7-linux-x86_64.egg/simplejson/__init__.py", line 445, in loads return cls(encoding=encoding, **kw).decode(s) File "/srv/lava/.cache/eggs/simplejson-2.4.0-py2.7-linux-x86_64.egg/simplejson/decoder.py", line 402, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/srv/lava/.cache/eggs/simplejson-2.4.0-py2.7-linux-x86_64.egg/simplejson/decoder.py", line 420, in raw_decode raise JSONDecodeError("No JSON object could be decoded", s, idx) JSONDecodeError: No JSON object could be decoded: line 1 column 0 (char 0) <LAVA_DISPATCHER>2013-06-27 04:43:52 PM INFO: Dashboard : http://pdsw-lava.cambridge.arm.com/dashboard/permalink/bundle/81916525dc8cc… My yaml file has the following contents ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ metadata: name: schedulertests version: 1.0 format: "Lava-Test-Shell Test Definition 1.0" run: steps: - "wget http://10.1.103.173/downloads/personal/CIjobs/testsuites/buildoutput-jenkin…" - "tar -xvzf buildoutput-jenkins-BLSreleasetests-scheduler_testsmanualtrigger-125_13.06_preLEB.tar.gz" - "cd buildoutput" - "./executeFTS.sh" - "lava-test-run-attach buildoutput_withresults.tar.gz application/x-gzip2" parse: pattern: "(?P<test_case_id>\\S+).+(?P<result>(succeeded|failed|deprecated|pass|fail))" fixupdict: succeeded: pass failed: fail deprecated: skip ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ Was there any changes for the yaml file that is needed now? Thanks Basil Eljuse... -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

10 years, 10 months

[ANN] android-build.linaro.org upgrade to Linaro Login Service

by Paul Sokolovsky

Hello, With Android releases out, I'd like to proceed with switchover of Android Build frontend authenticaton to Linaro Login. Estimated downtime is 2hrs. To minimize impact, I'm scheduling this for later evening UTC (around 8pm UTC). Let me know if you need access to a-b at that time (otherwise, upgrade is OKed by Vishal). -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

10 years, 10 months

lab arndale mac/ip addresses

by Michael Hudson-Doyle

Hi, I'm trying to use the arndales in the lab for some benchmarking and hitting a strange problem: when I boot an arndale into a test image, eth0 seems to get the same MAC address each time, which is also the same MAC address as tcarndale. This means it gets the same IP address from DHCP and then of course nothing really works right. Am I doing something wrong? Is arndale networking just a bit funny? Cheers, mwh

10 years, 10 months

pm-qa launcher script for LAVA....

by Basil Eljuse

Hi Naresh / Senthil, Wonder if you could help me here with the question on pm-qa execution on LAVA. I was using the pm-qa launcher script which was part of https://launchpad.net/lava-android-test/trunk/2013.01/+download/lava-androi… Attaching the same for your reference. Since the latest LEBs do have pm-qa overlayed to /data/benchmark/pm-qa instead of /system/xbin.pm-qa i modified the pm-qa launcher script locally. However with the modified launcher script i do get some failures. Attaching the log output also for your reference. I am suspecting that i can no longer use the pm-qa launcher script from the above link as is. Any idea what launcher script i should use from LAVA for pm-qa? Thanks Basil Eljuse... -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

10 years, 10 months

Review of django-crowd-rest-backend-linaro

by Paul Sokolovsky

Hello, Working on http://cards.linaro.org/browse/LAVA-109, I've forked the best matching Django backend for Crowd to add groups support as we need. I've finished adding new functionality and first round of testing, and appreciate a review. The changes can be found at https://git.linaro.org/gitweb?p=people/pfalcon/django-crowd-rest-backend-li… (Original project is hosted in hg, and I used recently discussed "git clone hg::<url>" syntax to clone to git. As you can see it didn't work ideally - original committer was imported as "Unknown". I didn't yet look into that issue, hints are welcome). -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

10 years, 10 months

Calxeda02 nodes

by Dave Pigott

Hi all, Now that we've replaced the faulty node in calxeda02, something else has happened. Namely, the mac addresses of the four nodes on that one card will be different. Can someone do an inspect of nodes 8, 9, 10 and 11 and give me the mac addresses so I can re-assign their ip addresses with dhcp? Thanks Dave

10 years, 10 months

Re: [Linaro-validation] New publishing infra prototype report

by Paul Sokolovsky

On Wed, 29 May 2013 17:11:11 +0100 James Tunnicliffe <james.tunnicliffe(a)linaro.org> wrote: > Issues raised in > http://bazaar.launchpad.net/~linaro-automation/linaro-android-build-tools/t… > > Getting a token: > I see this as the service that starts the job has some secret allowing > it to request the token, which is then passed onto the job. Yes, just like that: we have fixed (and thus trusted) job scheduler, which can reliably authenticate itself to a token server, get a token and pass that token to a much less trusted builder. > This may > require a Jenkins plugin. Yes, that's one possibility, as line 94 of the doc you quote says. Another possibility is to have extra frontend on top of Jenkins, which would request a token and inject it into Jenkins job (as a paremeter during start). That's possible right away with android-build and would be possible with other Jenkins with original ci-frontend plan. > > Open Embedded Builds/rsync: > This is not required. OE has a list of package sources and versions > associated with each build so we should be able to write a simple > "upload packages if that version doesn't exist" script. This probably > requires us to host files in openembedded/sources/<package > name>/<version>/<package file>, but that is a simple enough change. James, for me, what you said translates into something "let's dig into adhoc peculiarities of one usecase, because it seems that it's easy to handle that, as if we don't know that it the end it still won't be that easy, but the result will not be reusable". Nope, let's shoot for general solution of problem of publishing arbitrary file sets. That's also "easy". The hardest part of that is to accept that we'll duplicate best-practice solution (rsync) and by duplicating it, we'll lose extra features like intra-file optimizations (because *that* we for sure don't want to duplicate). That's why I'd like who anyone has strong reasons for going with rsync is come up with them before we decide on architecture (keeping in mind that rsync comes with friends like ssh, LDAP, PAM, Kerberos, etc.) > > publish --token=<token> --type=<build_type> --strip=<strip> <build_id> > <glob_pattern>... > > This seems like a reasonable starting point. Lets make sure that it > uses a configuration file to specify what to do with those build types > etc. Preferably one that it can update from a public location so we > don't have to re-spin the tool to add a new build type (though I guess > we normally check it out of VCS as we go, so that works too). Well, on client side, it's ideally just a single file which just handle obvious filtering options (like <glob_pattern> or --strip=) locally and passes the rest to API/service. Server-side can handle the options in any way it wants, note that options above don't require much "configuration", for example --type= just maps to top-level download dir. Except for, well, we already have adhoc behavioral idiosyncrasies, like Android builds flattening happening on server. You hardly can "configure" that (though lambdas in YAML sounds cool (for debugging :-D)). Better approach would be to move that stuff to client side and have simple well-defined publishing semantics. > > James > > On 29 May 2013 16:57, James Tunnicliffe > <james.tunnicliffe(a)linaro.org> wrote: > > Hi Paul, > > > > Thanks for this. I need a mechanism for publishing from CI runtime > > jobs so this is important to me. I did look into using SSH/SFTP and > > it is simple to do in a reasonably insecure way, it would be much > > better to have an HTTP[S] based solution that uses temporary > > authentication tokens. > > > > I was looking at this today because I woke up early worrying about > > it. Clearly I need more interesting stuff to think about! (and now, > > more sleep). > > > > Anyway, it should be possible to do in Django: > > > > https://docs.djangoproject.com/en/dev/topics/http/file-uploads/ > > https://pypi.python.org/pypi/django-transfer/0.2-2 > > http://wiki.nginx.org/HttpUploadModule > > > > My own notes are more focused on an internal server that would > > upload files to releases/snapshots but could retain files until > > disk space was needed to act as a cache. I was going to look at > > extending linaro-licenese-protection for this so there was no way > > to use the cache to avoid licenses. I was also going to have > > completely private files that you could only access if you had the > > authentication token that a job was given. > > > > https://docs.google.com/a/linaro.org/document/d/1_ewb-xFDJc8Adk7AijV95XthGM… > > > > Feel free to add comments or insert more information and thoughts. > > > > Note that for high performance uploads we probably want to hand off > > the upload to a web server. That django-transfer module doesn't > > support any Apache related upload stuff, which may mean that it > > doesn't exist. Moving to an nginx based solution would be easy > > enough if we needed to (we could replace the mod-xsendfile with the > > equivalent nginx call). > > > > I think a prototype branch is ~1 day of engineering effort (no > > nginx, token based upload call in place, probably some kind of > > token request call, probably limited security, no > > proxy-publishing). Adding the rest of the features, testing etc > > probably takes it to more like 1 week. > > > > James > > > > > > On 29 May 2013 16:26, Paul Sokolovsky <paul.sokolovsky(a)linaro.org> > > wrote: > >> > >> > >> Begin forwarded message: > >> > >> Date: Wed, 29 May 2013 17:19:31 +0300 > >> From: Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> > >> To: Tyler Baker <tyler.baker(a)linaro.org>, Alan Bennett > >> <alan.bennett(a)linaro.org> Cc: Senthil Kumaran > >> <senthil.kumaran(a)linaro.org>, Fathi Boudra > >> <fathi.boudra(a)linaro.org> Subject: Re: New publishing infra > >> prototype report > >> > >> > >> Hello Tyler, > >> > >> As brought up today on IRC, it's a month since the below report and > >> proposal for further steps, and I don't remember any reply. This > >> whole publishing thing is peculiar, as it sits still when its not > >> needed, but it's actually in ambush there to cause havoc at any > >> time. > >> > >> For example, today Senthil came up with the question on how to > >> publish to snapshots. Fortunately, it turned out that it was > >> request for publishing a single file manually. But I know the guys > >> are working on Fedora builds, and that definitely will need > >> automated publishing (unless initial requirements as provided by > >> Fathi changed). And it's definitely needed for CBuild migration, > >> which I assume will be worked on next month. > >> > >> Btw, I discovered that a BP for that was submitted yet by Danilo: > >> https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/file-publ… > >> > >> > >> Thanks, > >> Paul > >> > >> > >> On Mon, 29 Apr 2013 18:58:39 +0300 > >> Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote: > >> > >>> Hello, > >>> > >>> Last month I worked on a blueprint > >>> https://blueprints.launchpad.net/linaro-android-infrastructure/+spec/protot… > >>> to prototype an implementation of publishing framework which > >>> wouldn't depend on particular Jenkins features (and misfeatures) > >>> and could be reused for other services across Linaro CI > >>> infrastructure. Among these other projects are: > >>> > >>> 1. OpenEmbedded builds - efficient ("fresh only") publishing of > >>> source tarballs and cache files. > >>> 2. CBuild - publishing of toolchain build artifacts and logs. > >>> 3. Fedora/Lava - publishing of build artifacts and logs. > >>> > >>> So, the good news is that was possible to implement a publishing > >>> system whose interface is a single script which hides all the > >>> publishing complexity underneath. Implementation was a cumbersome, > >>> because existing publishing backend was reused, but it already > >>> opens possibility for better logging, debugging, profiling, etc. > >>> > >>> With proof-of-concept client-side available, the main complexity > >>> still lies in server-side backend. It's clear that current "SFTP > >>> + SSH trigger script" approach doesn't scale well in terms of > >>> ease of setup and security. I added my considerations to address > >>> that topic in " Conclusions and Future Work" section of > >>> http://bazaar.launchpad.net/~linaro-automation/linaro-android-build-tools/t… > >>> > >>> So, action items I suggest based on this report: > >>> > >>> 1. Tyler to consult with Fathi (Fedora), Marcin (OE) and me > >>> (CBuild) and prepare architecture/spec for the general publishing > >>> system. It would be nice to BP this task to start in 13.05. > >>> 2. Depending on the time required to prepare spec, implementation > >>> can be scheduled right away, or postponed until LCE13, so we had > >>> another chance to discuss it face to face (as adhoc meeting, or > >>> as a session, if it's really worth it). > >>> > >>> > >>> Thanks, > >>> Paul > >>> > >>> Linaro.org | Open source software for ARM SoCe > >>> Follow Linaro: http://www.facebook.com/pages/Linaro > >>> http://twitter.com/#!/linaroorg - > >>> http://www.linaro.org/linaro-blog > >> > >> > >> > >> -- > >> Best Regards, > >> Paul > >> > >> Linaro.org | Open source software for ARM SoCs > >> Follow Linaro: http://www.facebook.com/pages/Linaro > >> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog > >> > >> > >> -- > >> Best Regards, > >> Paul > >> > >> Linaro.org | Open source software for ARM SoCs > >> Follow Linaro: http://www.facebook.com/pages/Linaro > >> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog > > > > > > > > -- > > James Tunnicliffe > > > -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

10 years, 10 months

Linux-next: Snown-ball Failed to mount rootfs

by Naresh Kamboju

Hi Team, While monitoring lava Dashboard page: - http://validation.linaro.org/lava-server/dashboard/image-reports/linux-next… And following job failed - http://validation.linaro.org/lava-server/scheduler/job/56645/log_file Kernel command line is as below but kernel not able to detect mmcblk1p5 instead it detected mmcblk0: p1 p2 p3 Kernel command line: console=ttyAMA2,115200n8 ip=dhcp vmalloc=300M root=/dev/mmcblk1p5 rootwait mem=128M@0 mali.mali_mem=32M@128M hwmem=168M@160M mem=48M@328M mem_issw=1M@383M mem=640M@384M mmcblk0: mmc0:0001 7.28 GiB mmcblk0boot0: mmc0:0001 partition 1 2.00 MiB mmcblk0boot1: mmc0:0001 partition 2 2.00 MiB ab8500-ext-supply3: disabling mmcblk0: p1 p2 p3 <LAVA_DISPATCHER>2013-06-03 04:26:58 PM CRITICAL: Could not get master image booted properly <LAVA_DISPATCHER>2013-06-03 04:26:58 PM ERROR: boot_linaro_image failed Please investigate this issue. Best regards, Naresh Kamboju

10 years, 10 months

validation.linaro.org Upgrade

by Dave Pigott

Hi All, This is just a reminder that we're doing the upgrade of the v.l.o production server starting on Sunday at 09:00 UTC. Boards will be off lined from this time. On Monday morning once all the boards have cleared their jobs, we will be performing backups and then doing the upgrade. If all goes well, then we will be back online late on Monday or worst case by 12:00 UTC on Tuesday. The server and scheduler will still be running until we do the upgrade, but I would recommend holding back submissions of jobs from Monday at 12:00 UTC until we give the all clear. Many thanks Dave LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

10 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation June 2013