resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines up from /etc/network/interfaces

Bug #448095 reported by PC
272
This bug affects 49 people
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
Won't Fix
Undecided
Unassigned
Nominated for Lucid by Simon Huerlimann
resolvconf (Ubuntu)
Confirmed
Undecided
Unassigned
Nominated for Lucid by Simon Huerlimann

Bug Description

Binary package hint: resolvconf

ifdown -a ; ifup -a fixes the problem after a reboot.

ProblemType: Bug
Architecture: i386
Date: Sat Oct 10 17:55:06 2009
DistroRelease: Ubuntu 9.10
Package: resolvconf 1.44ubuntu1
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-13.43-generic
SourcePackage: resolvconf
Uname: Linux 2.6.31-13-generic i686

Revision history for this message
PC (pieter-claassen) wrote :
Revision history for this message
Anders Kaseorg (andersk) wrote :

Yeah, apparently ifupdown starts before resolvconf now.

Changed in resolvconf (Ubuntu):
status: New → Confirmed
tags: added: ubuntu-boot
removed: i386
Anders Kaseorg (andersk)
summary: - On reboot, resolvconf does not pick the dns-nameserver and dns-search
- lines up from /etc/network/interfaces. That means you have not DNS
+ resolvconf starts after ifupdown, does not pick the dns-nameserver and
+ dns-search lines up from /etc/network/interfaces
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Obvious fix is to resolvconf, e.g. by porting to upstart you could "start on starting network-interface"

Changed in ifupdown (Ubuntu):
status: New → Won't Fix
Revision history for this message
Wladimir Mutel (mwg) wrote :

The crude fix is usual, similar to LP:366967 :
in the file '/etc/init/network-interface.conf'
comment out the line 'exec ifup --allow auto $INTERFACE'

works for me and my resolvconf, so far.

Anders Kaseorg (andersk)
tags: added: regression-potential
tags: added: regression-release
removed: regression-potential
Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Hi,

I made an upstart script, like Scott suggested, which initialises the resolvconf directory structure. I have it start pre-udev, so it's sure to fire before ifup. It replaces the sysv link in rcS.d, but I also made some changes to resolvconf itself, basically I moved the resolvconf run directory to /lib/init/rw/, to have the earliest available writable filesystem from the start of the boot process.

Anyway, the upstart script is attached, and put the following lines in /sbin/resolvconf

[ -e /etc/default/resolvconf ] && . /etc/default/resolvconf
RUN_DIR=${RESOLVCONF_RUNDIR:=/lib/init/rw/resolvconf}

(uncomment the old RUN_DIR line of course)

and in /etc/resolvconf/update.d/libc :

[ -e /etc/default/resolvconf ] && . /etc/default/resolvconf
DYNAMICRSLVCNFFILE="${RESOLVCONF_RUNDIR:=/lib/init/rw/resolvconf}/resolv.conf"

(again uncomment the old var)

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

oh and symlink your /etc/resolv.conf to /lib/init/rw/resolvconf/resolv.conf !

Revision history for this message
Jürgen Kreileder (jk) wrote :

resolvconf actually should already use /lib/init/rw/resolvconf with /etc/resolvconf/run being a symlink to it. (At least for new installations, for upgraded systems I had to fix this manually).

Revision history for this message
Francis Russell (francis-russell) wrote :

I'm having difficulty understanding what this script accomplishes. If it it co-exists with the existing init script, then when '/etc/init.d/resolvconf start' does finally run, ${RUNDIR}/interface will be deleted again, which is not what we wanted.

If it's meant to act as a replacement for the start action of the init script, then it at also needs to perform the "update -i" action the original init script does to initialise all the things that listen to resolvconf updates.

I believe Scott was hoping that someone would port the entire resolvconf init script to upstart. In the resolvconf model (I believe) a service restart is considered to merely be a stop followed by a start. The problem with the resolvconf init script is that it makes a distinction between a boot-time start and a restart. Resolvconf will delete the contents of the interface directory on a boot-time start, but not on a restart. I think how to distinguish between the two is a question for the upstart developers as I think it's a requirement that exists outside their current use-cases. Someone please correct me if I'm wrong about this.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Hmm yeah I wasn't really clear in my prev post.

It definately obsoletes the old sysv init script, which should be removed.

The initialisation part is the most essential and moved to the upstart script. The other actions on the init script are really nothing more than calling (or not) 'update' on resolvconf, but as you can see from /sbin/resolvconf and /etc/init.d/resolvconf there is duplicated code there (and should all be moved to /sbin/resolvconf).

But you are right about the 'update -i', that should be added to the upstart script at initialisation.

You are also right about the difference in the old init script about boot-time start and service-restart later. A restart on the old initscript merely calls update. But since I know hardly any upstart specifics I don't know how to define the difference between init() and start() precisely.

The move to /lib/init/rw makes the difference less important though, since /lib/init/rw is clean after each boot, since it's not persistent. When using /etc/resolvconf/run you might encounter leftovers from previous boots, but with /lib/init/rw we could just create the resolvconf structure if it's not there yet, and have subsequent calls to stop/start/restart mimic the old initscript behaviour.

I can make a more complete upstart script if anyone's interested?

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Jürgen, you mean this should be the case in 9.10 or 10.04 ?

Revision history for this message
dinar qurbanov (qdinar) wrote :

hello. firefox and empathy do not work, though ping and host commands work. my internet is set with pppoeconf and is set to connect automatically. currently i fix this with sudo poff dsl-provider and then sudo pon dsl-provider. what is better way?

probably this is because this bug.

Revision history for this message
dinar qurbanov (qdinar) wrote :

by the way i was going to report bug , report bug link in https://bugs.launchpad.net/ubuntu redirects to https://help.ubuntu.com/community/ReportingBugs i tried to click that buttin in firefox but it is going to send many unneeded things. impossibility to fill bug report in site is quite big bug, i think.
but fortunately i have seen this bug and this is like what i wanted to report.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

q.dinar, probably not the same bug, since resolving works for you with ping and host

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Ok I made the upstart script 'restartable', and unified more hardcoded paths into /sbin/resolvconf

- the initialisation of the rundir can now be forced with /sbin/resolvconf -i, and is automatically done by the upstart script when no valid structure is found
- starting and stopping the service now sets the enabled/disabled state via /sbin/resolvconf.
- triggering an update is now only done using /sbin/resolvconf -u
- the rundir can now be queried using /sbin/resolvconf -r

So basically this solves the bug, and also cleans up the scattered resolvconf initialisation

There are probably other scripts in /etc/resolvconf/update.d that still need RW access to other parts of the filesystem, but these updates can be done later in the bootprocess, e.g. calling a resolvconf -u before bind is started, or after /var becomes writable or something similar. I so far only tested the lifecycle of the libc resolver.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :
Revision history for this message
dinar qurbanov (qdinar) wrote :

i have tried to
"in the file '/etc/init/network-interface.conf'
comment out the line 'exec ifup --allow auto $INTERFACE' "
but in my case this has not helped.

Sander van Grieken, should i try your files? where is located resolvconf.conf ?

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

resolvconf.conf should be saved in /etc/init

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

but still, this is probably not the bug you suffer from..

Revision history for this message
TrReardon (tr-reardon) wrote : Re: [Bug 448095] Re: resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines up from /etc/network/interfaces

I've tried your fix Sander and it sort of works. Which is to say that
resolvconf properly runs at boot. HOWEVER, it does not run correctly on
ifdown/ifup:

$ sudo ifdown eth0
[sudo] password for reardon:
resolvconf: Error: /lib/init/rw/resolvconf/interface is not a directory
resolvconf: Error: /lib/init/rw/resolvconf/interface is not a directory
run-parts: /etc/network/if-down.d/resolvconf exited with return code 1
There is already a pid file /var/run/dhclient.eth0.pid with pid 1166
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:1d:92:a0:77:90
Sending on LPF/eth0/00:1d:92:a0:77:90
Sending on Socket/fallback
DHCPRELEASE on eth0 to 192.168.0.1 port 67
resolvconf: Error: /lib/init/rw/resolvconf/interface is not a directory
 * Reloading /etc/samba/smb.conf smbd only
   ...done.

$ sudo ifup eth0
Internet Systems Consortium DHCP Client V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:1d:92:a0:77:90
Sending on LPF/eth0/00:1d:92:a0:77:90
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 192.168.0.198 from 192.168.0.1
DHCPREQUEST of 192.168.0.198 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.0.198 from 192.168.0.1
 * Reloading /etc/samba/smb.conf smbd only
   ...done.
resolvconf: Error: /lib/init/rw/resolvconf/interface is not a directory
bound to 192.168.0.198 -- renewal in 2147483648 seconds.
resolvconf: Error: /lib/init/rw/resolvconf/interface is not a directory
run-parts: /etc/network/if-up.d/000resolvconf exited with return code 1

+Reardon

On Thu, Dec 24, 2009 at 6:47 AM, Sander van Grieken <sander@3v8.net> wrote:

> but still, this is probably not the bug you suffer from..
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/interfaces
> https://bugs.launchpad.net/bugs/448095
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitecture: all
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-13.43-generic
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/448095/+subscribe
>
>

Revision history for this message
TrReardon (tr-reardon) wrote :

I created the directory /lib/init/rw/resolvconf/interface by hand. But no
idea what should go in here. The whole point of installing resolvconf in
the first place was so that vpn clients would work properly (in my case,
vpnc). But no updates to resolv.conf are made when I connect with vpnc
(this did work with the original script, though the boot case was broken).

+Reardon

On Thu, Dec 24, 2009 at 2:02 PM, TR Reardon <email address hidden>wrote:

> I've tried your fix Sander and it sort of works. Which is to say that
> resolvconf properly runs at boot. HOWEVER, it does not run correctly on
> ifdown/ifup:
>
>

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

You should use the /sbin/resolvconf from #17. I made a stupid mistake in the one I posted first.

There's no need to create /lib/init/rw/resolvconf/interface by hand. It should be created at boot, or by calling /sbin/resolvconf -i as root.

Revision history for this message
dinar qurbanov (qdinar) wrote :

in my case also ping ya.ru does not work, but host ya.ru and then ping ip address works.

Revision history for this message
TrReardon (tr-reardon) wrote :

Your solution did not work on reboot. Now when I try ''sudo resolvconf -i'
I get a different error

$ sudo resolvconf -i
mkdir: cannot create directory `': No such file or directory
resolvconf: Error: unable to create

+Reardon

On Fri, Dec 25, 2009 at 11:30 AM, Sander van Grieken <sander@3v8.net> wrote:

> You should use the /sbin/resolvconf from #17. I made a stupid mistake in
> the one I posted first.
>
> There's no need to create /lib/init/rw/resolvconf/interface by hand. It
> should be created at boot, or by calling /sbin/resolvconf -i as root.
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/interfaces
> https://bugs.launchpad.net/bugs/448095
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitecture: all
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-13.43-generic
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/448095/+subscribe
>
>

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Did you redownload the /sbin/resolvconf replacement? Can you confirm there are no
differences between your copy and the attachment? Because you report the same error the
first /sbin/resolvconf replacement I posted had, and I cannot reproduce your current error
with the current one.

Revision history for this message
TrReardon (tr-reardon) wrote :

My mistake this time. It's working properly now with your updated
/sbin/resolvconf

+Reardon

On Sat, Dec 26, 2009 at 7:16 AM, Sander van Grieken <sander@3v8.net> wrote:

> Did you redownload the /sbin/resolvconf replacement? Can you confirm there
> are no
> differences between your copy and the attachment? Because you report the
> same error the
> first /sbin/resolvconf replacement I posted had, and I cannot reproduce
> your current error
> with the current one.
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/interfaces
> https://bugs.launchpad.net/bugs/448095
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitecture: all
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-13.43-generic
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/448095/+subscribe
>
>

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Found one more tiny bug. fixed it and replaced /sbin/resolvconf attachment.

Revision history for this message
TrReardon (tr-reardon) wrote :

Ok, I've tried with all your latest, and basically nothing has changed, it's
all still broken. On system boot, resolv.conf remains blank (or rather, it
is created, but with no entries, only the top comment lines).

ifdown/ifup fixes the problem. Same as the Ubuntu release problem.

Have you tried with vpnc or similar tunnel installed?

Does anything from /sbin/resolvconf get logged that I can read or send to
you?

+Reardon

On Sat, Dec 26, 2009 at 7:11 PM, Sander van Grieken <sander@3v8.net> wrote:

> Found one more tiny bug. fixed it and replaced /sbin/resolvconf
> attachment.
>
>
> ** Attachment added: "/sbin/resolvconf"
> http://launchpadlibrarian.net/37215643/resolvconf
>
> ** Attachment removed: "replacement for /sbin/resolvconf"
> http://launchpadlibrarian.net/37141756/sbin.resolvconf
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/interfaces
> https://bugs.launchpad.net/bugs/448095
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitecture: all
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-13.43-generic
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/448095/+subscribe
>
>

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

ok, time for a full checklist :)

- update /sbin/resolvconf from bug attachment
- update /etc/resolvconf/update.d/libc from bug attachment
- install /etc/init/resolvconf.conf from bug attachment
- remove /etc/rcS.d/S07resolvconf
- make sure /etc/resolv.conf symlinks to /lib/init/rw/resolvconf/resolv.conf

vpn or tunnelling should work as good as before. Nothing has changed for 'late' connections.

debugging is a bit hard, but you can see the non-zero exit code if you boot in rescue mode.

Revision history for this message
TrReardon (tr-reardon) wrote :

I think the problem is that there is a significant post-boot delay before
resolv.conf is updated. It took ~ 90sec (after gdm start) on last boot.
But at least it's working

+Reardon

On Mon, Dec 28, 2009 at 5:11 AM, Sander van Grieken <sander@3v8.net> wrote:

> ok, time for a full checklist :)
>
> - update /sbin/resolvconf from bug attachment
> - update /etc/resolvconf/update.d/libc from bug attachment
> - install /etc/init/resolvconf.conf from bug attachment
> - remove /etc/rcS.d/S07resolvconf
> - make sure /etc/resolv.conf symlinks to
> /lib/init/rw/resolvconf/resolv.conf
>
> vpn or tunnelling should work as good as before. Nothing has changed for
> 'late' connections.
>
> debugging is a bit hard, but you can see the non-zero exit code if you
> boot in rescue mode.
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/interfaces
> https://bugs.launchpad.net/bugs/448095
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitecture: all
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-13.43-generic
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/448095/+subscribe
>
>

Changed in resolvconf (Ubuntu):
assignee: nobody → MOTU (motu)
Revision history for this message
Wladimir Mutel (mwg) wrote :

It feels somewhat strange that resolvconf is relegated to 'universe' in Ubuntu.
In Debian, its role is pretty infrastructural. And it is quite closely related with ifupdown.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Yes I thought that too, Universe is not the place for resolvconf.

But anyway, it seems no one from Ubuntu is interested in this bug?

Revision history for this message
dinar qurbanov (qdinar) wrote :

bug report about my case: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/500735 "
pppoeconf autoconnect does not work fully in ubuntu 9.10".

Revision history for this message
Will (will-berriss) wrote :

Just to say I have this bug too. :(

Symptom:

After a reboot, /etc/resolv.conf contains only this:

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
nameserver 10.18.4.3
nameserver 10.18.4.1

There is no search domain, yet I specified it in /etc/network/interfaces as follows:

dns-nameservers 10.18.4.3 10.18.4.1
dns-search blah.co.uk fudd.co.uk

However, if I now issue the following command :

$ sudo /etc/init.d/networking restart

It fixes /etc/resolv.conf, as per this:

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search blah.co.uk fudd.co.uk
nameserver 10.18.4.3
nameserver 10.18.4.1

Can't wait till this is fixed.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote : Re: [Bug 448095] Re: resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines up from /etc/network/interfaces

Yeah I'm actually stunned that such a design failure is not acted upon by Ubuntu. Guess
they just capitalize on the work done by Debian, without having to do the hard work of
actually maintaining a distribution.

However this bug MUST sting on servers and 'old-school' people that use
/etc/network/interfaces instead of NetworkManager, not to mention all the HOWTOs on the
net that suggest solutions involving /etc/network/interfaces.

Just apply the new versions of resolvconf files attached to the bug and your problems will
be gone, at least until the upgrade to 10.04 :-/

I myself am moving to Debian ASAP

grtz,
Sander

On Sunday 07 February 2010 10:25:55 you wrote:
> Just to say I have this bug too. :(
>
> Symptom:
>
> After a reboot, /etc/resolv.conf contains only this:
>
> $ cat /etc/resolv.conf
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
> OVERWRITTEN nameserver 127.0.0.1
> nameserver 10.18.4.3
> nameserver 10.18.4.1
>
> There is no search domain, yet I specified it in /etc/network/interfaces
> as follows:
>
> dns-nameservers 10.18.4.3 10.18.4.1
> dns-search blah.co.uk fudd.co.uk
>
>
> However, if I now issue the following command :
>
> $ sudo /etc/init.d/networking restart
>
> It fixes /etc/resolv.conf, as per this:
>
> $ cat /etc/resolv.conf
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
> OVERWRITTEN nameserver 127.0.0.1
> search blah.co.uk fudd.co.uk
> nameserver 10.18.4.3
> nameserver 10.18.4.1
>
> Can't wait till this is fixed.

Revision history for this message
Bruce Miller (brm0423) wrote :

Duplicate Bug #548576 reports this same problem in Kubuntu Lucid Lynx Beta 1 amd64 daily disks of 2010-03-25 and 2010-03-27.

On this network, individual hosts are set up to use DHCP and individual nameservers are not listed in /etc/network/interfaces. Predictable IP addresses are assigned by the router based on adapter MAC addresses; from the position of the host, this is a DHCP configuration.

Circumstances leading to triggering this bug were unusual:

The "install software" step of the installation process failed. (See Bug #548572; probable cause: failure of command: apt-cdrom add )

At the reboot after install, very little software was installed. Although I am not an IT professional and thus inexpert in these matters, I suspect that dhclient read the nameserver data from the router and used it to populate /etc/resolv.conf

I then installed the entire set of packages from a list which I keep routinely updated (using dpkg --set-selections < <listname>. I suspect that that process installed NetworkManager. During the same session, I also installed the proprietary video driver.

The video driver necessitated a further reboot. At this point, /etc/resolv.conf was empty. I had only local network connectivity. None to the internet.

I have worked around the problem by saving the original resolv.conf to a separate file, and running a three-line script to copy it back, and restart networking. I count this as hands-down my ugliest kludge in 28 years of breaking development software.

Revision history for this message
Mathieu Marquer (slasher-fun) wrote :

Also affects me on a machine installed with Ubuntu Lucid Alternate AMD64 beta 1. On each start, the file /etc/resolv.conf is empty although dns-servers are correctly specified in /etc/network/interfaces. If I run "sudo ifdown eth0 && sudo ifup eth0", /etc/resolv.conf gets its normal content from /etc/network/interfaces.

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

I've created a resolvconf package incorporating the fixes to port resolvconf to upstart from Sander van Grieken. It's available from my PPA at https://launchpad.net/~huerlisi/+archive/ppa.

Please test if it works as expected and give feedback if not.

@Ubuntu guys: tell me what to do to enhance the changes of this (or another) fix being added to Lucid.

Revision history for this message
Anders Kaseorg (andersk) wrote :

Simon: Your resolvconf “1.45ubuntu1ppa1” is actually version 1.44, which seems … really odd. A patch that reverts all the changes between 1.44 and 1.45 as a side effect is certainly not going to make it into Lucid. You’ll need to post a clean debdiff against the current Lucid package with no extraneous changes before it can be considered.

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

Andres: You're absolutely right. I've just created a "correct" karmic package, but was in need for a fixed package for lucid an hour ago. My "fix" was to just bump the package version to get it built on lucid.

Will work on an updated lucid package and repost. The karmic package should be okay to test, though.

Revision history for this message
Anders Kaseorg (andersk) wrote :

FYI, you can install a particular version of a package (even if it is a downgrade) by running
  sudo aptitude install resolvconf=1.44ubuntu1ppa2
There is no need to artificially inflate the package’s version number.

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

Anders: Thank you for the tip! A "rebased" version is currently building/publishing in my PPA. Should soon be available.

Changes to 1.44ubuntu1ppa2:
* using 1.45ubuntu1 as base
* cleaning up debian/changelog to only have one new version
* using LP: instead of Closes: to close Launchpad bug, not Debian bug ;-)

Will attach debdiff.

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

Mmh, just found a bug, please wait for ...ppa3 before testing. Sorry

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

Okay, uploaded resolvconf-1.45ubuntu1ppa4 to my PPA. Will take a few minutes 'till it's published.

Changes to resolvconf-1.45ubuntu1ppa2:
* added /sbin/resolvconf version by Sander van Grieken (which was forgotten in last upload)
* updated postinst and prerm to directly use resolvonf to enable/disable updates instead of init.d/resolvconf

I did have a look at the changes Sander did to /sbin/resolvconf. They seem sensible as they mostly move enable/disable functionality from the now "absent" init.d script to resolvconf.

Revision history for this message
Simon Huerlimann (huerlisi) wrote :
Revision history for this message
Simon Huerlimann (huerlisi) wrote :

@Ubunteros: can I do anything to get this in for Lucid? Look out for a sponsor, do some bikesheding on the package, anything?

Lucid is a LTS release and expected to be more stable than other releases. And this is a genuine regression compared to the last LTS. I understand that resolvconf is in universe and not part of the supported core, and that's the reason why I try to help out.

So I repeat my request: Please give me any hints on how to enhance the chances of this (or another) fix be included in Lucid.

Thanx for this great distribution, anyway;-)

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

Maybe someone with the necessary right could raise the importance of this bug. I mean, this bug makes resolvconf doing DOS on LTS upgrades from hardy, but even bug #60518 did get 'medium'.

I also did some bug triaging to make this one stand out more;-)

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Thanks Simon for packaging this for Lucid, much appreciated.

My currently installed resolvconf package notes the following contacts as maintainers:
Maintainer: Ubuntu MOTU Developers <email address hidden>
Original-Maintainer: resolvconf maintainers <email address hidden>

So... you could try sending a notification to the MOTU devs, but they should have been made aware through this launchpad system already. The whole MOTU thing looks like a catchall anyway, so I think resolvconf in Ubuntu is just a Debian copypaste job. They should rename to COTU (Copy Of The Upstream). I think you'll have more luck contacting the debian maintainer...

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

I just upgraded to lucid and installed your PPA package.

Of course I forgot to check the situation before installing your PPA package, but anyway, I ended up with a different /etc/resolv.conf link. A quick check reveals that the postinst script in the deb is (re)creating the link to /etc/resolvconf/run. In the top of postinst however it is said that /lib/init/rw is now used, but it seems the rest of the script doesn't agree.

Also in postinst is some initialization of the resolvconf directories that should now be done by /sbin/resolvconf.

Anyway, I restored the link and everything works as it should, thanks!

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

Hi Sander

Thanks for the report. Will check, fix, release. (Hopefully... ;-)

Revision history for this message
Wladimir Mutel (mwg) wrote :

Ubuntu 10.04 : misbehaviour is still present. Hope to see resolvconf better integrated with ifupdown&upstart in the near future .

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

@Sander: took much longer to find some time to fix the /lib/init/rw vs. /var/lib bug. The postinst script is full of checks to handle all kinds of setups. Not sure how much of that is really needed. But as I don't get the idea of all of it, I just leave it. Regarding the comment in the beginning about /lib/init/rw: a few lines below, there is a copy of the same comment with another comment saying it is not valid for ubuntu, as ubuntu provides an early tmpfs... Well, I guess it wouldn't hurt to stay closer to Debian and use /lib/init/rw anyway. I haven't found time to check the initialization part you mentioned...

@Wladimir Mutel: Yes, the resolvconf package in Lucid still has this nasty bug. But Sander van Grieken did code up an upstart based version of it, and I did some packaging.

You may try my package from my PPA at https://launchpad.net/~huerlisi/+archive/ppa. Comments more than welcome.

Will try to mail the last maintainer of resolvconf about this and ask him to either release a fixed version or sponsor an upload of my package...

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Since I haven't been looking at this bug for a while, I'll just dump my ideas of what IMO should be done in the postinst (and maybe other) package scripts, before I forget them.

There's a couple of situations that should be handled:

a) installing resolvconf while being in a non-resolvconf state
b) upgrading resolvconf that has it's data in another place than the new resolvconf expects it to be (NOTE: which isn't necessarily /lib/init/rw! It's actual location is defined in /etc/default/resolvconf)

In situation A, the problem is that resolvconf doesn't have the information yet to populate resolv.conf, so it should not be activated until reboot, or at least until networking is restarted. It's of course possible to already set up the right /etc/resolv.conf symlink, but the active /etc/resolv.conf should be copied into resolvconf's symlink target file verbatim, and should not be re-generated by resolvconf (possibly by implicitly disabling updates). This is a problem that already exists with the 'official' resolvconf, so it's not a new problem.

In situation B I think we should copy the 'interfaces' folder from the old location over to the new location, maybe in combination with some validity checks to see if the information there matches the active network interfaces. The place of the old location might be deduced from the /etc/resolv.conf symlink, and/or from the old default location under /var. Also maybe cleanup the files at the old location.

If I missed any other situations that might give rise to problems, please add them to this bugreport!

Revision history for this message
Jürgen Kreileder (jk) wrote :

resolvconf (1.45ubuntu1ppa5) karmic; urgency=low

  * Use /var/run in resolvonf binary.

 -- Simon Huerlimann (CyT) <email address hidden> Mon, 03 May 2010 00:27:16 +0200

Why RUN_DIR=${RESOLVCONF_RUNDIR:=/var/run}? Didn't you mean /var/run/resolvconf?
That's what your postinst and apparmor use.

Revision history for this message
Simon Huerlimann (huerlisi) wrote :

@Jürgen: Oops, my bad. Thank you! Fixed PPA upload is on the way...

@Sander: Sounds very reasonable. I have a hard time really understanding all the tests and checks the original postinst does:-( What you propose sounds like a straight and clean solution. I'll probably won't find the time to implement, though... It probably makes sense to forward your thoughts to the Debian BTS, as you said some time ago: Ubuntu doesn't seem to really care about this package...

Revision history for this message
Gabriel de Perthuis (g2p) wrote :

Here is my quick fix, it just moves resolvconf directory creation earlier and disables invocation from rcS.d since the init.d script doesn't support running twice:

sudo update-rc.d resolvconf disable

sudo tee /etc/init/earlier-resolvconf.conf <<'EOF'
description "Prepare resolvconf directory"
start on (starting network-interface
          or starting network-manager
          or starting networking)
pre-start script
    invoke-rc.d resolvconf start
end script
EOF

Revision history for this message
Kevin Hamer (khamer) wrote :

Gabriel's quick fix (#57) didn't work for me. Bug #550962 (marked as a duplicate of this bug) mentions adding

invoke-rc.d networking restart

to rc.local, so I'm going to try that. Rather frustrating, as this is even more problematic in ubuntu server, where NetworkManager isn't even an option.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Why not just install Simon's package?

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

@Simon: Hopefully Debian will pickup the changes that cleanup the hardcoded paths, but as I found out they don't use upstart, so those parts will be useless to them. So we're stuck with MOTU :)

If I find the time I'll take another look at the packaging scripts, so at least the symlink setup works more reliably..

Revision history for this message
Kevin Hamer (khamer) wrote :

I'll try out and update how Simon's package does with ubuntu server 10.04 tomorrow.

Changed in resolvconf (Ubuntu):
assignee: MOTU (motu) → nobody
Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Fabrice, can you at least add an explanation why you unassigned MOTU?

Do you mean this bug will be a WONTFIX?

Revision history for this message
Anders Kaseorg (andersk) wrote :

No, just that bugs should not in general be assigned to MOTU. They should be assigned to a specific person who is actively working on the bug (if any). As you can see, the bug is still Confirmed.

The next thing that needs to happen is that someone needs to propose a debdiff for sponsorship: a clean diff with no extraneous changes, and a single changelog block with an Ubuntu version number (not the version number that gets uploaded to a PPA), based on the current version in maverick.

Revision history for this message
Stefano Rivera (stefanor) wrote :

> The next thing that needs to happen is that someone needs to propose a debdiff for sponsorship

In that case, unsubscribing ubuntu-sponsors

tags: added: patch
Revision history for this message
Liraz (liraz-siri) wrote :

Many thanks to everyone who helped track down this regression, which effected TurnKey Linux users of the new TurnKey Core Lucid-based beta as well:

https://bugs.launchpad.net/turnkeylinux/+bug/596560

IMHO, for desktop usage upstart has great potential. But for servers it's a net loss. Booting a few seconds faster doesn't matter as much as stability and simplicity. I just wish there was some way to save all of this asynchronous cleverness for the desktop. In a few years once Ubuntu and Debian transition fully to upstart we should be OK, but now it's ugly out there.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

On Wednesday 15 September 2010 19:27:47 Liraz wrote:
> Many thanks to everyone who helped track down this regression, which
> effected TurnKey Linux users of the new TurnKey Core Lucid-based beta as
> well:
>
> https://bugs.launchpad.net/turnkeylinux/+bug/596560
>
> IMHO, for desktop usage upstart has great potential. But for servers
> it's a net loss. Booting a few seconds faster doesn't matter as much as
> stability and simplicity. I just wish there was some way to save all of
> this asynchronous cleverness for the desktop. In a few years once Ubuntu
> and Debian transition fully to upstart we should be OK, but now it's
> ugly out there.

Hmm I'm starting to doubt that, since many distributions are moving to systemd, and none
except Ubuntu (and derivatives) to upstart. This will likely mean that most upstream
projects will not take upstart into consideration, so Ubuntu alone will have to maintain
it. If this bug is any indication......

Revision history for this message
Liraz (liraz-siri) wrote :

Isn't Debian still planning on moving to upstart? If so that would be a major vote of confidence and would guarantee upstart sticks around for a while longer.

systemd looks very neat. That both RedHat and OpenSUSE are moving to adopt it is telling but I don't think it's very likely Ubuntu will give up upstart any time soon. More likely we'll see some borrowing of code and ideas. FWIW, SysVinit compatibility is the highest on my wishlist.

OTOH, if Debian decide to move to systemd all bets are off. In that case I hope Ubuntu does the right thing and chucks upstart out rather than increase Ubuntu's divergence from the rest of the Linux world.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

My apologies, I have to backtrack on my prev statement. I thought to have read that on LWN
some time in the past, but I cannot find such statement anymore through google.

Fact is, that Debian hasn't moved to upstart OR systemd (or initng for that matter) yet,
even in unstable, and is using insserv (optional) to parallelize the boot sequence. They
are still contemplating which direction to take.

see
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot and
http://lists.debian.org/debian-devel-announce/2009/09/msg00003.html

and the most recent announcement
http://lists.debian.org/debian-devel-announce/2010/05/msg00009.html

.. where upstart is described as 'the most promising candidate'.

Again, sorry for the confusion :)

On Monday 27 September 2010 11:52:48 you wrote:
> Isn't Debian still planning on moving to upstart? If so that would be a
> major vote of confidence and would guarantee upstart sticks around for a
> while longer.
>
> systemd looks very neat. That both RedHat and OpenSUSE are moving to
> adopt it is telling but I don't think it's very likely Ubuntu will give
> up upstart any time soon. More likely we'll see some borrowing of code
> and ideas. FWIW, SysVinit compatibility is the highest on my wishlist.
>
> OTOH, if Debian decide to move to systemd all bets are off. In that case
> I hope Ubuntu does the right thing and chucks upstart out rather than
> increase Ubuntu's divergence from the rest of the Linux world.
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines
up from /etc/network/interfaces
> https://bugs.launchpad.net/bugs/448095
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

I just upgraded one of my systems to Maverick, and the bug seems to be solved out-of-the-box there.

However, it seems that they just dropped in the upstart script from this bug without much thinking, resulting in somewhat of a mutant resolvconf, because
a) the upstart script assumes the modified /sbin/resolvconf from this bug, i.e. it gets called with -r -i --enable-updates --dsiable-updates options, but the provided /sbin/resolvconf is not aware of these options.
b) there's a link to start resolvconf from /etc/rcS.d, while there's also an upstart script (?!). The fact that /etc/init.d/resolvconf is 'upstardized' probably prevents it from doing double initialisation, but the link from /etc/rcS.d is not necessary.

Third, resolvconf's data has been moved again back to /etc/resolvconf/run, forcing the need for a writable rootfs.

So, it works at boot, but there's no enabling/disabling updates (start/stop resolvconf service) and no initialisation of the volatile directory structure by /sbin/resolvconf itself. This directory structure is probably instead prepared during install by the packaging scripts.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Ehh? Changelog of resolvconf doesn't match reality?
Or am I looking in the wrong spot?

https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/resolvconf/maverick

* Merge from debian unstable (LP: #605116), remaining changes:
   - bin/resolvconf:
     + fail with non-zero exit code when /etc/resolv.conf is not a symlink.
   - debian/postinst:
     + use default /var/run.
     + make sure all run files are sent to /var/run, not /lib/init/rw
     + update regex to check that /var/run is a tmpfs (LP: #386822)
     + fix typo in comments
   - debian/rules:
     + don't install the init script in runlevels 0 and 6.
   - debian/postrm:
     + remove /var/run/resolvconf, not /lib/init/rw/resolvconf
     + also purge /var/run/resolvconf/interface

Revision history for this message
Anders Kaseorg (andersk) wrote :

Sander van Grieken: I’m not sure what you’re talking about, there’s no Upstart script in the Ubuntu resolvconf package [1]. Perhaps you previously had the PPA package installed and it’s left over from that (note that dpkg will not delete conffiles by default [2])?

[1] http://packages.ubuntu.com/maverick/all/resolvconf/filelist
[2] http://wiki.debian.org/DpkgConffileHandling

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

I'm talking about the actual package Anders. Apparently the package contents are incorrect at your [1] link.

$ dpkg -l | grep resolvconf
ii resolvconf 1.46ubuntu1 name server information handler

$ apt-cache showpkg resolvconf
Package: resolvconf
Versions:
1.46ubuntu1 (/var/lib/apt/lists/nl.archive.ubuntu.com_ubuntu_dists_maverick_universe_binary-amd64_Packages) (/var/lib/dpkg/status)

$ dpkg -L resolvconf | grep /etc/init/
/etc/init/resolvconf.conf

Revision history for this message
Jürgen Kreileder (jk) wrote :

As Anders said, conffiles don't get deleted by default.
Do 'dpkg -s resolvconf | grep /etc/init/', you should see that /etc/init/resolvconf.conf is marked as obsolete.

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Ok my bad :)

I never thought of the /etc/init.d initscripts as 'config' files (and I guess no package marks them as such) so I extended this assumption to the upstart scripts too..

Never really used the '-s' option, thanks for the tip.

Revision history for this message
Anders Kaseorg (andersk) wrote :

/etc/init.d scripts are treated as configuration files too, as specifically mandated by Debian Policy [1]. By default, all files in /etc are marked as conffiles by Debhelper [2]. This is important for whoever’s working on this bug, because you will need to write code to specifically clean up the old-style init script; the necessary code is given on the Debian Wiki page I linked to earlier [3].

[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init
[2] http://manpages.ubuntu.com/manpages/lucid/man1/dh_installdeb.1.html
[3] http://wiki.debian.org/DpkgConffileHandling

Revision history for this message
Jürgen Kreileder (jk) wrote :

I've put a fixed build of resolvconf for maverick on https://launchpad.net/~jk/+archive/ubuntu-fixes (ppa:jk/ubuntu-fixes)

The package contains the changes made by Simon Huerlimann and Sander van Grieken.
Source code is available via above PPA and https://code.launchpad.net/~jk/ubuntu/maverick/resolvconf/upstart

Revision history for this message
Sander van Grieken (sander-vangrieken) wrote :

Jürgen, I installed your deb, but it fails to create the /var/run/resolvconf directory. Also the /etc/resolv.conf symlink still points to /etc/resolvconf/run/resolv.conf

output of dpkg -i :

Preparing to replace resolvconf 1.46ubuntu1 (using resolvconf_1.46ubuntu1ppa1_all.deb) ...
Unpacking replacement resolvconf ...
Setting up resolvconf (1.46ubuntu1ppa1) ...
Installing new version of config file /etc/resolvconf/update.d/libc ...
touch: cannot touch `/var/run/resolvconf/enable-updates': No such file or directory
Processing triggers for man-db ...
Processing triggers for ureadahead ...

Revision history for this message
Jürgen Kreileder (jk) wrote :

Sander, looks like a bug inherited from the lucid package. The postinst script must run "resolvconf -i" instead of "resolvconf --enable-updates". I'll upload a fixed package in a few minutes. (The current package should work after "start resolvconf", though).

Revision history for this message
Jürgen Kreileder (jk) wrote :

The new package is in ppa:jk/ubuntu-fixes now. postinst now runs "resolvconf -i" if the run dir doesn't exist yet.

Revision history for this message
dm (jan-rauberg) wrote :

The new package ppa2 does not work as expected in Maverick. After every start I have to do a dpkg-reconfigure resolvconf. Otherwise /etc/resolv.conf is a dead link. Then I have to restart networking an NIS. This is very annoying. I thing the ppa1 was good.

Revision history for this message
Jürgen Kreileder (jk) wrote :

ppa2 only changed the postinst script, so the error should have been in ppa1 too.

To what does /etc/resolv.conf point and does /var/run/resolvconf exist after booting?

Revision history for this message
Juri Haberland (haberland) wrote :

Sander et al.,

I found a problem in the upstart config file from your resolvconf patch:

> start on ( virtual-filesystems and starting udev )

This makes a "restart udev" hang, because upstart waits for resolvconf to finish, which will never happen, as it waits for the signal "virtual-filesystems", which will never come. As udev itself depends on virtual-filesystems, this dependency is superfluous.

Changing the 'start on' line to:

> start on starting udev

fixes this problem.

Revision history for this message
dyna (ubuntu-dyna) wrote :

Bug present in 11.04 natty aswell.

Most of the times resolv.conf is empty expect for 2 remarked generated-by-resolvconf lines.
Only about 1 of 10 reboots resolv.conf will get filled correctly with dns-* data from the interfaces file.

Please fix this, correct dns info is pretty important for servers which do not use dhcp-client.

Revision history for this message
Craig Constantine (craig-constantine) wrote :

...just removing ("apt-get purge resolvconf") the package fixes the problem for me.

I don't need the /etc/resolv.conf file being dynamically modified. Simply purge the package, remove the "# this file is auto generated..." comment in /etc/resolv.conf and my problem is solved.

Revision history for this message
Miguel Branco (mpbbranco) wrote :

I'm reluctant to apply the PPA because I fear that if it breaks I will not be able to recover. Could someone summarize/update the cli steps as done by SvG in the past for 11.10 ? I've tried these manual steps but it broke my networking startup (i.e., updated resolvconf, libc, init/resolv.conf, removed rcS.d/S07, updated symlink). I could recover by backing up the original files. My S07 script is activated at startup so should I disable it with update-rc and exactly how ?

Revision history for this message
Miguel Branco (mpbbranco) wrote :

Nevermind, the quickfix from GdP seems to have worked as is.

Revision history for this message
Thomas Hood (jdthood) wrote :

Hi Miguel.

I would very much appreciate it if you and other contributors to this bug thread would test the latest resolvconf package at https://launchpad.net/~jdthood/+archive/resolvconf. This package is a release candidate prepared by the Debian maintainers of resolvconf in collaboration with some Ubuntu folks; a package very much like it will be uploaded to Ubuntu repos before too long. If you test it now you can ensure that any bugs affecting your machines get addressed by us immediately and you can help to improve the quality of the package ultimately uploaded, thus benefitting other users.
--
Thomas Hood

Revision history for this message
Daniel Stensnes (dstensnes) wrote :

Good lord. Will someone please assign this stuff to someone? I need this for openvpn to my work place. It has been open for several years already....

Revision history for this message
Thomas Hood (jdthood) wrote :

This should be fixed already in 1.63ubuntu8, available in the Precise repo.

Revision history for this message
Sven Kieske (s-kieske) wrote :

Thomas Hood:
I must decline that this is fixed.
How my system is setup:
Ubuntu 12.04.3 LTS Server minimal installed.

I have booted a system without /etc/network/interfaces.
I created /etc/network/interfaces, than I ran ifup eth0 which should bring up eth0 device and trigger resolvconf package
to check for new entries to add to resolv.conf.

ifup works, the ip-address and routes get assigned, however the dns-nameservers do not get assigned.

apt-cache showpkg resolvconf shows me the version: 1.63ubuntu16

Revision history for this message
Thomas Hood (jdthood) wrote :

Please post your /etc/network/interfaces.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.