control: reopen 990069 control: found 990069 2.31-13 control: tag 990069 + patch
On 2021-08-01 00:05, Ron wrote: > > Hi, > > Sadly I can confirm this problem still persists in 2.31-13 too. I found > it (before I found this report of it) yesterday upgrading a fully up to > date buster vm to bullseye ... > > In my case I noticed it at the first conffile prompt when trying to ssh > a new connection into the vm failed, which was after the first prompting > from libc to restart services (and ssh was not included in the list of > services to restart then). > > I can confirm that manually restarting ssh (while the upgrade was still > in progress) did fix it to enable logins again. > > The interesting bit of the upgrade log is included below - I'm not sure > offhand exactly how the libc restart logic is coded, but at first blush > I'd note the new openssh-server is unpacked but not set up at the time > the libc service restart takes place ... > > Cheers, > Ron > > Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... > Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ... > Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... > Preparing to unpack .../runit-helper_2.10.3_all.deb ... > Unpacking runit-helper (2.10.3) ... > Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ... > Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... > Preparing to unpack .../libc6_2.31-13_amd64.deb ... > Checking for services that may need to be restarted... > Checking init scripts... > Unpacking libc6:amd64 (2.31-13) over (2.28-10) ... > Setting up libc6:amd64 (2.31-13) ... > Checking for services that may need to be restarted... > Checking init scripts... > Services to restart for GNU libc library upgrade: > cron atd > Restarting services possibly affected by the upgrade: > cron: restarting...done. > atd: restarting...done. > Services restarted successfully. > Preparing to unpack .../libc-bin_2.31-13_amd64.deb ... > Unpacking libc-bin (2.31-13) over (2.28-10) ... > Setting up libc-bin (2.31-13) ... > ... > <much later> > ... > Setting up openssh-server (1:8.4p1-5) ... Thanks for this upgrade log, with it I have been able to understand and reproduce the issue. The libc restart logic looks for installed packaged, however due to all the breaks and depends between openssh-server and libc6 in the buster -> bullseye upgrade path, it could happen that at the moment the libc6 postinst script is ran, the openssh-server has been degraded from installed to unpacked. I have tested the following fix, which works well when used in the same conditions as the above log: diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh index 8406a543..ee99ac16 100644 --- a/debian/script.in/nsscheck.sh +++ b/debian/script.in/nsscheck.sh @@ -1,8 +1,8 @@ echo -n "Checking for services that may need to be restarted..." # Only get the ones that are installed, of the same architecture # as libc (or arch all) and configured - check=$(dpkg-query -W -f='${binary:Package} ${Status} ${Architecture}\n' $check 2> /dev/null | \ - grep -E "installed (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//') + check=$(dpkg-query -W -f='${binary:Package} ${db:Status-Want} ${Architecture}\n' $check 2> /dev/null | \ + grep -E "(install|hold) (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//') # some init scripts don't match the package names check=$(echo $check | \ sed -e's/\bapache2.2-common\b/apache2/g' \ However before uploading such a fix so close to the release, I think it requires a review by many more pair of eyes. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature