On Wed, Jan 18, 2012 at 9:51 AM, Gary Thomas <g...@mlbassoc.com> wrote:
> On 2012-01-18 07:42, James Abernathy wrote: > >> >> >> On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy >> <jfaberna...@gmail.com<mailto: >> jfaberna...@gmail.com>**> wrote: >> >> >> >> >> On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy < >> jfaberna...@gmail.com <mailto:jfaberna...@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@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@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@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@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@yoctoproject.org > https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto> >
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto