upgrade to 1:7.2p2-4ubuntu1 fails on ubuntu server

Bug #1579978 reported by Tomas Cassidy
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

This package upgrade failure has occurred on multiple machines, with the same error on each machine. All affected machines are running Upstart (upstart-sysv) as /sbin/init. The package installed/updated successfully on a machine running Systemd (systemd-sysv) as /sbin/init.

$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  linux-image-4.2.0-35-generic linux-image-extra-4.2.0-35-generic
Use 'sudo apt autoremove' to remove them.
0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up openssh-server (1:7.2p2-4ubuntu1) ...
start: Job failed to start
invoke-rc.d: initscript ssh, action "restart" failed.
dpkg: error processing package openssh-server (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 openssh-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: openssh-server 1:7.2p2-4ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Tue May 10 11:51:58 2016
InstallationDate: Installed on 2015-09-04 (249 days ago)
InstallationMedia: Ubuntu-Server 15.04 "Vivid Vervet" - Release amd64 (20150422)
SourcePackage: openssh
UpgradeStatus: Upgraded to xenial on 2016-05-04 (5 days ago)

Revision history for this message
Tomas Cassidy (tomas-cassidy) wrote :
description: updated
description: updated
Revision history for this message
Tomas Cassidy (tomas-cassidy) wrote :

I had no problems installing the upgraded packages after switching from upstart-sysv to systemd-sysv on the affected machines.

Revision history for this message
Robie Basak (racb) wrote :

Hi Tomas,

Did you attempt to upgrade to Xenial directly from Vivid or did you go through Wily? Was it on Vivid that you switched back to upstart-sysv? I'm not sure this is a supported path (it's certainly an unusual one) but I wonder if an upgrade from Trusty to Xenial is affected since that will still be running upstart after the upgrade but before a reboot.

Revision history for this message
Tomas Cassidy (tomas-cassidy) wrote :

Hi Robie,

I had the same problem occur this morning on a couple of server installs running systemd-sysv, so I'm thinking it might not be an upstart-specific issue. I rebooted one of the servers and was then able to upgrade the package successfully. I haven't yet rebooted the other server. Both had a .crash file in /var/crash and I submitted one of them as bug 1580401. I couldn't work out how to submit the .crash file to an existing bug report.

Revision history for this message
Tomas Cassidy (tomas-cassidy) wrote :

I upgraded from Vivid => Wily => Xenial. I had switched back to upstart-sysv on Vivid but I noticed that the upgrade software reinstalls the ubuntu-standard package (and therefore systemd-sysv) on upgrade to a new release, so I had re-installed upstart-sysv after each upgrade.

Revision history for this message
Robie Basak (racb) wrote :

I've not managed to reproduce this. I tried installing upstart-sysv on a Wily cloud image and upgrading it to Xenial. This made the systemd preinst fail (which may be a separate bug) but I didn't see any openssh failure. I also tried installing upstart-sysv on a Vivid cloud image and upgrading that to Wily and then to Xenial. This worked without problems.

Installing upstart-sysv does remove ubuntu-standard as you say, so I'm not sure this is a supported path. So I'm marking Importance as Low on the basis that it is at least an uncommon path that will not affect the majority of users.

I'm not sure how this might make any further progress without steps to reproduce.

Changed in openssh (Ubuntu):
importance: Undecided → Low
Revision history for this message
Tomas Cassidy (tomas-cassidy) wrote :

Hi Robie,

I tried purging and reinstalling openssh-server, but that failed again with the same error.

I then rebooted the machine and was able to then successfully run apt-get -f install to fix the package installation. Subsequently re-installing the package worked without a problem.

Perhaps there was a temporary file causing a problem somewhere, which was automatically cleaned out on reboot? Something leftover from the upgrade to xenial?

Revision history for this message
Daniel (daniel1985) wrote :

I had the same problem at my machine. I tried to remove and then reinstall openssh-server, but the same error occurred. I know, that just remove openssh-server takes all my conf files on the system. I finally solved my problem by using sshd -t and get an error in my config file, which was running fine with previous version of openssh-server. It seems, that there is no more option to for roaming?

Comment out "UseRoaming no" fixed this issue for me. Perhaps you use this option in your old config file?

Revision history for this message
Seth Arnold (seth-arnold) wrote : Re: [Bug 1579978] Re: upgrade to 1:7.2p2-4ubuntu1 fails on ubuntu server

On Thu, May 12, 2016 at 06:21:36AM -0000, Daniel wrote:
> solved my problem by using sshd -t and get an error in my config file,
> which was running fine with previous version of openssh-server. It
> seems, that there is no more option to for roaming?

I believe upstream removed the roaming support in the client:
http://www.openssh.com/txt/release-7.1p2

Thanks

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openssh (Ubuntu):
status: New → Confirmed
Revision history for this message
Bill Hayden (hayden-haydentech) wrote :

For me, the root cause of this was systemd's inability to create temporary files. I would get a ton of messages similar to "Unsafe symlinks encountered in /var/run/sshd, refusing." in the systemd log, By changing my system root directory (i.e. /) to be owned by root, it fixed all these problems, included the resultant sshd problem. Previously / was owned by my user and group somehow.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.