Hello Eugene,
> > > 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).
You generally don't need to run full-upgrade on a stable Debian
release, that's true.
But if you are upgrading between major Debian releases, you are
required to perform a full-upgrade and install everything that it says
so there, if you fail to do it, you are running an unstable system
because you are mixing packages from different major releases.
This is where "normal upgrade" comes in, as soon as you upgrade to a
new Debian major release and don't perform full-upgrade, you're in
"unknown territory" (not officially supported/not normal).
We have lots of QA and CI tools that ensure things don't break in
multiple different scenarios, but this is one where we can't ensure
things will work (and don't test for it).
> 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.
This is true generally speaking, but if you break the upgrade process
when going to a new major release, then this is not the case anymore,
the system can now be considered unstable. Anything you install might
require full-upgrade because this should have been done at the time
when you switched major releases.
You are bound to keep hitting issues like this one because it's not a
supported system where we can predict what's gonna happen, our tooling
doesn't test for such scenarios.
The correct approach would be to stick to the previous release, and/or
use backports, or solve the issues blocking the system from performing
a full-upgrade (which are issues that only arises with third party
packages, since we do have automated tests that ensure systems with
official packages-only are able to fully upgrade).
> 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'd like to mention again, that even though I think you might be
risking too much with a system that bumped to a bigger major version
without a full-upgrade, and that this is not officially supported by
Debian, this is still a valid and real issue that you hit, and I will
solve it.
I also trust that you know what you're doing with those systems, and I
don't mean to say what you should or should not do. As long as you're
aware of the risks involved and understand that this is an unsupported
scenario with hidden issues, it should be fine.
> > 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).
There was an issue on my reproduction steps, I'm now able to reproduce
the issue on Buster and Bullseye.
For the record and future references:
rsync 3.2.3-8 can be built on any Debian release as of now, the issue
only arises when a package built with libc6-dev >= 2.32 is installed
on a system that contains libc6 < 2.32.
Our dpkg-symbols solution is not able to identify this and naturally
choses a lower version requirement for the libc6 dependency.
Reproduction can be done on a Buster/Bullseye VM by installing an
rsync 3.2.3-8 that was compiled with libc6-dev >= 2.32 and running:
rsync -va /etc/ld.so.cache /tmp
I'm currently studying what's the best approach on solving this in a
clean manner, and I have updated upstream on this matter[0].
My previous plan still stands; I'd like to try to solve this outside
of the packaging of rsync, if possible, but if not I will bump rsync's
dependency to libc6 >=2.32 when it gets compiled with libc6-dev 2.32.
>> 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).
No, it's the other way around, lchown was the one mentioned by
mistake, the syscall related to this issue is lchmod.
Again, thanks for reporting the issue and helping me debug it :)
[0] https://github.com/WayneD/rsync/issues/109#issuecomment-939506927
--
Samuel Henrique <samueloph>
