Bug 509618 - is bind-libs broken?
is bind-libs broken?
Status: CLOSED DUPLICATE of bug 509635
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-04 02:01 EDT by Mohammed Arafa
Modified: 2013-04-30 19:43 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-13 07:10:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mohammed Arafa 2009-07-04 02:01:38 EDT
Description of problem:
my machine updated this morning and now dig won't work

Version-Release number of selected component (if applicable):
bind-libs-9.6.1-2.fc11.x86_64


How reproducible:
everytime

Steps to Reproduce:
1.
2.
3.
  
Actual results:
dig: error while loading shared libraries: liblwres.so.50: cannot open shared object file: No such file or directory

Expected results:
just works

Additional info:
Comment 1 Robert Scheck 2009-07-04 06:35:28 EDT
If this really is a bug and not another issue, then it's one of bind-libs
and never of the standalone bind-libbind package. Re-assigning to bind now.
Comment 2 Tom Horsley 2009-07-04 07:54:47 EDT
Similar results on my machine:

bind-libs-9.6.1-2.fc11.x86_64

After installing latest updates, I am completely screwed by the
bind updates. Here are some samples:

Error in named configuration:
/usr/sbin/named-checkconf: error while loading shared libraries: libbind9.so.50: cannot open shared object file: No such file or directory

zooty> nslookup cnn.com
nslookup: error while loading shared libraries: liblwres.so.50: cannot open shared object file: No such file or directory

rpm -q --list bind-libs
/usr/lib64/libbind9.so.50
/usr/lib64/libbind9.so.50.0.3
/usr/lib64/libdns.so.50
/usr/lib64/libdns.so.50.2.0
/usr/lib64/libisc.so.50
/usr/lib64/libisc.so.50.1.1
/usr/lib64/libisccc.so.50
/usr/lib64/libisccc.so.50.0.0
/usr/lib64/libisccfg.so.50
/usr/lib64/libisccfg.so.50.0.0
/usr/lib64/liblwres.so.50
/usr/lib64/liblwres.so.50.0.2

zooty> ls -l /usr/lib64/libbind9.so.50
lrwxrwxrwx 1 root root 18 Jul  4 07:24 /usr/lib64/libbind9.so.50 -> libbind9.so.50.2.0
zooty> ls -l /usr/lib64/liblwres.so.50
lrwxrwxrwx 1 root root 18 Jul  4 07:24 /usr/lib64/liblwres.so.50 -> liblwres.so.50.2.0

Note the broken symlinks :-(.

I did this nonsense to repair the problem as a work around:

cd /usr/lib64
ln -s liblwres.so.50.0.2 liblwres.so.50.2.0
ln -s libbind9.so.50.0.3 libbind9.so.50.2.0
Comment 3 Michael Hampton 2009-07-06 16:39:04 EDT
I had logged in specifically to report this bug, and happily found it had already been reported.

I fixed this issue by running "ldconfig" as root.

I would suggest that the %post script for this package do so, in order to prevent this sort of problem in future.
Comment 4 Bill McGonigle 2009-07-06 16:59:04 EDT
same as Tom:

rebo> rpm -q bind-libs
bind-libs-9.6.1-2.fc11.x86_64

I hit it via the 'host' command which is now broken.
Comment 5 Bill McGonigle 2009-07-06 17:03:56 EDT
oh, should have read the mid-air collision... ldconfig does fix.
Comment 6 Tom Horsley 2009-07-06 18:05:16 EDT
Learn something every day. I didn't know ldconfig would supply
the missing symlinks, I thought it just built some database over
in /etc.
Comment 7 m 2009-07-09 15:44:34 EDT
same with bind-libs-9.6.1-2.fc11.i586
would be nice to have the spec file updated per post #3 or whatever is needed.
Comment 8 Stephen Cuppett 2009-07-12 14:08:41 EDT
Bug #509964 may be a duplicate.
Comment 9 Adam Tkac 2009-07-13 07:10:30 EDT

*** This bug has been marked as a duplicate of bug 509635 ***

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