Summary: | net-misc/wget-1.11.1 doesn't resolve DNS names in 2008.0 beta2 stage3 chroot due to /etc/resolv.conf being 600 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Yanestra <Yanestra> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | kkuehne, martin, releng |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Yanestra
2008-05-17 21:48:21 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 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 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. 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?? 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. 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}" # # 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? "Does it work if you put distfiles.gentoo.org and its ip address in /etc/hosts?" Yes, that works. (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 @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). 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? (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 > This might indicate that users do not have read access to /etc/resolve.conf
Sigh, no. Simply imply not all bug reporters are idiots.
i'm guessing that was indeed the source of your troubles |