| Summary: | libowl do_fetch error | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Shane Wang <shane.wang> | ||||||
| Component: | core | Assignee: | Michael Halstead <mhalstead> | ||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | Medium+ | CC: | corneliux.stoicescu, jiajun.xu, laurentiu.serban, meta.mr.watcher, meta.watcher, richard.purdie, scott.a.garman, sgw | ||||||
| Version: | 1.3 | ||||||||
| Target Milestone: | 1.4 M4 | ||||||||
| Hardware: | x86 | ||||||||
| OS: | Multiple | ||||||||
| Whiteboard: | |||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||
| Verified: | Documentation change: | --- | |||||||
| Attachments: |
|
||||||||
|
Description
Shane Wang
2012-07-24 07:30:23 UTC
This looks like it might be a proxy related issue, could this be reproduced on a different machine? I just re-fetched that tarball of the git repo and everything is Ok on this end, please re-check. I reproduced it on Jiajun's machine. Try this way if you can't, then close it. 1. remove the tar ball of libowl and all git stuffs related to libowl in your download dir. 2. run "bitbake libowl -c fetch" 3. you will find a new tar ball of libowl in the download dir with the size 50000+ bytes (possibly). run tar command to unpack the tar ball. On my side, I can't unpack the .tar.gz file with errors. I followed your steps twice, I even set PREMIRRORS="" each time I would get the following and the tar file was OK, please confirm the size and date of your tarball. -rw-rw-r-- 1 sgw sgw 55935 May 8 12:40 ../../downloads/git2_git.yoctoproject.org.libowl.tar.gz -rw-rw-r-- 1 sgw sgw 0 Jul 26 00:00 ../../downloads/git2_git.yoctoproject.org.libowl.tar.gz.done Please verify there is not some kind of proxie cache or some other proxy related issue. Reopen if needed. Maybe this helps: I have 2 poky directories from the same branch (denzil) and same commit (denzil 1.2.2) with the following configuration: 1) clean poky directory with clean build directory. "bitbake -c fetch libowl" works 2) old poky directory with populated build/downloads directory. "bitbake -c fetch libowl" produces the same error as this bug. Note: I moved the downloads directory from a poky directory with master + latest commit (19 Oct.). I tried bitbake -c clean libown and manually removing all libowl references from build/sstate-cache/ and build/downloads but nothing worked. NOTE: Adding the log file from do_fetch. Hope this helps. NOTE: Reopening Created attachment 896 [details]
do_fetch log for libowl
I could reproduce this! I am seeing that the initial wget works and then the tar fails as seen in the original bug, with a corrupted tarball. The PREMIRROR tarball located on the autobuilder mirror is correct and sane. I am not sure if there is a timing issue. If I add a couple of syncs before the tar things work every time. Is there some parallelism involved in the fetcher that could cause some issues? A different question is why did it not fall back to the actual upstream when the premirror failed. Here is something interesting: There are 2 links that are used to fetch this tarball. One from yoctoproject.org, one from openembedded.org. http://downloads.yoctoproject.org/mirror/sourcee/git2_git.yoctoproject.org.libowl.tar.gz (THIS WORKS) http://sources.openembedded.org/git2_git.yoctoproject.org.libowl.tar.gz (THIS DOES NOT WORK) 1) download using the yoctoproject.org link and extract the tarball. notice it works with no errors. 2) download using the openembedded.org link; you will receive an error because tehe file does not exist there any longer. After that download using the yoctoproject.org link and extract the tarball. Notice the tarball is corrupted. After talking this over with my team we came over the idea that this might be a proxy-related issue; the proxy might be caching something from the dead link and thus corrupting the tarball. /Cornel I think this is fixed in 1.4, can someone try to confirm this, I just tested with 1.4 and a cleanall then 2 fetches and it seemed to work, but when I tried with Danny it failed once, but I can get it to reproduce again, I really need a clean reproducer for this Any help advice welcome Created attachment 968 [details]
log.do_fetch
I think there are still some issues with this. I got a fetch failure out of around 10 yesterday. Here is my output:
"
ERROR: Fetcher failure: Fetch command failed with exit code 2, output:
tar: Skipping to next header
gzip: stdin: invalid compressed data--crc error
gzip: stdin: invalid compressed data--length error
tar: Child returned status 1
tar: Error is not recoverable: exiting now
ERROR: Function failed: Fetcher failure for URL: 'git://git.yoctoproject.org/libowl;protocol=git'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/cornel/SDD/Yocto/3poky/build/tmp/work/x86_64-poky-linux/libowl/0.1+git1+6ebc8ac8f8575278dd40a535cadefa26374e44b1-r0/temp/log.do_fetch.19136
ERROR: Task 2415 (/home/cornel/SDD/Yocto/3poky/meta/recipes-sato/libowl/libowl_git.bb, do_fetch) failed with exit code '1'
"
Tested on:
Build Configuration:
BB_VERSION = "1.17.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Ubuntu-12.04"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "qemux86-64"
DISTRO = "poky"
DISTRO_VERSION = "1.3+snapshot-20121204"
TUNE_FEATURES = "m64"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp
meta-skeleton = "(nobranch):247b6a3754c2c50318e2a73d79981ba0e9cb560b"
Note1: Please look at my attached log.do_fetch.
Note2: I have no download mirrors set in local.conf.
The issue seems to be only within Intel network, possibly a proxy issue, we have not been able to verify it outside, I have verified with wget standalone in a loop and about 1 in 10 or so fail in the same way. This issue occurs also on denzil-next OE Build Configuration: BB_VERSION = "1.15.2" TARGET_ARCH = "i586" TARGET_OS = "linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "1.2.1" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-yocto = "sgarman/denzil-next-pull4:d166ea7bb13eaf25b54e14f0bf9c5747ea950617" I've downloaded approximately 6300 copies over the last 8 days with zero errors through proxy.jf.intel.com. It seems that increasing the open connection count has fixed the problem from here. Laurentiu can you provide the proxy settings used when you saw the issue on December 13th? If I remember correctly, Laurentiu is using: export http_proxy='http://proxy.jf.intel.com:911/' export https_proxy='http://proxy.jf.intel.com:911/' export ftp_proxy='http://proxy.jf.intel.com:911/' export socks_proxy='http://proxy.jf.intel.com:1080/' And /usr/local/bin/git-proxy #!/bin/bash # $1 = git.yoctoproject.org, $2 = 1080 PROXY=proxy.jf.intel.com exec socat STDIO SOCKS4:$PROXY:$1:$2 Please note that I used the exact same setup but with proxy-ir.glb.intel.com We have decided not to fail test cases for this issue as for master and danny branch it occurs apparently at random. It can be bypassed 100% by using local download mirrors. A new Test Case will be added for this issue until it is resolved. Because this is an almost non-existing issue, and it seems to be particular to our proxy setup, I believe it is not related to Yocto. Until we can find a reproducible scenario I am setting this to worksforme. Please feel free to reopen if need be. |