[yocto] build failure on ubuntu 64bits development system

James Abernathy jfabernathy at gmail.com
Wed Jan 18 07:01:14 PST 2012


On Wed, Jan 18, 2012 at 9:51 AM, Gary Thomas <gary at mlbassoc.com> wrote:

> On 2012-01-18 07:42, James Abernathy wrote:
>
>>
>>
>> On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy <jfabernathy at gmail.com<mailto:
>> jfabernathy at gmail.com>**> wrote:
>>
>>
>>
>>
>>    On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy <
>> jfabernathy at gmail.com <mailto:jfabernathy at gmail.com>**> wrote:
>>
>>        I just built a new development pc and installed Ubuntu 11.10 x64.
>>  I wonder if there are any new requirements to building Yocto in that
>> environment?  I got an error right
>>        off, but then it complete the first 63 task and stopped
>> successfully.  error below:
>>
>>        jim at ubuntu:~/poky/build-cdv$ bitbake core-image-sato
>>        Pseudo is not present but is required, building this first before
>> the main build
>>        Parsing recipes: 100% |#############################**####################|
>> Time: 00:00:25
>>        Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037
>> targets, 22 skipped, 0 masked, 0 errors.
>>        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 0x4c338d0>)
>>           File "buildstats.bbclass", line 21, in set_device(e=<bb.event.*
>> *BuildStarted object at 0x4c338d0>)
>>        UnboundLocalError: local variable 'rdev' referenced before
>> assignment
>>
>>
>>        Any ideas?
>>
>>        JIm A
>>
>>
>>    I went back and tried using the tarballs for poky edison and
>> cedartrail bsp and the errors don't occur.  So I'm guessing the issue isn't
>> related to Ubuntu 32 vs. 64 bit.
>>
>>
>> I spoke too soon. Same error in edison tarballs.  I looked at the code
>> and I can see an place were rdev could go un assigned. If you fell out of
>> the for loop without passing any of
>> the if conditions, rdev would be unassigned.  That must be what is
>> happening in Ubuntu 11.10 x64
>>
>> Anybody building with Ubuntu 11.10 x64?  This doesn't happen on x32
>>
>> Jim A
>>
>>
>> def set_device(e):
>>     tmpdir = bb.data.getVar('TMPDIR', e.data, True)
>>     try:
>>         os.remove(bb.data.getVar('**DEVFILE', e.data, True))
>>     except:
>>         pass
>>     ##############################**##############################**
>> ################
>>     # We look for the volume TMPDIR lives on. To do all disks would make
>> little
>>     # sense and not give us any particularly useful data. In theory we
>> could do
>>     # something like stick DL_DIR on a different partition and this would
>>     # throw stats gathering off. The same goes with SSTATE_DIR. However,
>> let's
>>     # get the basics in here and work on the cornercases later.
>>     ##############################**##############################**
>> ################
>>     device=os.stat(tmpdir)
>>     majordev=os.major(device.st_**dev)
>>     minordev=os.minor(device.st_**dev)
>>     for line in open("/proc/diskstats", "r"):
>>         if majordev == int(line.split()[0]) and minordev ==
>> int(line.split()[1]):
>>            rdev=line.split()[2]
>>     file = open(bb.data.getVar('DEVFILE', e.data, True), "w")
>>     file.write(rdev)
>>     file.close()
>>
>
> Can you show what the differences are between /proc/diskstats
> on the two systems?  That's obviously what's causing the error.
>
> --

on the x64 system it's:
jim at ubuntu:~/poky-edison-6.0/build$ cat /proc/diskstats
   1       0 ram0 0 0 0 0 0 0 0 0 0 0 0
   1       1 ram1 0 0 0 0 0 0 0 0 0 0 0
   1       2 ram2 0 0 0 0 0 0 0 0 0 0 0
   1       3 ram3 0 0 0 0 0 0 0 0 0 0 0
   1       4 ram4 0 0 0 0 0 0 0 0 0 0 0
   1       5 ram5 0 0 0 0 0 0 0 0 0 0 0
   1       6 ram6 0 0 0 0 0 0 0 0 0 0 0
   1       7 ram7 0 0 0 0 0 0 0 0 0 0 0
   1       8 ram8 0 0 0 0 0 0 0 0 0 0 0
   1       9 ram9 0 0 0 0 0 0 0 0 0 0 0
   1      10 ram10 0 0 0 0 0 0 0 0 0 0 0
   1      11 ram11 0 0 0 0 0 0 0 0 0 0 0
   1      12 ram12 0 0 0 0 0 0 0 0 0 0 0
   1      13 ram13 0 0 0 0 0 0 0 0 0 0 0
   1      14 ram14 0 0 0 0 0 0 0 0 0 0 0
   1      15 ram15 0 0 0 0 0 0 0 0 0 0 0
   7       0 loop0 0 0 0 0 0 0 0 0 0 0 0
   7       1 loop1 0 0 0 0 0 0 0 0 0 0 0
   7       2 loop2 0 0 0 0 0 0 0 0 0 0 0
   7       3 loop3 0 0 0 0 0 0 0 0 0 0 0
   7       4 loop4 0 0 0 0 0 0 0 0 0 0 0
   7       5 loop5 0 0 0 0 0 0 0 0 0 0 0
   7       6 loop6 0 0 0 0 0 0 0 0 0 0 0
   7       7 loop7 0 0 0 0 0 0 0 0 0 0 0
   8       0 sda 33076 23382 1115462 1829656 31802 9209 2849176 624296 0
190664 2454576
   8       1 sda1 32289 23295 1108604 1827592 27505 9200 2848960 560828 0
131548 2388540
   8       2 sda2 429 24 3618 1224 18 9 216 64 0 1260 1288
   8       3 sda3 2 0 20 108 0 0 0 0 0 108 108
   8       5 sda5 191 63 1900 460 0 0 0 0 0 436 456
   8      16 sdb 32063 23153 1112192 1760580 25981 8723 2780656 549424 0
134176 2310272
   8      17 sdb1 31842 23153 1110554 1759984 21702 8723 2780656 501512 0
88724 2261696
   8      18 sdb2 2 0 12 52 0 0 0 0 0 52 52
   8      21 sdb5 47 0 250 228 0 0 0 0 0 228 228
  11       0 sr0 0 0 0 0 0 0 0 0 0 0 0
   9       0 md0 133691 0 2218832 0 67133 0 5629616 0 0 0 0
   9       1 md1 235 0 1880 0 0 0 0 0 0 0 0

On the x32 system it's:
  im at ubuntu-workstation:~$ cat /proc/diskstats
  1       0 ram0 0 0 0 0 0 0 0 0 0 0 0
  1       1 ram1 0 0 0 0 0 0 0 0 0 0 0
  1       2 ram2 0 0 0 0 0 0 0 0 0 0 0
  1       3 ram3 0 0 0 0 0 0 0 0 0 0 0
  1       4 ram4 0 0 0 0 0 0 0 0 0 0 0
  1       5 ram5 0 0 0 0 0 0 0 0 0 0 0
  1       6 ram6 0 0 0 0 0 0 0 0 0 0 0
  1       7 ram7 0 0 0 0 0 0 0 0 0 0 0
  1       8 ram8 0 0 0 0 0 0 0 0 0 0 0
  1       9 ram9 0 0 0 0 0 0 0 0 0 0 0
  1      10 ram10 0 0 0 0 0 0 0 0 0 0 0
  1      11 ram11 0 0 0 0 0 0 0 0 0 0 0
  1      12 ram12 0 0 0 0 0 0 0 0 0 0 0
  1      13 ram13 0 0 0 0 0 0 0 0 0 0 0
  1      14 ram14 0 0 0 0 0 0 0 0 0 0 0
  1      15 ram15 0 0 0 0 0 0 0 0 0 0 0
  7       0 loop0 0 0 0 0 0 0 0 0 0 0 0
  7       1 loop1 0 0 0 0 0 0 0 0 0 0 0
  7       2 loop2 0 0 0 0 0 0 0 0 0 0 0
  7       3 loop3 0 0 0 0 0 0 0 0 0 0 0
  7       4 loop4 0 0 0 0 0 0 0 0 0 0 0
  7       5 loop5 0 0 0 0 0 0 0 0 0 0 0
  7       6 loop6 0 0 0 0 0 0 0 0 0 0 0
  7       7 loop7 0 0 0 0 0 0 0 0 0 0 0
  8       0 sda 335 3 2704 284 0 0 0 0 0 284 284
  8       1 sda1 167 0 1336 152 0 0 0 0 0 152 152
  8      16 sdb 360 3 2904 480 0 0 0 0 0 376 480
  8      17 sdb1 165 0 1320 120 0 0 0 0 0 120 120
  8      18 sdb2 29 0 232 212 0 0 0 0 0 212 212
  8      32 sdc 5605 15794 503606 680328 578 1698 19480 35292 0 20740 715608
  8      33 sdc1 5274 15763 500722 678628 565 1698 19480 34748 0 20068
713364
  8      34 sdc2 2 0 4 0 0 0 0 0 0 0 0
  8      37 sdc5 162 31 1544 892 0 0 0 0 0 884 892
 11       0 sr0 0 0 0 0 0 0 0 0 0 0 0
jim at ubuntu-workstation:~$

The file system is BTRFS  on Software RAID 0 with 2 disks.

JIm A


> ------------------------------**------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------**------------------------------
> ______________________________**_________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20120118/d9007e23/attachment.html>


More information about the yocto mailing list