Harden test for no new acquires after transaction abort
If a transaction is doomed we want to gracefully shutdown our zoo of
worker processes. As explained in the referenced commit we do this by
stopping the main process from handing out new work and ignoring the
replies it gets from the workers, so that they eventually run out of
work.
We tested this previously by checking if a rred worker was given work
items at all, but depending on how lucky the stars of the machine
working on this are the worker would have already gotten work before the
transaction was aborted – so we tried this 25 times a row (f35601e5d2).
No machine can be this lucky, right?
Turns out the autopkgtest armhf machine is very lucky.
I feel a bit sorry for feeding grep such a long "line" to work with, but
it seems to work out. Porterbox amdahl (who is considerably less lucky;
had to turn down to 1 try to get it to fail sometimes) is now happily
running the test in an endless loop.
Of course, I could have broken the test now, but its still a rather
generic grep (in some ways more generic even) and the main part of the
testcase – the update process finishes and fails – is untouched.
References: 38f8704e419ed93f433129e20df5611df6652620
Closes: #984966
(cherry picked from commit 0d25ce3d466ecddea02d171981f011f7dbf95e08)
(cherry picked from commit c091472587eb743a9137b6375a17e45951554515)
LP: #1918920
(cherry picked from commit bb5842ca5c5a2ec9e54126e8cc269765907eb792)
The benefits of immediate configuration are that Essential packages
will be configured immediately, so if they are wrongly not working
without being configured they won't fail later packages.
However, we've reached the point where dependencies on the essential set
are too complex for immediate configuration to always work, causing
installations to error out at the end, despite having succeeded, because
we did not correctly return the error here and did not check for pending
errors before running dpkg.
Given that we check and configure any packages at the end that have not
been configured yet, or fail if we can't configure them; making
immediate configuration optional is the best way forward - it orders as
it does now, but then does not spuriously fail after having successfully
installed everything.
Closes: #973305, #188161, #211075, #649588
LP: #1871268
(cherry picked from commit c530a192d6a57e091d400cb42f9ce0d5a327ff01)
(cherry picked from commit 721e65d4306c80a170e562c20b42e2211af54a71)
Do not immediately configure m-a: same packages in lockstep
In LP#835625, it was reported that apt did not unpack multi-arch
packages in the correct order, and dpkg did not like that. The fix
also made apt configure packages together, which is not strictly
necessary.
This turned out to cause issues now, because of dependencies on
libc6:i386 that caused immediate configuration of that to not
work.
Work around the issue by not configuring multi-arch: same packages
in lockstep if they have the immediate flag set. This will be the
pseudo-essential set, and given how essential works, we mostly need
the native arch to work correctly anyway.
LP: #1871268
Regression-Of: 30426f4822516bdd26528aa2e6d8d69c1291c8d3
(cherry picked from commit 2b13473a9b9947f55a0871d146e4fee456b0af60)
(cherry picked from commit d97ac78658524777065ec4057c933e9103d0f6f0)
Do not produce late error if immediate configuration fails, just warn
We are seeing more and more installations fail due to immediate
configuration issues related to libc6. Immediate configuration is
supposed to ensure that an essential package is configured immediately,
just in case some other packages use a part of the essential package
that only works if that package is configured.
This used to be a warning, it was turned into an error in some commit I
can't remember right now, but importantly, the error missed a return,
which means that ordering completed succesfully and packages were being
installed anyway; and after all that happened successfully, we'd print
an error at the end and exit with an error code, which is not super
useful.
Revert the error back to a warning such that the behavior stays the same
but we do not fail (unless we mess up ordering which then gets caught by
a consistency check later on.
This is the smallest effort implementation to fix the bug where the
currently running kernel could be autoremoved. It avoids the config
file changes, as well as querying the entire cache to be able to find
other variants of the current kernel and group them by version.
This is essentially a slimmed down variant of the solution in 2.2,
to avoid changing the config file and end up protecting less packages
than before - ensuring we only protect _more_ packages.
It might be a tad slow, as we recalculate the DefaultRootSetFunc2
a few times, but does not seem to be super bad.
LP: #1615381
(cherry picked from commit 0991d375cefd0999cf518ea1b437ae71d0d5bc2d)
RunScripts: Do not reset SIGQUIT and SIGINT to SIG_DFL
This caused python-apt to unset the Python signal handler when running
update or install commands, breaking KeyboardInterrupt amongst possibly
other things.
We do not set those signal handlers in this functions, and the calling
functions restore signal handlers to previous ones.
LP: #1898026
(cherry picked from commit 8eccb902aa3be22a151943286fb376759a2b3585)
(cherry picked from commit 880d8e11a7e4d4660388dc806c39710cc627e626)
Do not require force-loopbreak on Protected/Important packages
dpkg will be changed in 1.20.8 to not require --force-remove for
deconfiguration anymore, but we want to decouple our changes from the
dpkg ones, so let's always pass --force-remove-protected when installing
packages such that we can deconfigure protected packages.
Closes: #983014
(cherry picked from commit f8ff3afcd42d8b2e6506bc6f44a894149bf87442)
LP: #1916725
Squashed: regression fix: do require force-loopbreak for Conflicts
Conflicts do require removing the package temporarily, so they really
should not be used.
We need to improve that eventually such that we can deconfigure packages
when we have to remove their dependencies due to conflicts.
(cherry picked from commit 0d51cf142884801c903df0cddaec5545f0174553)
