Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
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?
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.
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.
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
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)).
Cheers,
Ivo
Reply to: