This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 739746 - dhcp / bind mismatch on f15 to f16 upgrade: no network
dhcp / bind mismatch on f15 to f16 upgrade: no network
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
Depends On:
Blocks: F16Beta/F16BetaBlocker
  Show dependency treegraph
Reported: 2011-09-19 17:53 EDT by Adam Williamson
Modified: 2013-04-30 19:50 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-10-03 12:01:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2011-09-19 17:53:41 EDT
Currently, if you upgrade from a fully-updated F15 to F16 Beta RC1, you get no network, because of an unfortunate update circumstance. There's pending updates for bind, dhcp and dnsperf for F15 and F16: (F16) (F15)

the F15 one has gone stable, so a fully-updated F15 includes bind-libs-9.8.1-1.fc15 and dhcp-4.2.11.P1.fc15 built against that bind.

The F16 one has not gone stable, so the state of the art in F16 currently is bind-9.8.0-9.P4.fc16 , and dhcp-4.2.2-4.fc16 built against that bind.

So the 'current' F16 dhcp is a higher EVR than F15's, but built against an older bind.

When you upgrade from F15 to F16 you get F16's dhcp, but you keep F15's bind, so you wind up with a mismatch, and dhclient won't run: no network for you, skippy!

This is a Beta blocker, as it violates "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria". To fix it, we should pull into F16 Beta. Accordingly, I'm setting this to MODIFIED.
Comment 1 John Ellson 2011-09-21 01:54:46 EDT
+1 as a blocker,

but if anyone else gets stuck without a network because of this, the following worked for me:

    cd /usr/lib64
    ln -s
    ln -s
Comment 2 Adam Tkac 2011-09-21 04:35:35 EDT
(In reply to comment #1)
> but if anyone else gets stuck without a network because of this, the following
> worked for me:
>     cd /usr/lib64
>     ln -s
>     ln -s

Yes, this should work, dhclient (not sure about dhcpd) uses only small subset of libisc ABI and this subset didn't change between .81 and .83
Comment 3 Tim Flink 2011-09-21 14:37:03 EDT
I'm also +1 blocker on this. While the workaround from comment 1 does work, the root cause of the problem is not incredibly obvious.

Since that makes it +3 blocker, I'm moving to accepted.
Comment 4 Jeffrey C. Ollie 2011-09-22 09:46:09 EDT
Ironically, what saved me when this happened to me was IPv6.  My work network is IPv6 enabled so I got an IPv6 address via router advertisement after I upgraded my work desktop system.  I added the IPv6 address of my nameserver to /etc/resolv.conf and was then able to do a "yum upgrade --enablerepo=updates-testing" to get the F16 build of BIND.
Comment 5 Dmytro Taranovsky 2011-09-22 12:17:43 EDT
While the updated bind may solve this particular problem, the underlying issue is that faulty upgrade logic allowed the problem to appear in the first place.  Correspondingly, I added
Bug 740601 - Upgrades using preupgrade should downgrade packages as appropriate
Comment 6 Tim Flink 2011-09-27 11:30:47 EDT
It looks like the updates for dhcp and bind have been pushed to stable for F16, moving this to ON_QA
Comment 7 Tim Flink 2011-09-27 13:02:02 EDT
I just tested preupgrade from F15 -> F16. The appropriate dhcp and bind packages are installed, network works without extra intervention.

Moving this to VERIFIED.
Comment 8 Adam Williamson 2011-10-03 12:01:46 EDT
the update is pushed stable, so we can close this now.

Note You need to log in before you can comment on or make changes to this bug.