apt proxy failures
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LAVA Dispatcher |
Fix Released
|
High
|
Andy Doan |
Bug Description
We've been seeing an occassionally weird issue when setting the apt proxy. It looks like:
root@master:~# [rc=0]: cp -L /etc/resolv.conf /mnt/testrootfs/etc
root@master:~# [rc=0]: mount --rbind /dev /mnt/testrootfs/dev
root@master:~# [rc=0]: chroot /mnt/testrootfs sh -c 'export http_proxy=http://
root@master:~# [rc=0]: chroot /mnt/testrootfs echo 'Acquire:
root@master:~# [rc=0]: chroot /mnt/testrootfs cat /etc/apt/
cat: /etc/apt/
A real example of this is here:
http://
Its happening enough (and fairly consistently on snowballs) that I think we should try and understand this. One thing I notice in the log file above was that it took a few retries to download the root.tar.gz. So I wonder if the 30proxy is just a symptom and not the root issue.
Related branches
- Andy Doan (community): Approve
- Spring Zhang (community): Needs Resubmitting
-
Diff: 109 lines (+15/-23)3 files modifiedlava_dispatcher/actions/lava-test.py (+10/-12)
lava_dispatcher/client/base.py (+4/-7)
lava_dispatcher/context.py (+1/-4)
Changed in lava-dispatcher: | |
importance: | Undecided → High |
Changed in lava-dispatcher: | |
status: | New → In Progress |
Changed in lava-dispatcher: | |
milestone: | none → 2012.08 |
Changed in lava-dispatcher: | |
assignee: | nobody → Andy Doan (doanac) |
milestone: | 2012.08 → 2012.09 |
Changed in lava-dispatcher: | |
status: | In Progress → Fix Released |
I should also add. Alexander thinks the way we are doing this is wrong. He thinks that rather than setting 30proxy, we should run instead run apt-get differently:
apt-get -oAcquire:http:proxy= http:// 192.168. 1.10:3128