** Tags added: server-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2047082
Title: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it. Status in openssh package in Ubuntu: New Bug description: In our project we regularly build Ubuntu VM images for current 23.10 (stable). In https://github.com/cockpit-project/bots/issues/5691 we ran into an upgrade failure of openssh-server. It starts with the current cloud image and then apt upgrades it, with "DEBIAN_FRONTEND=noninteractive". openssh was updated a few days ago indeed: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:UqrRSpQNM7SIixVivYP/WwZRjt7Sv89P31W/Gxaf+Z8 root@ubuntu (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:hy9AEDydfnZeY9nf9P4Sb90kx39Oqr101A6tz5j4RQw root@ubuntu (ED25519) rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 I.e. of course that security update itself [1] didn't introduce the regression, but earlier VM builds just didn't have a pending openssh update -- looks like this has been a luring upgrade trap in the release already. As a first naïve reproducer I tried apt update DEBIAN_FRONTEND=noninteractive apt update openssh-server on our current VM (with the release version 1:9.3p1-1ubuntu3), and that worked fine. Same with installing all 9 available packages. rescue.target is loaded/inactive/static, as it should be. Updating without DEBIAN_FRONTEND does show me a conffile prompt about /etc/ssh/sshd_config, which is justified as we do modify the config: # Allow root login with password sed -i 's/^[# ]*PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config # Prevent SSH from hanging for a long time when no external network access echo 'UseDNS no' >> /etc/ssh/sshd_config this also leads to a merge conflict. However, I suppose all of that is tangential to the rescue-ssh.target issue. In all my interactive upgrades, it seemed to handle that just fine: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... rescue-ssh.target is a disabled or a static unit not running, not starting it. So this seems to be related to the first-time installation of openssh- server -- it is part of the cloud image, but it does the host key generation during our image builds. So reproducing this is a bit tricky, but aside from that: Why does it even do this in the first place? # Automatically added by dh_installsystemd/13.11.6ubuntu1 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -d /run/systemd/system ]; then systemctl --system daemon-reload >/dev/null || true if [ -n "$2" ]; then _dh_action=restart else _dh_action=start fi deb-systemd-invoke $_dh_action 'rescue-ssh.target' >/dev/null || true fi fi It feels like the postinst should *never* try to start rescue- ssh.target. That's an alternative boot mode, and should never run un multi-user.target, isn't it? [1] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.1 DistroRelease: Ubuntu 23.10 PackageVersion: openssh-server 1:9.3p1-1ubuntu3.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2047082/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
