Hi Samuel.
On Tue, Sep 28, 2021 at 08:51:59PM +0100, Samuel Henrique wrote:
> > To build version dependency automatically script should have access
> > to the whole history of all versions of libc6, with list of symbols
> > and markers when each symbol become usable.
>
> We have that, you can read about it here[0][1][2], if you're interested.
Thank you for those references, I've got much helpful info from them.
> > Yes, this issue may occure when libc6 vesion is outdated in normal
> > upgrade process.
>
> I would disagree on the definition of a normal upgrade process, one
> would never end up with a combination of incompatible rsync + libc,
> that can only happen if somebody installs a package that is not
> supported by Debian (not from the official repos) and that package
> holds libc back (thus running an unsupported version)[4].
I had several (at least 2 distinct) live systems with this post-upgrade
problem. They have backups, but now it too late: now those backups are
replaced by new ones.
However, it requires some clarification what is "normal upgrade" process.
I do not run full-upgrade ("aptitude safe-upgrade" in my taste) if some
new package it to be installed. I simply check dependences to be sure
that new package does not bring risk to break functionality of important
services on production system. The full-upgrade is performed on a schedule,
once a week or two, and requires additional monitoring of the system's
behaviour. For example, I have an LXC containter with libc-2.31-17,
which was not updated at least a month (file libc.so.6 dated 23-Aug).
Running "apt-get update ; aptitude -R install rsync" I got rsync-3.2.3-8
without libc6 update. I consider this as a normal situation, because
I have no obligation to do full-upgrade when I install some package.
However, this combination (rsync-3.2.3-8 + libc6-2.31-17) is not
functional: rsync replies "failed to set permissions [...] Function
not implemented (38)".
> I did try to reproduce the issue on Jessie, with libc 2.28, but I was
> able to run "rsync -va /etc/ld.so.cache /tmp" with no issues.
Did you try the last rsync binary with libc6-2.28?
I tried and got an error (see below).
> It might be possible that the issue you're seeing only affects libc
> between 2.28 and 2.31, if that's the case, it will be very tricky for
> me to reproduce since Debian only supports 2.28, 2.31 and 2.32.
Many versions are saved here: http://snapshot.debian.org/binary/libc6/.
Using the previously mentioned LXC container and binary packages from
snapshot.debian.org, I tried rsync-3.2.3-8 with libc 2.31-17, 2.30-4,
2.29-10, 2.28-10, 2.28-1, 2.27-1, in all cases rsync fails with the same
"not implemented" error. I did not go below 2.27-1 because it requires
downgrading of base system packages...
> If you have an affected system at hand, I would kindly ask you to try
> to implement upstream's workaround[5] and see if it makes your issue
> go away.
I could take me too much time to set up building environment and compile
from sources... However, I can test binary on my setup, if you provide it
(for arch:amd64, please). I can provide access to my LXC environment:
just send me your ssh public key, and I'll create an entry for you.
> Just a small correction, I see you mentioned lchown, but the issue is
> related to lchmod.
Yes, it should be read "lchown" (lchmod was mentioned by mistake).
--
Eugene Berdnikov
