Re: dpkg failure trying to change ownership of a symlink ...
That sounds really familiar; I had the same problem a while ago. The
story, as far as I understand it, is as follows.
*** quote from chown(2) manpage ***
In versions of Linux prior to 2.1.81 (and distinct from
2.1.46), chown did not follow symbolic links. Since Linux
2.1.81, chown does follow symbolic links, and there is a
new system call lchown that does not follow symbolic
links. Since Linux 2.1.86, this new call (that has the
same semantics as the old chown) has got the same syscall
number, and chown got the newly introduced number.
*** end quote ***
Obviously, this means that libc has to be modified to support the new
lchown() system call. If I recall correctly, from the discussion on
this list when this happened, several years ago, there is an added
twist on the Alpha platform, in that the syscall numbers match those
on DEC UNIX in order to be able to run DU binaries, which means that
we can't blithely change them around as described above. The exact
details of the solution elude me, then and now, but the result is that
there is a rather complicated interaction between the versions of the
kernel, libc, and dpkg (and presumably any other program which cares
about this sort of thing). You want all three to either predate or
postdate this change, although I seem to recall that the kernel
matters less than the other two, because the post-change libc notices
the kernel version and deals with it, or something like that. Also it
appears that having a pre-change dpkg and a post-change libc is less
bad than the reverse, which brings us to your situation.
You didn't say which versions of the relevant packages you have
installed (except "mainly slink"), so I can't tell how closely your
problem matches the one I had. I will describe how I got into this
situation, and how I got out of it; hopefully some of this will be
relevant to you. I'm trying to reconstruct the sequence from memory,
so some of the details may not be exactly right.
initial configuration:
dpkg 1.4.0.24
libc6.1 2.0.7u-1
kernel 2.1.125
first step into cow-pie:
upgrade to dpkg_1.4.0.34 , hoping it will solve some other
symlink-related problem. oops. now dpkg doesn't work at all, because:
Error trying to change ownership of symlink xxx:
Function not implemented
try upgrading to libc6.1_2.0.7.19981211-6 -- can't, same error. try
reverting to dpkg_1.4.0.24 -- can't, same error. now i'm really stuck
in it.
upgrade kernel to 2.2.17 . no change.
after an indeterminate period of futile messing around, i finally hit
on the following solution:
unpack dpkg_1.4.0.24.deb into user directory using 'dpkg -x'. this
doesn't choke, because it's not manipulating symlinks.
find dynamic libraries linked to extracted dpkg_1.4.0.24 binary:
# ldd ./dpkg
libdpkg.so.0 => /usr/lib/libdpkg.so.0 (0x0000020000002000)
libc.so.6.1 => /lib/libc.so.6.1 (0x0000020000120000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020001000000)
manually adjust /usr/lib/libdpkg.so.0 symlink to point to
libdpkg.so.0.0.0 library extracted from dpkg_1.4.0.24 archive.
use dpkg_1.4.0.24 binary to properly install dpkg_1.4.0.24.deb :
# ./dpkg -i dpkg_1.4.0.24.deb
upgrade to libc6.1_2.0.7.19981211-6 and dpkg_1.4.0.34 , IN THAT ORDER,
including any dependencies, mainly ldso, libncurses4, and libstdc++2.9
final configuration:
dpkg 1.4.0.34
libc6.1 2.0.7.19981211-6
kernel 2.2.17 (this probably doesn't matter)
Now everything seems to work fine. It would have been nice if the
dependency list for dpkg_1.4.0.34 took care of this problem, but it
may be that it's only an issue on the Alpha platform, or that it only
shows up if you upgrade some things but not others.
I hope that some of this is useful to you. dpkg_1.4.0.34.deb and
libc6.1_2.0.7.19981211-6.deb are available on archive.debian.org . I
fortuitously still had dpkg_1.4.0.24.deb lying around; if you find you
need this and can't get it elsewhere, maybe I could ftp it to you
somehow.
-- Ian
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
Reply to: