From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 315C713877A for ; Mon, 28 Jul 2014 15:34:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DF949E0BCF; Mon, 28 Jul 2014 15:34:29 +0000 (UTC) Received: from mail-wg0-f68.google.com (mail-wg0-f68.google.com [74.125.82.68]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A481FE0870 for ; Mon, 28 Jul 2014 15:34:28 +0000 (UTC) Received: by mail-wg0-f68.google.com with SMTP id m15so2648339wgh.11 for ; Mon, 28 Jul 2014 08:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PVXbabO2U0qU/gwLOua7yHQqaP06Ne9LQ75WLX6qobs=; b=XX65GnqY608Fnx046ykcMIfeGStlKGG7TyU/An92RGT2Y3GxAK9st0xK6GSR0rlgXC w/Wx2EW5wAOwlLEjVmIl/OVdvFreH+o/qCZapKr92xF8lST8zxmzE7m5bTK3OSrWSn5Y yttwV7EWyH9IAstNvCOWr1Xk4/H9hDgpaHiSuJdjulGIBDZLdghNUXipa7JkajSQuoy1 /35nRa0N5SAyGywNoe3uTEBs+paMEc6LpxM5FXQeDLBrn/278xFeInqH4PNQ8wOCQfwU iMC3I9EHnvPjTQP3MIDwC0ap9vSprTAhqbTybUwIPvK78cms4GAYnd03AF4gmSNwM8l6 v7+g== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.194.243.200 with SMTP id xa8mr50034404wjc.97.1406561667228; Mon, 28 Jul 2014 08:34:27 -0700 (PDT) Received: by 10.180.75.235 with HTTP; Mon, 28 Jul 2014 08:34:27 -0700 (PDT) In-Reply-To: <53D57670.3090007@fastmail.co.uk> References: <20140727102923.7229724e@hactar.digimed.co.uk> <20140727201322.3397d2f4@digimed.co.uk> <53D57670.3090007@fastmail.co.uk> Date: Mon, 28 Jul 2014 18:34:27 +0300 Message-ID: Subject: Re: [gentoo-user] resolv.conf is different after every reboot From: Grand Duet To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 478a626c-c898-4f51-8aeb-c725248b8aba X-Archives-Hash: 10411687103bbed05a3c6713ffa07493 2014-07-28 1:00 GMT+03:00 Kerin Millar : > On 27/07/2014 21:38, Grand Duet wrote: >> >> 2014-07-27 22:13 GMT+03:00 Neil Bothwick : >>> >>> On Sun, 27 Jul 2014 13:33:47 +0300, Grand Duet wrote: >>> >>>>> That's what replaces it when eth0 comes up. >>>>> It looks like eth0 is not being brought up fully >>>> >>>> >>>> It sounds logical. But how can I fix it? >>> >>> >>> By identifying how far it is getting and why no further. >>> But it appears that eth0 is being brought up correctly >>> and then the config is overwritten by the lo config. >> >> >> I think so. >> >> As I have already reported in another reply to this thread, >> it is my first reboot after commenting out the line >> dns_domain_lo="mynetwork" >> and so far it went good. >> >> Moreover, the file /etc/resolv.conf has not been overwritten. >> >> I still have to check if everything else works fine and >> if I will get the same result on the next reboot >> but I hope that the problem has been solved. >> >> But it looks like a bug in the net csript. >> Why lo configuration should overwrite eth0 configuration at all? > > > I would consider it be a documentation bug at the very least. Being able to > propagate different settings to resolv.conf depending on whether a given > interface is up may be of value for some esoteric use-case, although I > cannot think of one off-hand. Some other distros use the resolvconf > application to handle these nuances. > > In any case, it is inexplicable that the user is invited to define > dns_domain for the lo interface. Why would one want to push settings to > resolv.conf based on the mere fact that the loopback interface has come up? > Also, it would be a great deal less confusing if the option were named > dns_search. > > I think that the handbook should refrain from mentioning the option at all, > for the reasons stated in my previous email. Those who know that they need > to define a specific search domain will know why and be capable of figuring > it out. > > It's too bad that the handbook is still peddling the notion that this > somehow has something to do with 'setting' the domain name. It is tosh of > the highest order. I agree with you. But how to put it all in the right ears?