Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Aurelien Jarno <aurelien@aurel32.net>]

On 2021-03-19 15:24, Ivo De Decker wrote:
> Hi,
> 
> On Fri, Nov 20, 2020 at 01:44:50PM +0100, Alois Wohlschlager wrote:
> > Am Freitag, den 20.11.2020, 09:13 +0000 schrieb Niko Tyni:
> > > I don't think this is related to the recent perl 5.30 -> 5.32
> > > transition.
> > > The report is about a buster -> bullseye upgrade, and perl in
> > > bullseye
> > > was still at 5.30 at the time.
> > > 
> > > In any case, the report says perl (presumably perl-base as well) was
> > > still at the buster version when the breakage happened, so it didn't
> > > have the libcrypt1 dependency.
> > 
> > This is indeed the case. perl-base was only upgraded to the bullseye
> > version after I manually fixed the breakage. (Indeed, when I wrote
> > "Perl" I actually meant "perl-base", but perl itself was also at the
> > buster version FWIW.)
> > 
> > > FWIW the breakage can be reproduced just by manually unpacking the
> > > new
> > > libc6 on a buster system.
> > > 
> > > I don't know why it hasn't been encountered earlier.
> > 
> > I found out by now that the problem actually has been encountered
> > earlier(#946599, where it broke libc's maintainer scripts). In my case,
> > it broke the check-support-status hook providd by debian-security-
> > support. (I'm not sure whether it's such a great idea for dpkg to run
> > hooks when dependencies are broken, but that's what was happening on my
> > system.)
> 
> I filed #984539 against debian-security-support, to make sure the hook never
> fails. That doesn't fix this bug, but at least it might reduce the potential
> impact of issues like these.
> 
> > > Yeah, I missed the libcrypt1 -> libc6 dependency. That prevents this
> > > option. (I wonder if the circular dependency is a factor in apt
> > > choosing
> > > the upgrade order that results in this breakage.)
> > 
> > I'm not sure what's going on here, as libcrypt1's libc6 Depends should
> > be satisfied by the buster version. So it seems to me like installing
> > libcrypt1 before upgrading libc6 should be strictly better than doing
> > it the other way round, even purely in terms of satisfaction of
> > dependencies.
> > 
> > Maybe it's worth investigating why apt decides to proceed the "wrong"
> > way anyway, should I try setting up a VM to reproduce the problem?
> 
> I did some upgrade tests starting from the
> debian-10-generic-amd64-20210208-542.qcow2 cloud image, and in all my tests,
> apt chooses to unpack libc6 before libcrypt1.
> 
> However, in all of my tests, between the unpack of the new libc6 and libcrypt1
> only other unpacks where done, and no dpkg hooks where run. If you have a way
> to reproduce the upgrade where dpkg ran the hook in between, that might be
> interesting. Do you still have a list of packages that was installed before
> you started the upgrade?

Have you tried to install a foreign libc6? It usually makes the upgrade
a bit more tricky and could be what triggers the issue.

> Note that even if the hook isn't run or doesn't fail, there is still a period
> between the unpack of libc6 and libcrypt1 where perl is broken. If other
> operations are done in between that cause maintainer scripts to run, these
> could potentially call perl, which will be broken in this case.
> 
> > > > > Another option might be to have the new libc6 Conflict with old
> > > > > versions
> > > > > of Essential:yes packages that need libcrypt1, forcing those
> > > > > Essential:yes
> > > > > packages to get upgraded first. A quick check based on libcrypt1
> > > > > reverse
> > > > > dependencies in sid shows perl-base, login and util-linux. I'm
> > > > > not sure
> > > > > if this list is exhaustive, though.
> > 
> > Having libc6 Conflict with one of those packages should be enough,
> > right?
> 
> I tried creating libc6 packages with either a conflits or a breaks agains the
> old perl-base or the old login, and in each case I get this error:
> 
> E: This installation run will require temporarily removing the essential package libc6:amd64 due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
> E: Internal Error, Could not early remove libc6:amd64 (2)
> 
> So it doesn't look like this will work.

I haven't tried, but it's what I was expecting.

> Note that I manually changed the binaries and didn't rebuild glibc, so I might
> have made a mistake, but this scenario should certainly be tested before
> something like this is uploaded to unstable. Maybe an upload to experimental
> might allow people to test this more easily?
> 
> I Cced the apt maintainers to see if they have other suggestions to get
> apt/dpkg to unpack libcrypt1 before libc6.

Another (ugly) suggestions we discussed at some point was:
1) in the preinst copy the existing libcrypt1 library to a private and
add it to ldconfig with lower priority than /usr/lib/$(MULTIARCH)
2) in the postinst remove these copy and ldconfig configuration.

> I wonder if all this might be caused by the breaks from libcrypt1 (against
> libc6 (<< 2.29-4)). Is there a way to remove the breaks without causing
> issues?  Maybe this is somewhat similar to the situation in

The problem of removing the break, is that we loose the possibility of
downgrades. Is it something acceptable?

> https://bugs.debian.org/972936#24: libgcc-s1 takes over binaries from libgcc1,
> but only 'replaces' it, without breaks (note that extra steps had to be taken
> to avoid further issues (adding Important: yes and Protected: yes)).

Are this extra-steps basically required to prevent downgrades?

Cheers,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net