Package: upgrade-reports Severity: normal My previous release is: Debian Bookworm/12 I am upgrading to: Debian Trixie/13 Archive date: From https://mirror.init7.net/debian/project/trace/ftp-master.debian.org: Tue Jul 22 14:36:00 UTC 2025 Creator: dak g7a63da59 Running on host: fasolo.debian.org Archive serial: 2025072203 Date: Tue, 22 Jul 2025 14:36:00 +0000 Architectures: all amd64 arm64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el riscv64 s390 s390x sparc source Upgrade date: 2025-07-22, ~17:15 CEST uname -a before upgrade: Not recorded uname -a after upgrade: Linux monitoring 6.12.35+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.35-1 (2025-07-03) x86_64 GNU/Linux Method: Roughly `apt update; apt dist-upgrade --autoremove --purge`, via SSH
Contents of /etc/apt/sources.list: deb https://mirror.init7.net/debian/ trixie main deb-src https://mirror.init7.net/debian/ trixie main deb https://mirror.init7.net/debian/ trixie-backports main deb-src https://mirror.init7.net/debian/ trixie-backports main deb https://mirror.init7.net/debian/ trixie-updates main deb-src https://mirror.init7.net/debian/ trixie-updates main deb https://security.debian.org/debian-security trixie-security main deb-src https://security.debian.org/debian-security trixie-security main - Were there any non-Debian packages installed before the upgrade? If so, what were they? => No, there should not have been any. - Was the system pre-update a 'pure' system only containing packages from the previous release? If not, which packages were not from that release? => Yes, it should have been pure. - Did any packages fail to upgrade? => No, there were no failures. - Were there any problems with the system after upgrading? => No problems that I have noticed so far. Further Comments/Problems: I've upgraded several Bookworm systems to Trixie so far, which went pretty smooth. But there's one thing I keep noticing, and which I observed a bit more closely while upgrading the system I'm sending this report from: Starting at roughly the time when dpkg says something like Unpacking openssh-server (1:10.0p1-5) over (1:9.2p1-2+deb12u6) ... I'm not able anymore to open new SSH connections to the system I'm upgrading. The SSH daemon is still running, and the existing connections also still work, but new connections fail with kex_exchange_identification: read: Connection reset by peer Connection reset by fd... port 22 on the client. At this time, I see messages like the following in the output from `systemctl status openssh-server.service` (the SSH daemon is still running, usually since the last reboot, or in this case since the libc upgrade earlier during the upgrade process, so the daemon process itself should still be running the binaries from Bookworm, even though the new binaries have already been extracted): Jul 22 17:37:32 monitoring sshd[492742]: -R not supported here The upgrade continues as usual. At some point, I get asked if I want to install the new SSH configuration from the package or keep my modified version (and it doesn't seem to matter what I answer to the question) - but once dpkg restarts the SSH daemon afterwards, new connections are possible again. To me, it seems like the old binary, which is still running, is passing an unsupported parameter to the new binary that was already unpacked when trying to fork off a new process for the new connection (but I haven't checked if that's how it actually works when a new connection is opened, I'm just guessing). The "-R not supported here" string seems to be 'new', i.e. I didn't find it in the openssh package source on Bookworm, but it exists in the version from Trixie. I can't preclude that I'm consistently doing something wrong/unusual/strange during the upgrade or that my SSH daemon configuration contains something weird (although I'm not aware of anything special in there), so maybe this doesn't affect others. So far, I haven't noticed any bug report against the openssh package, an entry in the release notes for Trixie or the NEWS file for openssh which mentions an issue like this one, but I'm sorry if I missed that. Hope this helps, and many thanks for your efforts! Manfred
