[yocto] Fwd: build failure on ubuntu 64bits development system

[Jim Abernathy]

On 01/18/2012 11:06 AM, William Mills wrote:
>
>
> On 01/18/2012 10:25 AM, James Abernathy wrote:
>>
>>
>> On Wed, Jan 18, 2012 at 10:15 AM, William Mills <wmills at ti.com
>> <mailto:wmills at ti.com>> wrote:
>>
>>
>>
>>     On 01/18/2012 10:04 AM, James Abernathy wrote:
>>
>>
>>
>>         ---------- Forwarded message ----------
>>         From: *William Mills* <wmills at ti.com <mailto:wmills at ti.com>
>> <mailto:wmills at ti.com <mailto:wmills at ti.com>>>
>>         Date: Wed, Jan 18, 2012 at 9:57 AM
>>         Subject: Re: [yocto] build failure on ubuntu 64bits development
>>         system
>>         To: Gary Thomas <gary at mlbassoc.com <mailto:gary at mlbassoc.com>
>> <mailto:gary at mlbassoc.com <mailto:gary at mlbassoc.com>>>
>>         Cc: yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>> <mailto:yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>__>
>>
>>
>>
>>
>>         On 01/18/2012 09:51 AM, Gary Thomas wrote:
>>
>>         On 2012-01-18 07 <tel:2012-01-18%2007> <tel:2012-01-18%2007>:42,
>>         James Abernathy wrote:
>>
>>
>>
>>         On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy
>> <jfabernathy at gmail.com <mailto:jfabernathy at gmail.com>
>> <mailto:jfabernathy at gmail.com <mailto:jfabernathy at gmail.com>>
>> <mailto:jfabernathy at gmail.com <mailto:jfabernathy at gmail.com>
>> <mailto: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>
>> <mailto:jfabernathy at gmail.com <mailto:jfabernathy at gmail.com>>
>> <mailto:jfabernathy at gmail.com <mailto:jfabernathy at gmail.com>
>> <mailto: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.
>>
>>
>>         If your build dir is encyptfs or a fuse device or anything that
>>         is not a
>>         direct block device you will get this error. This is to be 
>> fixed in
>>         1.1.1 but encyptfs will still have other problems.
>>
>>         I build the Ubuntu 11.10 x64 system with 2 drives setup as Soft
>>         RAID 0.
>>         I picked btrfs as the file system for no particular reason.
>>         Should I go
>>         back to ext4 or is RAID 0 the problem?
>>
>>
>>     No, I would not do that yet. I would think software RAID would
>>     present a block device so would not trigger this error.
>>
>> I was hoping to use RAID 0 for speed. I have a I7 2700K on a DZ68DB with
>> 2 6Gb/s ports matched to 2 6Gb/s 7200 hard drives. Since the builds take
>> so long, I was looking for an edge.
>>
>> So are there any recommendations at this point? I'm assuming that the
>> default ext4 directly on the SATA drive is a fall back position.
>>
>> Advice?
>
> If it were me, I would instrument (hack) that code above to see what 
> part is failing.  Are you getting the right dev major/ minor from the 
> stat code or is the /proc/diskstats search code failing.
>
> Alternatively you could try the 1.1.1 branch to see if that fixes it.
>
I'm not sure I'm the right guys to be debugging this :-)
In the interest of my schedule, and since this is a brand new 
workstation, I'm just going to try EXT4 on Soft RAID 0 and see if that 
works.  If not, I'll look at 1.1.1.  I Assume that would be the M4 
release at this time.

Jim A
>
>>
>> Jim A
>>
>>
>> > 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
>>
>>     Your build dir is in md0 or md1 (wrt your other post)
>>
>>
>>         JIm A
>>
>>         ___________________________________________________
>>         yocto mailing list
>>         yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>> <mailto:yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>__>
>>         https://lists.yoctoproject.____org/listinfo/yocto
>> <https://lists.yoctoproject.__org/listinfo/yocto
>> <https://lists.yoctoproject.org/listinfo/yocto>>
>>
>>
>>
>>
>>         _________________________________________________
>>         yocto mailing list
>>         yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>>         https://lists.yoctoproject.__org/listinfo/yocto
>> <https://lists.yoctoproject.org/listinfo/yocto>
>>
>>