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 25E7213877A for ; Wed, 30 Jul 2014 22:23:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3B489E0917; Wed, 30 Jul 2014 22:23:03 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2EF57E08FA for ; Wed, 30 Jul 2014 22:23:02 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by gateway1.nyi.internal (Postfix) with ESMTP id 2B0C025AE4 for ; Wed, 30 Jul 2014 18:22:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 30 Jul 2014 18:22:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.co.uk; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=dUVi9QKeulQWhPKJ+KjzKf08dE8=; b=EKdqr90pjudKs+ktCEUPwLf5emsl XcwibqnGkS7U3UXxxK1AZPnAwZ6vQ7fKMocxmG3Pf/HF6XjQMlZUUS1XbDxYXBUp GAgC2bsbNFOWXWnTqaY10rq7rTuWQyeXvKTaPGPIC5bp/a2FlDFbkxzSpS2jIyn3 5Fq/LoRKSPTudAE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=dUVi9QKeulQWhPKJ+KjzKf 08dE8=; b=eHyL78PVhnnNe+MhVDaQ74b9CKT1MEhqLM1DSRn+JWbW4LbvOJLX/Y sClFbCWB1m0NoeWQeZpDdu1C6RiGii9i+ATTqIwXqX7XU+Gmoo/m4YsO6AulGVAC lNBrYAH/Vg4M98yo4QyhqD/nMF4FvVHPlcJtyc+SvirzUaecK4b0g= X-Sasl-enc: W2/elbGpvw70Ju2/nMCxREXH4nJVOxJWjwyj8fhKSPE+ 1406758971 Received: from [192.168.1.146] (unknown [77.101.146.254]) by mail.messagingengine.com (Postfix) with ESMTPA id C3A0CC0000C for ; Wed, 30 Jul 2014 18:22:51 -0400 (EDT) Message-ID: <53D97038.3010609@fastmail.co.uk> Date: Wed, 30 Jul 2014 23:22:48 +0100 From: Kerin Millar User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20140623 FossaMail/24.6.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] resolv.conf is different after every reboot References: <20140727102923.7229724e@hactar.digimed.co.uk> <20140727201322.3397d2f4@digimed.co.uk> <53D57670.3090007@fastmail.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 8c40e583-8c7a-4e44-aca2-fbfedfb1062f X-Archives-Hash: 1639db9cee776c9cf58a3d1eb5783229 On 28/07/2014 16:34, Grand Duet wrote: > 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? > I'm not entirely sure. I'd give it another shot if I thought it was worth the effort. My experience up until now is that requests for minor documentation changes are dismissed on the basis that, if it does not prevent the installation from being concluded, it's not worth bothering with [1]. I do not rate the handbook and, at this juncture, my concern is slight except for where it causes demonstrable confusion among the user community. Indeed, that's why my interest was piqued by this thread. --Kerin [1] For example: bugs 304727 and 344753