[Yocto-builds] buildbot failure in The Yocto Autobuilder on nightly-oecore

[Paul Eggleton]

On Friday 22 March 2013 01:32:59 yocto-builds at yoctoproject.org wrote:
> Build status: FAILURE
> 
> Buildslave for this Build: ab06
> | NOTE: Test Result for qemuarm core-image-sato
> | NOTE: Testcase PASS FAIL NORESULT
> | NOTE: SSH 1 0 0
> | NOTE: SCP 1 0 0
> | NOTE: dmesg 1 0 0
> | NOTE: smart_help 1 0 0
> | NOTE: smart_query 0 1 0
> | NOTE: rpm_query 1 0 0
> | NOTE: connman 1 0 0
> | NOTE: shutdown 1 0 0

And from the log:
>| 	TARGET: smart command run without problem
>| 	TARGET: smart command has issue when running, Pls. check the error log
>| 	TARGET: ##### Error Log #####
>| rpmdb: BDB0113 Thread/process 663/3069857792 failed: BDB1507 Thread died in 
>Berkeley DB library
>| error: db_init:db3.c:1098: dbenv->failchk(-30973): BDB0087 DB_RUNRECOVERY: 
>Fatal error, run database recovery
>| Re-opening dbenv with DB_RECOVER ...
>| BDB2526 Finding last valid log LSN: file: 1 offset 8322133
>| 
>recovery 0% complete
>...
>recovery 18% completeBDB1518 Recovery complete at Fri Mar 22 01:11:21 2013
>| BDB1519 Maximum transaction ID 0 recovery checkpoint [1][8328113]
>| .
>| recovery succeeded.
>| Updating cache...               ######################################## 
>[100%]
>| 
>| avahi-daemon-0.6.31-r6.1 at armv5te
>| avahi-locale-en-gb-0.6.31-r6.1 at armv5te
>| 
>| Saving cache...
>| 
>| 	TARGET: #####    End    #####

>From this we can determine:

* The problem is no longer confined to MIPS
* The RPM database is definitely becoming corrupted

Even in the face of multiple clients opening the RPM database within the same 
machine, locking should prevent simultaneous access of the database from 
resulting in corruption. Is there a chance two qemu instances are being 
started on the same image file, thus bypassing any internal locking?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre