Bug 818

Summary: opkg defects: when opkg from remote site, it will easily fails with md5 err
Product: [Yocto Project Subprojects] ADT Reporter: liping Ke <liping.ke>
Component: adtAssignee: liping Ke <liping.ke>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: High CC: jessica.zhang, lianhao.lu, liping.ke, poky.adt.watcher, poky.watcher
Version: 1.0   
Target Milestone: 1.0 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description liping Ke 2011-03-08 00:18:34 UTC 
When opkg update and install from a remote URI, if the network is not fast enough, it will meet md5sum chkerror easily, something like below:
opkg_install_pkg: Package XXX md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'
opkg_install_cmd: Cannot install package XXX

I found for increasing success chance, (we here always fail), for installing each package, 
firstly add 
1) opkg update (update each time)

2) then opkg install 

3) sleep 3 (3 seconds are best)


then begin another round for installing another package.

Even so I still fail, for example, when installing qemu-native,
it will automatically install many other packages, it will easily fail for the same reason. I  guess if I add update/sleep, it will also fail.

So I guess opkg source code must have some defects (synchronization problem wget download problem or else). It must be fixed first.

This is a high priority bug.

criping
Comment 1 liping Ke 2011-03-08 00:30:27 UTC 
If I have a machine in the internal lab, which means has another layer of network gate, the speed is slower, the failure rate will be higher accordingly.
Even with above work-round, I still have rare success chances.


criping
Comment 2 liping Ke 2011-03-08 01:28:24 UTC 
I verified in opkg source code, 
for wget, add some options such as -v -tries will help a lot.

I guess this is something with poky fetch with wget often unpack fails

So after we add appropriate wget options, make sure it will not download damaged file, the problem should be fixed.

criping
Comment 3 liping Ke 2011-03-08 18:02:49 UTC 
It's obvious a opkg bug. Using wget style for opkg doesn't work well when network condition is not very good. It's partly because wget itself is not that perfect especially when -q option.

If we switch to curl instead of wget, it's a little better, but still, we might meet the same problem.


criping
Comment 4 liping Ke 2011-03-09 17:22:01 UTC 
After more investigation, it might be our proxy server problem.

We have two repos under different folders. And the proxy server often provides something in the cache. So it mixed up the contents of the two repos. 

Everything is just messed up.

We'll first delete one repo to see how proxy server works.

Jessica gave info that visiting outside intel network, everything is just fine.
Comment 5 liping Ke 2011-03-10 00:17:07 UTC 
After we checking the opkg code, wget code should be just correct.

Then it should be our proxy server cache problem. Since our filename and path are too long. and the different repo's path and name are very much similar. It makes our proxy server cache-hit algorithm perplexed.

After adding --no-cache in wget to disable all server side cache, the problem should be fixed.

criping
Comment 6 liping Ke 2011-03-10 22:14:18 UTC 
This problem has been fixed by http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f776bc667eb99bf554f433d75a381ebbb1ddb618


We solve the proxy issue by disable all wget server side proxy.

criping
Comment 7 liping Ke 2011-03-10 22:15:46 UTC 
change bug status