Public bug reported:
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
** Affects: openssh (Ubuntu)
Importance: Low
Status: New
** Tags: mantic
--
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
