resolvconf failed to install/upgrade because /etc/resolv.conf immutable

Submitter, please do as the error message suggests. Gain root privileges in a terminal and run 'chattr -i /etc/resolv.conf' and then 'dpkg --configure resolvconf.

For more information about resolvconf please start by reading resolvconf(8).

Status changed to 'Confirmed' because the bug affects multiple users.

Thanx....I think that fixed it.

Chris.

On 27 April 2012 11:50, Thomas Hood <email address hidden> wrote:
> ** Changed in: resolvconf (Ubuntu)
>       Status: Confirmed => Invalid
>
> ** Summary changed:
>
> - package resolvconf 1.63ubuntu11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
> + resolvconf failed to install/upgrade because /etc/resolv.conf immutable
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/989585
>
> Title:
>  resolvconf failed to install/upgrade because /etc/resolv.conf
>  immutable
>
> Status in “resolvconf” package in Ubuntu:
>  Invalid
>
> Bug description:
>  Failed to install during upgrade
>
>  ProblemType: Package
>  DistroRelease: Ubuntu 12.04
>  Package: resolvconf 1.63ubuntu11
>  ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
>  Uname: Linux 3.2.0-23-generic x86_64
>  ApportVersion: 2.0.1-0ubuntu5
>  AptOrdering:
>   unity-scope-musicstores: Install
>   resolvconf: Configure
>   ubuntu-minimal: Configure
>   unity-scope-musicstores: Configure
>  Architecture: amd64
>  Date: Fri Apr 27 11:23:12 2012
>  DuplicateSignature:
>   Setting up resolvconf (1.63ubuntu11) ...
>   resolvconf.postinst: Error: Cannot replace the current /etc/resolv.conf with a symbolic link because it is immutable. To correct this problem, gain root privileges in a terminal and run 'chattr -i /etc/resolv.conf' and then 'dpkg --configure resolvconf'. Aborting.
>   dpkg: error processing resolvconf (--configure):
>    subprocess installed post-installation script returned error exit status 1
>  ErrorMessage: subprocess installed post-installation script returned error exit status 1
>  PackageArchitecture: all
>  SourcePackage: resolvconf
>  Title: package resolvconf 1.63ubuntu11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
>  UpgradeStatus: Upgraded to precise on 2012-04-27 (0 days ago)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/989585/+subscriptions

> I think that fixed it

Good to hear.

How did /etc/resolv.conf become immutable on the affected system? Did the administrator do it with chattr?

Honestly, I don't know....I am the Admin and its my desktop. I don't
remember messing with /etc/resolv.conf, but I can't swear I didn't at
some point in the past.

I just thought that the error thrown up was caused by a glitch in the
upgrade process. Usually, I don't upgrade OS'es....I wipe and start
again. But the last few times with Ubuntu I have upgraded. Each time
there was something small which caused an error, but nothing which was
a showstopper, so I would usually let the upgrade finish and sort out
the error afterwards if necessary.....I just assumed this was another
one of those.

Sorry....this probably doesn't help much with this incident (I can't
even call it a bug really ;-)....

Chris.

On 27 April 2012 13:54, Thomas Hood <email address hidden> wrote:
>> I think that fixed it
>
> Good to hear.
>
> How did /etc/resolv.conf become immutable on the affected system?  Did
> the administrator do it with chattr?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/989585
>
> Title:
>  resolvconf failed to install/upgrade because /etc/resolv.conf
>  immutable
>
> Status in “resolvconf” package in Ubuntu:
>  Invalid
>
> Bug description:
>  Failed to install during upgrade
>
>  ProblemType: Package
>  DistroRelease: Ubuntu 12.04
>  Package: resolvconf 1.63ubuntu11
>  ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
>  Uname: Linux 3.2.0-23-generic x86_64
>  ApportVersion: 2.0.1-0ubuntu5
>  AptOrdering:
>   unity-scope-musicstores: Install
>   resolvconf: Configure
>   ubuntu-minimal: Configure
>   unity-scope-musicstores: Configure
>  Architecture: amd64
>  Date: Fri Apr 27 11:23:12 2012
>  DuplicateSignature:
>   Setting up resolvconf (1.63ubuntu11) ...
>   resolvconf.postinst: Error: Cannot replace the current /etc/resolv.conf with a symbolic link because it is immutable. To correct this problem, gain root privileges in a terminal and run 'chattr -i /etc/resolv.conf' and then 'dpkg --configure resolvconf'. Aborting.
>   dpkg: error processing resolvconf (--configure):
>    subprocess installed post-installation script returned error exit status 1
>  ErrorMessage: subprocess installed post-installation script returned error exit status 1
>  PackageArchitecture: all
>  SourcePackage: resolvconf
>  Title: package resolvconf 1.63ubuntu11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
>  UpgradeStatus: Upgraded to precise on 2012-04-27 (0 days ago)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/989585/+subscriptions

Your report is actually very helpful. Without reports like yours we wouldn't know that people are encountering problems.

You aren't the first one to report that /etc/resolv.conf was immutable when the resolvconf package was installed. It was in response to an earlier such report that code was added to the package's postinst to print out a helpful error message under these circumstances.

We could have gone further and added a line "chattr -i /etc/resolv.conf" to the postinst. But in Debian and Ubuntu we try to respect the administrator's choices and not silently override them, so we didn't add that line. But this decision was based on the assumption that it *is* *administrators* who are setting the immutable bit on /etc/resolv.conf.

Given the fact that so many packages stomp on /etc/resolv.conf I can easily imagine why administrators might resort to this.

But when enough people report exactly the same error it has to make one wonder if there isn't something else going on. Is there, for example, a web page out there somewhere that advises people to set the immutable bit on /etc/resolv.conf as a way of solving the problem of program X stomping on that file? Or is there a package somewhere out there whose maintainer scripts set the immutable bit? If so then we need to know this.
--
Thomas

On Fri, Apr 27, 2012 at 01:49:10PM -0000, Thomas Hood wrote:

> But when enough people report exactly the same error it has to make one
> wonder if there isn't something else going on. Is there, for example, a
> web page out there somewhere that advises people to set the immutable bit
> on /etc/resolv.conf as a way of solving the problem of program X stomping
> on that file? Or is there a package somewhere out there whose maintainer
> scripts set the immutable bit? If so then we need to know this.

I haven't found such a webpage, but I was just talking to an experienced
Ubuntu developer yesterday who said he had this set to avoid Network Manager
stomping on it, so had to manually undo this as part of the upgrade.

I'm wondering if we should automatically chattr -i the file on upgrade as
necessary, since this is in fact not a supported configuration. A debconf
notification to the admin should be sufficient, IMHO.

We may want to deal with this automatically on upgrade. Reopening.

I don't know of a specific web page to point to,, but a quick Google search for "resolv.conf chattr" turns up quite a number of hits...

However, it seems like people who have done this on their machines have had some specific reason to take an interest in the specific contents of their resolv.conf file, and I wonder if silently undoing that will causes some unhappy surprises....

Another options would be to add pre-upgrade check for this situation in update-manger and give the user a clear warning message before commencing the upgrade.

(Also, would it make sense to expand the Release Notes paragraph on resolvconf to mention this sort of problem? The current brief-mention-with-link-to-blog is pretty easy to miss [and in any case the blog doesn't currently mention the immutable-resolv.conf problem].)

On Fri, Apr 27, 2012 at 08:57:51PM -0000, Nathan Stratton Treadway wrote:
> However, it seems like people who have done this on their machines have
> had some specific reason to take an interest in the specific contents of
> their resolv.conf file, and I wonder if silently undoing that will
> causes some unhappy surprises....

Agreed, which is why I'm proposing that we not be silent about it. A
critical debconf error prompt is appropriate here.

There's no sense in failing the upgrade for something we know how to fix
automatically, because there is ultimately only one choice here. You can't
upgrade to 12.04 without installing resolvconf, you can't install resolvconf
without giving it control over /etc/resolv.conf. Now that resolvconf is
managing this file instead of NM, there really aren't good reasons to make
it immutable anyway, and admins just need to transition to the new behavior.

> (Also, would it make sense to expand the Release Notes paragraph on
> resolvconf to mention this sort of problem? The current brief-mention-
> with-link-to-blog is pretty easy to miss [and in any case the blog
> doesn't currently mention the immutable-resolv.conf problem].)

It doesn't mention it because we didn't expect it to be a significant
problem. And I think we should make it not a problem, which makes the
documentation moot...

Initial proposed fix for this pushed to bzr.

Yes, there is a web page. I set mine because the network manager keep trying to switch me over to DHCP from a static IP address and searching on the internet turned up this solution, which worked great.

Hi. My system was set up for a static IP and a local area name server. Network Manager was at one point overwriting my resolv.conf changes ... I may have set the immutable attribute at some point while wrestling with that process. In fact, I am fairly certain I did. I followed the procedure (dpkg --configure resolvconf ) given above and it seems to have worked just fine.

Good to hear.

Although this is a problem arising from administrator actions and although it's easy to fix by hand, the large number of reports justifies automating the solution, as Steve argues (and has already implemented and committed).

Steve: I've been looking at #989096. I Googled upon a Turkish-language discussion of using chattr to solve resolv.conf problems. In that discussion there is talk of doing "chattr +a" or "chattr +ia".

If the "a" attribute is set on a file then "ln -nsf" fails to remove the file.

Hello Chris, or anyone else affected,

Accepted resolvconf into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Another report of this issue was #378844.

This bug was fixed in the package resolvconf - 1.65ubuntu1

---------------
resolvconf (1.65ubuntu1) quantal; urgency=low

  * Merge from debian unstable. Remaining changes:
    - Make /etc/resolv.conf a relative symlink so that it works when
      setting up chroots.
    - Instead of throwing an error that aborts the upgrade when
      /etc/resolv.conf is immutable, pop a debconf error message to let the
      user know what's happening, then clear the immutable flag and continue
      with the installation. LP: #989585.
    - debian/config, debian/templates, debian/postinst: if we don't know that
      /etc/resolv.conf was being dynamically managed before install (in at
      least some cases), link the original contents of /etc/resolv.conf to
      /etc/resolvconf/resolv.conf.d/tail so that any statically configured
      nameservers aren't lost. LP: #923685.
    - Use an upstart job instead of sysvinit script.
    - Pre-Depend on the /run-providing version of initscripts instead of
      depending, so that the preinst does the right thing when creating
      /run/resolvconf/interfaces instead of getting clobbered later by a bind
      mount on initscripts upgrade. LP: #922491.
    - Completely drop the standard_run_subdirs_created helper function from
      debian/postinst, since it serves no purpose here.
    - postinst: Set resolvconf/linkify-resolvconf to false after initial
      conversion, ensuring upgrades won't convert /etc/resolv.conf to
      a symlink if the user manually converted it back to plain text.
      (LP: #922677)
    - Make resolvconf exit 0 when /etc/resolv.conf isn't a symlink
      (instead of exit 1) and update the error message.
    - Move the #DEBHELPER# token in debian/postinst to after the resolv.conf
      symlink is set, so the init script can actually start (since it expects
      /etc/resolv.conf to be a symlink).
    - Eliminate all references to /etc/resolvconf/run. This should all be done
      directly in /run, there is no reason to support making any of this
      configurable with a symlink since we already have a versioned dependency
      on the version of initscripts that introduces the /run transition.

resolvconf (1.65) unstable; urgency=low

  [ Thomas Hood ]
  * [3f0a1a1] Create /etc/resolvconf/run and its target and subdir
    in the postinst as well as in the preinst (Closes: #662724)
  * [ae16ea8] In postinst, as last resort, create /run/resolvconf/
     even if /run isn't a tmpfs.
  * [25711bf] ifupdown hook scripts: Don't return error to ifupdown
    (Addresses #661591 so far as resolvconf is concerned)
  * [8da29c3] Document that list-records doesn't list empty records.
    Add patterns for biosdevnames (See LP#949473)
  * [a998de3] Update default interface order patterns in list-records
  * [94baf61] resolvconf(8): Update ref to dhclient hook script
    (See LP#953257)

resolvconf (1.64) unstable; urgency=low

  [ Thomas Hood ]
  * [da2bfa4] Wipe more selectively (Closes: #657259)
  * [e5fbaef] Ubuntu backport: on enable-updates, exit with nonzero
    status if and only if updates could not be enabled (i.e., ignore
    update script errors).
  * [e1cb96e] Bump Standards-Version
 --...

Unfortunately, bug #994539 is a regression introduced by this change.

Hello Chris, or anyone else affected,

Accepted resolvconf into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

WARNING:

latest Precise-proposed resolvconf 1.63ubuntu13 break the network, need to downgrade to ubuntu12

On Tue, May 08, 2012 at 07:20:09AM -0000, dino99 wrote:
> latest Precise-proposed resolvconf 1.63ubuntu13 break the network,

It certainly does not, the only changes between 12 and 13 are to fix the
detection of an immutable bit on /etc/resolv.conf. What exactly is the
problem you're seeing?

hi Steve,

maybe i've too quickly blame that newest package: before upgrading it ip was resolved normally, then after upgraded ubuntu13 i've got "cant resolve url" error, so i've downgraded to ubuntu12 and the issue was solved. That why i've posted the comment #22 above. So now i'm using ubuntu12 but also get hardtime to resolving url after a cold boot: need to reload several times a page into firefox to get it (first still get "cant resolve url" error).
So i might have some borked settings with this pc. Sorry for the noise.

Tested here with two LXC containers, both of them running up to date oneiric amd64 with chattr +i /etc/resolv.conf.
I then updated the sources.list for s/oneiric/precise/, updated the list and installed resolvconf. First container didn't have -proposed, the second one did.

Log for the first one:
Preconfiguring packages ...
Selecting previously deselected package resolvconf.
(Reading database ... 11527 files and directories currently installed.)
Unpacking resolvconf (from .../resolvconf_1.63ubuntu11_all.deb) ...
Processing triggers for ureadahead ...
Setting up resolvconf (1.63ubuntu11) ...
resolvconf.postinst: Error: Cannot replace the current /etc/resolv.conf with a symbolic link because it is immutable. To correct this problem, gain root privileges in a terminal and run 'chattr -i /etc/resolv.conf' and then 'dpkg --configure resolvconf'. Aborting.
dpkg: error processing resolvconf (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 resolvconf
E: Sub-process /usr/bin/dpkg returned an error code (1)

Log for the second one:
Preconfiguring packages ...
Selecting previously deselected package resolvconf.
(Reading database ... 11527 files and directories currently installed.)
Unpacking resolvconf (from .../resolvconf_1.63ubuntu13_all.deb) ...
Processing triggers for ureadahead ...
Setting up resolvconf (1.63ubuntu13) ...
resolvconf start/running
Processing triggers for resolvconf ...

Looking through the diff, it looks like we want the debconf warning to show up in such case, but it doesn't.

So I wouldn't consider the SRU verification-done just yet, I'll check with Steve whether that was indeed the planned behaviour and if not, add a db_go call after the db_input entry in postinst.

This now works properly with ubuntu14 (only delta from ubuntu13 is the added db_go call).

sidnei: Please don't change the assignee of the bug unless you're the one working on the fix.

This bug was fixed in the package resolvconf - 1.63ubuntu14

---------------
resolvconf (1.63ubuntu14) precise-proposed; urgency=low

  * Call db_go after the db_input command so that the debconf error
    message is actually shown to the user.

resolvconf (1.63ubuntu13) precise-proposed; urgency=low

  [ Stéphane Graber ]
  * In is_immutable_file, if lsattr doesn't return anything on stdout,
    return 1 and hide stderr. This fixes lsattr failing on non-ext
    filesystems. (LP: #994539)

  [ Steve Langasek ]
  * Fix syntax of db_input command, which is part of why we're seeing
    failures in bug #994539.

resolvconf (1.63ubuntu12) precise-proposed; urgency=low

  * Instead of throwing an error that aborts the upgrade when
    /etc/resolv.conf is immutable, pop a debconf error message to let the
    user know what's happening, then clear the immutable flag and continue
    with the installation. LP: #989585.
 -- Stephane Graber <email address hidden> Mon, 14 May 2012 12:31:58 -0400