On Sat, Feb 11, 2012 at 08:16:57PM -, Thomas Hood wrote:
> Here's the next iteration of the proposal.
> 1) /etc/resolv.conf contains no nameserver information => exit
> 2) "Generated by NetworkManager" in /etc/resolv.conf => exit
> 3) /etc/network/interfaces contains "mapping" or "source" line
This algorithm seems rather complicated. With the split from #25, is
there any need for trying to figure out whether or not to do all these
checks?
Why not do the split from #25 unconditionally. I can only see negative
impact from not including old information. With #25, I can see no
negative impa
Here's the next iteration of the proposal.
1) /etc/resolv.conf contains no nameserver information => exit
2) "Generated by NetworkManager" in /etc/resolv.conf => exit
3) /etc/network/interfaces contains "mapping" or "source" lines => append
4) /etc/network/interfaces contains a logical interface d
** Changed in: resolvconf (Ubuntu Precise)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923685
Title:
New resolver package overwrites manually created resolv.c
We should grep for "dns-nameservers" and not just for "dns-" in step 5
in the algorithm.
The algorithm will still fail in a case like this:
=== /e/n/i ===
auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
iface foo inet static
dns-nameservers 1.2.3.4
===
indeed, 3) won't match either 4) or 5) and so will be caught by 6)
giving the same result
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923685
Title:
New resolver package overwrites manually created
Re: comment #22
Ik looks as if you can omit step 3 in your algorithm.
Either way, your algorithm seems to be equivalent to my "proposal #2"
from comment #16. Good sign that we came up with the same set of
conditions.
I'll comment further once I get back to my laptop (now on my way to the
FOSDEM
After a bit of discussion with Steve on IRC, we decided that we don't want to
prompt the user, even in the weirdest scenario.
Instead, I developed the following list of criteria to determine whether or not
to link the current resolv.conf to tail:
1) If "Generated by NetworkManager" in /etc/reso
** Changed in: resolvconf (Ubuntu Precise)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923685
Title:
New resolver package overwrites manually created resolv.con
** Changed in: resolvconf (Ubuntu Precise)
Assignee: (unassigned) => Canonical Foundations Team
(canonical-foundations)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923685
Title:
New resolver
This system was initially running Natty and installed with d-i. The file
/etc/network/interfaces was changed to be static. Everything worked.
The machine was then upgraded to Oneiric and still working. Then
upgraded to Precise and hit by this defect.
It is critical because the configuration of th
Hmm, Jean-Baptiste, could you give a bit more details on how that system
was initially installed?
My understanding is that upgrade works fine if it's a desktop install
with Network Manager or if it was installed with debian-installer and
had a static config.
If you installed the machine using DHC
This bug has been reported on the Ubuntu ISO testing tracker.
A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/924734
** Tags added: iso-testing
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
setting to critical. After an upgrade of a working system from Oneiric
to Precise, it is unable to do DNS resolution.
** Tags added: dist-upgrade qa-manual-testing rls-mgr-p-tracking
** Also affects: resolvconf (Ubuntu Precise)
Importance: High
Status: Confirmed
** Changed in: resolvco
Steve wrote:
> Ubuntu policy prohibits debconf prompting [...]
1. OK, no prompting. :)
If we don't debconf-prompt then what's the best way of letting the admin
know that she should edit /e/n/i?
> (AFAICS, the proposal above would result in prompts
> for any desktop system that is using NM ex
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: resolvconf (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923685
Title:
On Mon, Jan 30, 2012 at 07:53:00PM -, Thomas Hood wrote:
> Can we boil the proposal down to this?:
> If there is nameserver information in the original /etc/resolv.conf and
> there is no physical interface marked "auto" in /e/n/i for which there
> is a logical interface definition in /e/n/i th
Thomas Hood wrote:
> interfaces(5):
>
> Read the passages on mapping.
Ok, point taken. It is much much more complicated than I believed. Guess
I need to anticipate beyond Linux.
>> [...]
>> Would that break the system?
> And listing an obsolete nameserver address only has the effect of delaying
> Not sure I understand the difference here.
interfaces(5):
Lines beginning with the word "auto" are used to identify
the physical interfaces to be brought up when ifup is run
with the -a option.
[...]
Stanzas defining logical interfaces start with a line
consisting of th
Stefan Bader wrote in #11:
> Seems network manager is in charge (according to
> the comment in e/n/i). Is it expected to have resolv.conf
> not as a link to /run?
See https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/922677
especially comments 2 and 4.
--
You received this bug notificati
Hate to spoil this bug and I probably should open a new one. Doing
orchestra install tests I got the following from a fresh precise (seed
modified to install ubuntu-desktop) install yesterday:
ii resolvconf 1.63ubuntu6
name server information handler
$ ls -la /etc/res
Thomas Hood wrote:
> Worry: Physical interfaces are marked "auto" but the "dns-" fields are in
> logical interface
> stanzas. So we have to assume that only logical interface stanzas are used
> that are named
> like the corresponding physical interface.
Not sure I understand the difference here.
> it fails saying (in effect) that /run/resolvconf does not exist
Please compare
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/922491
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923685
I'm not sure whether this is related to this or not. I was about to
raise a bug for it, but thought I'd comment here in case it is related
to something someone did recently in regards to this bug. Here's my
scenario:
I'm using oneiric-mini.iso to install from a local ubuntu mirror (more
like a cac
Stefan Bader wrote in #2:
> Would it be an option to do nothing (not touch resolv.conf)
> if there is neither an active interface with dhcp nor
> dns-server lines in /etc/network/interfaces?
The aforementioned "link-tail-to-original" approximates this.
Stéphane Graber wrote in #5:
> the exact f
Thinking about the debconf message: I think this would be ok for me as
sort of occasionally affected. And maybe it would be ok as it would warn
any admin to action before a upgrade on a server farm. Or they go mental
(and if we are unlucky on us).
So anything automatic might be better. Writing dow
Right, so after talking with Stefan on IRC, the exact failing case is:
1) Installed system through debian-installer using DHCP configuration (choosing
static there would have added the dns- fields)
2) Post-install, turned the system into static network configuration
3) Upgraded from Oneiric to Pre
This happened because this is based on a d-i install back on Oneiric.
That did make a dhcp setup which was manually changed into one with a
static IP.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/9236
The real bug here seems to be why netcfg didn't put the dns- lines in
/etc/network/interfaces because it has code to do it and definitely
should have done it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/b
Some choice at least would draw the attention. Though it is hard to say
whether this would be seen as nuisance. For a fresh install I would
assume the installer sets things up. At least after that there is enough
information in the created file to alert anyone touching it. Must admit
I don't know w
This has always been a shortcoming in the resolvconf package: it does
not do a fully automatic installation. The case Stefan Bader describes
in this report is the most important lacuna: the package does not add
information to /etc/network/interfaces.
Until now we have dealt with this by adding wa
** Changed in: resolvconf (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923685
Title:
New resolver package overwrites manually created resolv.conf on server
32 matches
Mail list logo
