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: https://admin.fedoraproject.org/updates/FEDORA-2011-12385 (F16) https://admin.fedoraproject.org/updates/FEDORA-2011-12429 (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 https://admin.fedoraproject.org/updates/FEDORA-2011-12385 into F16 Beta. Accordingly, I'm setting this to MODIFIED.
+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 libisc.so.83.0.1 libisc.so.81 ln -s libisc-export.so.83.0.1 libisc-export.so.81
(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 libisc.so.83.0.1 libisc.so.81 > ln -s libisc-export.so.83.0.1 libisc-export.so.81 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
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.
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.
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
It looks like the updates for dhcp and bind have been pushed to stable for F16, moving this to ON_QA
I just tested preupgrade from F15 -> F16. The appropriate dhcp and bind packages are installed, network works without extra intervention. Moving this to VERIFIED.
the update is pushed stable, so we can close this now.