Cannot upgrade bind9

Question

This is the output at my current installation, after running apt-get upgrade or apt-get dist-upgrade

user@localhost:~# apt-get -f upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following packages will be upgraded:
  bind9
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0 B/335 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? Y
dpkg: dependency problems prevent configuration of bind9:
 bind9 depends on libbind9-80 (= 1:9.8.1.dfsg.P1-4ubuntu0.5); however:
  Version of libbind9-80 on system is 1:9.8.1.dfsg.P1-4ubuntu0.7.
 bind9 depends on libdns81 (= 1:9.8.1.dfsg.P1-4ubuntu0.5); however:
  Version of libdns81 on system is 1:9.8.1.dfsg.P1-4ubuntu0.7.
 bind9 depends on libisc83 (= 1:9.8.1.dfsg.P1-4ubuntu0.5); however:
  Version of libisc83 on system is 1:9.8.1.dfsg.P1-4ubuntu0.7.
 bind9 depends on libisccc80 (= 1:9.8.1.dfsg.P1-4ubuntu0.5); however:
  Version of libisccc80 on system is 1:9.8.1.dfsg.P1-4ubuntu0.7.
 bind9 depends on libisccfg82 (= 1:9.8.1.dfsg.P1-4ubuntu0.5); however:
  Version of libisccfg82 on system is 1:9.8.1.dfsg.P1-4ubuntu0.7.
 bind9 depends on liblwres80 (= 1:9.8.1.dfsg.P1-4ubuntu0.5); however:
  Version of liblwres80 on system is 1:9.8.1.dfsg.P1-4ubuntu0.7.
 bind9 depends on bind9utils (= 1:9.8.1.dfsg.P1-4ubuntu0.5); however:
  Version of bind9utils on system is 1:9.8.1.dfsg.P1-4ubuntu0.7.
dpkg: erroNo apport report written because the error message indicates it's a follow-up error from a previous failure.
                                      r processing bind9 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 bind9
E: Sub-process /usr/bin/dpkg returned an error code (1)

Edit: apt-cache policy bind9 results:

bind9:
  Installed: 1:9.8.1.dfsg.P1-4ubuntu0.5
  Candidate: 1:9.8.1.dfsg.P1-4ubuntu0.7
  Version table:
     1:9.8.1.dfsg.P1-4ubuntu0.7 0
        500 http://mirror.sov.uk.goscomb.net/ubuntu/ precise-updates/main i386 Packages
        500 http://security.ubuntu.com/ubuntu/ precise-security/main i386 Packages
 *** 1:9.8.1.dfsg.P1-4ubuntu0.5 0
        100 /var/lib/dpkg/status
     1:9.8.1.dfsg.P1-4 0
        500 http://mirror.sov.uk.goscomb.net/ubuntu/ precise/main i386 Packages

Solution 1

This might fix the issue:

sudo apt-get install -f bind9

If it doesn't, then this might fix the issue:

sudo apt-get remove bind9
sudo apt-get install bind9

Failing that you may want to remove bind9 via dpkg directly (to avoid apt-get uninstalling whatever depends on it):

sudo dpkg --remove bind9
sudo apt-get install -f bind9

If dpkg doesn't want to remove bind9 (it might say the package is in an inconsistent state and needs to be reinstalled before it can be removed), you may try upgrading to the new version directly

sudo dpkg -i /var/cache/apt/archives/bind9_1:9.8.1.dfsg.P1-4ubuntu0.7_*.deb
sudo apt-get install -f

Solution 2

It could be due to the apparmor policy file. If you see in /var/log/syslog:

Oct 30 12:07:40 sd-51351 kernel: [1269834.299538] type=1400 audit(1383131260.584:39): apparmor="DENIED" operation="open" parent=1968 profile="/usr/sbin/named" name="/var/named/run-root/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so" pid=1969 comm="named" requested_mask="r" denied_mask="r" fsuid=107 ouid=0

The, edit /etc/apparmor.d/usr.sbin.named and add the line:

/var/named/run-root/** rwm,

Then, restart services:

sudo service apparmor reload sudo service bind9 start

Comments

[Oli]

@minerz029 Looks like a security update version from July.

[Oli]

Can you edit the output of apt-cache policy bind9 onto the end of your post please? It looks like there's an old version (....0.5) of being installed and it can only find the newer (....0.7) dependencies.

[Fra H]

@MariusGedminas Full output now provided. Actually there was nothing interesting before that lines.

[Oli]

This would be how I would attempt to fix things... Removing/reinstalling will result in a small amount of downtime (and more if it won't reinstall, obviously) but this should clear the problem (the right version is available) and should work.

[Fra H]

I've got a package that depends on bind9, and I need it, so I cannot do remove. On install -f I get the same error message.Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies. plesk-core : Depends: bind9 (>= 9.2.1) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

[Marius Gedminas]

I edited my answer to add a couple more suggestions.

[Fra H]

Different error now: Setting up bind9 (1:9.8.1.dfsg.P1-4ubuntu0.7) ... * Starting domain name service... bind9 [fail] invoke-rc.d: initscript bind9, action "start" failed. dpkg: error processing bind9 (--configure): subprocess installed post-installation script returned error exit status 1 No apport report written because MaxReports has already been reached Errors were encountered while processing: bind9 E: Sub-process /usr/bin/dpkg returned an error code (1)

[Marius Gedminas]

Are there any error messages from named in /var/log/syslog that could explain why bind9 won't start? Perhaps there's a syntax error in some configuration file or a zone file? Or some other daemon is already listening on port 53? Fix that, then sudo dpkg --configure -a/sudo apt-get install -f should complete successfully.

[Fra H]

apparmor was blocking bind9. Error in syslog: initializing DST: openssl failure. Solved. Everything works now, thanks to your patience.

[serfer2]

It Works very nice. I was in a trouble with apt-get upgrade (with bind9) and this command did the trick: sudo dpkg -i /var/cache/apt/archives/bind9_1%3a9.8.1.dfsg.P1-4ubuntu0.10_‌​amd64.deb

[serfer2]

Problems with bind9 in Ubuntu servers are related, very frecuently, with Plesk and AppArmor conflicts. Here you can see how to solve it in a very simple way: failover.co/blog/… It saved me ;-)

[PanPipes]

This fixed the issue I had, but can someone explain what /var/named/run-root/** rwm, does in this instance?