Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Wolfram Stering <wolfram.stering@hale.at>
To: openembedded-core@lists.openembedded.org
Subject: Problem with buildstats when building on a btrfs volume
Date: Fri, 28 Oct 2011 09:25:28 +0200	[thread overview]
Message-ID: <4EAA58E8.4090702@hale.at> (raw)

Hello All,

I've encountered a problem when building (with TMPDIR residing) on a
btrfs volume.

It does not matter what is being built: starting clean, bitbake
discoveres that pseudo needs to be built, it does so successfully but
then gets an exception when doing the buildstats.

ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
  File "run_buildstats(e)", line 18, in run_buildstats(e=<bb.event.BuildStarted object at 0x5e33710>)
  File "buildstats.bbclass", line 21, in set_device(e=<bb.event.BuildStarted object at 0x5e33710>)
UnboundLocalError: local variable 'rdev' referenced before assignment

The problem is related to the fact that btrfs reports a fake device id
by stat(2) in st_dev.
See there for more information:
https://bugzilla.redhat.com/show_bug.cgi?id=711881
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/3509

OE core uses stat on tmpdir to find out the major/minor device ids when
collecting the build statistics, see function set_device in
buildstats.bbclass. If the (fake) device id can't be found in
/proc/diskstats, rdev is never set, but still used two lines later (this
case should be detected and handled gracefully anyhow, IMHO, e.g.
relinquishing buildstats).

I don't know how to reliably solve this problem. /proc/self/mountinfo
can't be used either, as the listed device id there is still different
from what is reported by stat (see the first link above). One possible
solution would be to match on the device name (third field in
/proc/diskstats), but this information is not returned by stat so the
actual mount point needs to be found as prefix of the TMPDIR path, then
symlinks in the device name would need to be resolved as well (which is
common, if LVM and the device mapper are used).

I'm not good at python, otherwise I'd have proposed a patch...

have a nice day,

-wolfi


-- 
Wolfram Stering
 (Entwicklung)
HALE electronic GmbH
Eugen-Müller-Straße 18, 5020 Salzburg, Austria
 Tel: +43 (662) 439011 550
 Fax: +43 (662) 439011 9
http://www.hale.at/
Firmenbuchnummer: FN 66801m HG Salzburg



--
Scanned by MailScanner.




                 reply	other threads:[~2011-10-28  7:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EAA58E8.4090702@hale.at \
    --to=wolfram.stering@hale.at \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox