Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 222555 - net-misc/wget-1.11.1 doesn't resolve DNS names in 2008.0 beta2 stage3 chroot due to /etc/resolv.conf being 600
Summary: net-misc/wget-1.11.1 doesn't resolve DNS names in 2008.0 beta2 stage3 chroot ...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-17 21:48 UTC by Yanestra
Modified: 2008-06-16 21:44 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yanestra 2008-05-17 21:48:21 UTC
I work under a current Debian 4.0 (AMD64/stable) and try to compile a current Gentoo in a chroot'ed environment.

Portage fails to resolve host names correctly after it has been updated. /etc/resolv.conf is set correctly.

# emerge --version
Portage 2.1.4.4 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24.6 x86_64)

# emerge -f --newuse world
Calculating world dependencies... done!

>>> Emerging (1 of 1) sys-devel/gcc-4.1.2 to /
>>> Downloading 'http://distfiles.gentoo.org/distfiles/gcc-4.1.2-patches-1.1.tar.bz2'
--2008-05-17 23:43:46--  http://distfiles.gentoo.org/distfiles/gcc-4.1.2-patches-1.1.tar.bz2
Resolving distfiles.gentoo.org... failed: Temporary failure in name resolution.
(and so on)

# ping distfiles.gentoo.org
PING distfiles.gentoo.org (156.56.247.195) 56(84) bytes of data.
64 bytes from gentoo.ussg.indiana.edu (156.56.247.195): icmp_seq=1 ttl=55 time=131 ms
(and so on)


Reproducible: Always

Steps to Reproduce:
1. Make a Gentoo environment somewhere in your FS.
2. chroot to it.
3. emerge --sync
4. emerge system
Actual Results:  
Emerge complains that it couldn't fetch files because it couldn't resolve the hostnames.
Comment 1 Karsten Kuehne 2008-05-18 12:35:58 UTC
(In reply to comment #0)
> I work under a current Debian 4.0 (AMD64/stable) and try to compile a current
> Gentoo in a chroot'ed environment.
> 
> Portage fails to resolve host names correctly after it has been updated.
> /etc/resolv.conf is set correctly.
> 
> # emerge --version
> Portage 2.1.4.4 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.6.1-r0,
> 2.6.24.6 x86_64)
> 
> # emerge -f --newuse world
> Calculating world dependencies... done!
> 
> >>> Emerging (1 of 1) sys-devel/gcc-4.1.2 to /
> >>> Downloading 'http://distfiles.gentoo.org/distfiles/gcc-4.1.2-patches-1.1.tar.bz2'
> --2008-05-17 23:43:46-- 
> http://distfiles.gentoo.org/distfiles/gcc-4.1.2-patches-1.1.tar.bz2
> Resolving distfiles.gentoo.org... failed: Temporary failure in name resolution.
> (and so on)
> 
> # ping distfiles.gentoo.org
> PING distfiles.gentoo.org (156.56.247.195) 56(84) bytes of data.
> 64 bytes from gentoo.ussg.indiana.edu (156.56.247.195): icmp_seq=1 ttl=55
> time=131 ms
> (and so on)
> 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Make a Gentoo environment somewhere in your FS.
> 2. chroot to it.
> 3. emerge --sync
> 4. emerge system
> Actual Results: 
> Emerge complains that it couldn't fetch files because it couldn't resolve the
> hostnames.

Hi,
coud you ping anything else appart from that? Did you try to ping the IP adress?
Can you post your /etc/conf.d/net and the relevant dmesg, lscpi and ifconfig output???
Whats the Gentoo and Kernel version you are using?
Thanks,
Karsten
Comment 2 Yanestra 2008-05-18 12:50:27 UTC
Hi,

> coud you ping anything else appart from that?

Yes, virtually everything.

> Did you try to ping the IP adress?

Yes. Works.

> Can you post your /etc/conf.d/net and the relevant dmesg, lscpi and ifconfig
output???

Since it is a production Debian system and just a chroot'ed Gentoo environment, which actually has neither kernel nor net config, I doubt that would help. In the chroot cage: Everything works, until portage makes some environmental changes. Why? For what reason? If there is some sandbox in order to fetch files, where is it?

> Whats the Gentoo and Kernel version you are using?

Gentoo is the Gentoo of today, and kernel is 
Linux superlupo 2.6.24.6 #1 SMP Sat May 3 22:19:46 CEST 2008 x86_64 GNU/Linux
Comment 3 Yanestra 2008-05-18 13:03:51 UTC
Ahem, sorry, forgot to say: "emerge --sync" works perfectly. Problems only when trying to fetch files. Most of the files are already there, so "emerge system" worked perfectly, too.
Comment 4 Karsten Kuehne 2008-05-18 17:24:59 UTC
First of all, I would give env-update a try and source /etc/profile

After that we could probably narrow it down to only wget wont connect to the mirror? Can you wget the file manually?
If you have a proxy in place did you specify it in the /etc/wgetrc or ~/.wgetrc??
Comment 5 Yanestra 2008-05-18 17:34:34 UTC
env-update and . /etc/profile done, no change.

wget manually invoked from command line works perfectly.

There are no private settings yet, this is simply a plain Gentoo (i.e. stage3-amd64-2008.0_beta2) without anything changed, except for /etc/localtime, /etc/resolv.conf, and /etc/make.conf. "emerge --sync" and "emerge system" are done, now I want to emerge the rest...

/dev and /proc are mounted --bind from the host system.

There are no proxy settings required, so that isn't the problem.
Comment 6 Karsten Kuehne 2008-05-18 18:14:00 UTC
I wondering if your "working" wget is not properly bound to portage.
Try:
1. which wget
2.set the FETCHCOMMAND var in your /etc/make.conf

example make.conf:
# Fetching files 
# ==============
#
# Default fetch command (5 tries, passive ftp for firewall compatibility)
#FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp \${URI} -P \${DISTDIR}"
#RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp \${URI} -P \${DISTDIR}"
#
# Using wget, ratelimiting downloads
#FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp --limit-rate=200k \${URI} -P \${DISTDIR}"
#RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp --limit-rate=200k \${URI} -P \${DISTDIR}"
#
Comment 7 Yanestra 2008-05-18 18:48:58 UTC
# which wget
/usr/bin/wget
# ls -d /var/db/pkg/*/wget*
/var/db/pkg/net-misc/wget-1.11.1

FETCHCOMMAND set... Doesn't work. Sorry. The error message: "Temporary failure in name resolution" means: It is there, it is being executed, but for some reason, the DNS settings disappear. What can it be but a broken sandbox mechanism?
Comment 8 Karsten Kuehne 2008-05-18 19:35:52 UTC
"Does it work if you put distfiles.gentoo.org and its ip address in /etc/hosts?"
Comment 9 Yanestra 2008-05-18 20:25:52 UTC
Yes, that works.
Comment 10 Jeroen Roovers (RETIRED) gentoo-dev 2008-05-18 23:31:37 UTC
(In reply to comment #8)
> "Does it work if you put distfiles.gentoo.org and its ip address in
> /etc/hosts?"

Of course that works.

@yanestra: You didn't show the $YOUR_CHROOT/etc/resolv.conf yet.

Also, did you try a simple `wget http://distfiles.gentoo.org/distfiles/gcc-4.1.2-patches-1.1.tar.bz2' yet?

Also, your emerge --info is missing.

I would also like to know if /proc and /dev are mounted inside the chroot.

By the way, it's considered inappropriate to use our distfiles master. Please find a local mirror[1] and start using that instead.

[1] http://www.gentoo.org/main/en/mirrors.xml
Comment 11 Yanestra 2008-05-19 07:14:38 UTC
@Jeroen
resolv.conf contains only one line: nameserver 192.168.1.1
I tried a manual wget, and it worked (which I already had written).
Jeroen, I suppose I may use the distfile master for testing purposes, maybe even with your permission. Thank you very much.
emerge --info will be posted when possible (it's not right now).
Comment 12 martin 2008-06-10 22:15:27 UTC
Hi,
I'm confronted with the same problem in a xen-domU. I copied a working domU, bootet the copy and wasn't able to fetch any sources - running wget manually worked.
The problem seems to have sth. to do with the userfetch-FEATURE. If I put "-userfetch" in my make.conf, everthing works fine. The permissions of the distdir are correct (since they work on the other machine without problems).
Any suggestions?
Comment 13 Ben 2008-06-15 01:04:34 UTC
(In reply to comment #12)
> The problem seems to have sth. to do with the userfetch-FEATURE. If I put
> "-userfetch" in my make.conf, everthing works fine. The permissions of the
> distdir are correct (since they work on the other machine without problems).
> Any suggestions?
> 
This might indicate that users do not have read access to /etc/resolve.conf 
Comment 14 Yanestra 2008-06-15 14:25:40 UTC
> This might indicate that users do not have read access to /etc/resolve.conf

Sigh, no. Simply imply not all bug reporters are idiots.
Comment 15 SpanKY gentoo-dev 2008-06-16 21:44:24 UTC
i'm guessing that was indeed the source of your troubles