| 1 |
On 28/07/2014 16:34, Grand Duet wrote: |
| 2 |
> 2014-07-28 1:00 GMT+03:00 Kerin Millar <kerframil@×××××××××××.uk>: |
| 3 |
>> On 27/07/2014 21:38, Grand Duet wrote: |
| 4 |
>>> |
| 5 |
>>> 2014-07-27 22:13 GMT+03:00 Neil Bothwick <neil@××××××××××.uk>: |
| 6 |
>>>> |
| 7 |
>>>> On Sun, 27 Jul 2014 13:33:47 +0300, Grand Duet wrote: |
| 8 |
>>>> |
| 9 |
>>>>>> That's what replaces it when eth0 comes up. |
| 10 |
>>>>>> It looks like eth0 is not being brought up fully |
| 11 |
>>>>> |
| 12 |
>>>>> |
| 13 |
>>>>> It sounds logical. But how can I fix it? |
| 14 |
>>>> |
| 15 |
>>>> |
| 16 |
>>>> By identifying how far it is getting and why no further. |
| 17 |
>>>> But it appears that eth0 is being brought up correctly |
| 18 |
>>>> and then the config is overwritten by the lo config. |
| 19 |
>>> |
| 20 |
>>> |
| 21 |
>>> I think so. |
| 22 |
>>> |
| 23 |
>>> As I have already reported in another reply to this thread, |
| 24 |
>>> it is my first reboot after commenting out the line |
| 25 |
>>> dns_domain_lo="mynetwork" |
| 26 |
>>> and so far it went good. |
| 27 |
>>> |
| 28 |
>>> Moreover, the file /etc/resolv.conf has not been overwritten. |
| 29 |
>>> |
| 30 |
>>> I still have to check if everything else works fine and |
| 31 |
>>> if I will get the same result on the next reboot |
| 32 |
>>> but I hope that the problem has been solved. |
| 33 |
>>> |
| 34 |
>>> But it looks like a bug in the net csript. |
| 35 |
>>> Why lo configuration should overwrite eth0 configuration at all? |
| 36 |
>> |
| 37 |
>> |
| 38 |
>> I would consider it be a documentation bug at the very least. Being able to |
| 39 |
>> propagate different settings to resolv.conf depending on whether a given |
| 40 |
>> interface is up may be of value for some esoteric use-case, although I |
| 41 |
>> cannot think of one off-hand. Some other distros use the resolvconf |
| 42 |
>> application to handle these nuances. |
| 43 |
>> |
| 44 |
>> In any case, it is inexplicable that the user is invited to define |
| 45 |
>> dns_domain for the lo interface. Why would one want to push settings to |
| 46 |
>> resolv.conf based on the mere fact that the loopback interface has come up? |
| 47 |
>> Also, it would be a great deal less confusing if the option were named |
| 48 |
>> dns_search. |
| 49 |
>> |
| 50 |
>> I think that the handbook should refrain from mentioning the option at all, |
| 51 |
>> for the reasons stated in my previous email. Those who know that they need |
| 52 |
>> to define a specific search domain will know why and be capable of figuring |
| 53 |
>> it out. |
| 54 |
>> |
| 55 |
>> It's too bad that the handbook is still peddling the notion that this |
| 56 |
>> somehow has something to do with 'setting' the domain name. It is tosh of |
| 57 |
>> the highest order. |
| 58 |
> |
| 59 |
> I agree with you. But how to put it all in the right ears? |
| 60 |
> |
| 61 |
|
| 62 |
I'm not entirely sure. I'd give it another shot if I thought it was |
| 63 |
worth the effort. My experience up until now is that requests for minor |
| 64 |
documentation changes are dismissed on the basis that, if it does not |
| 65 |
prevent the installation from being concluded, it's not worth bothering |
| 66 |
with [1]. I do not rate the handbook and, at this juncture, my concern |
| 67 |
is slight except for where it causes demonstrable confusion among the |
| 68 |
user community. Indeed, that's why my interest was piqued by this thread. |
| 69 |
|
| 70 |
--Kerin |
| 71 |
|
| 72 |
[1] For example: bugs 304727 and 344753 |
Archives